From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EA7BC61DA4 for ; Wed, 22 Feb 2023 22:13:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D69996B0071; Wed, 22 Feb 2023 17:13:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D3FDE6B0072; Wed, 22 Feb 2023 17:13:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE27F6B0073; Wed, 22 Feb 2023 17:13:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B09F26B0071 for ; Wed, 22 Feb 2023 17:13:39 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 78188AAF5E for ; Wed, 22 Feb 2023 22:13:39 +0000 (UTC) X-FDA: 80496330558.08.8747124 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf04.hostedemail.com (Postfix) with ESMTP id 8B3794000D for ; Wed, 22 Feb 2023 22:13:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=cg3FMFAJ; spf=pass (imf04.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677104017; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IbCbSZMDoolIYT4QTJLVLMs17uxD1iPtRBFug2ILkwU=; b=Hh2Q3dAfeyvEqfFJI1sz2xJU7imRfebowAX+gkglrpEkFsRG9vte0/+rdGpucID68e7c3q c4H1thMouTLiF4AEO+diOah1h+cuR652pvFZ1PZRFTJbf7e5TROfP17twdi2Lh15X23Xhp Kc9aWIILzKxVQFkfuRfr5Cdcbyy+O2Y= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=cg3FMFAJ; spf=pass (imf04.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677104017; a=rsa-sha256; cv=none; b=eTj+3us4yh2C3IHGJTquzO4VVnqjIokozKwHidp7QXldN3oMTEFXcY93qjO6y4zGSnX+I5 RRpy8Eb18bRcRxPzBmXWVQpg4tu54dGLQ2l+fdJyQmxDbWBuWwFr8ntGWrxu27UrzUPm1t O52oLeb6ffNr9P/UqNIQqNE/vI2mahM= Received: by mail-pg1-f170.google.com with SMTP id d6so1706120pgu.2 for ; Wed, 22 Feb 2023 14:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IbCbSZMDoolIYT4QTJLVLMs17uxD1iPtRBFug2ILkwU=; b=cg3FMFAJuPi2c8A7CQq/nKwBx0D1yuWtBSTFipKwbm37PB7JPMt6VRIcZf0lJ+HlNx y6U+XsxuwVdAbzt6Qp4UA6rpXOMpRum4XkQvLx2s54YYOsMrpX+PwJDKFbr9qFwOZDqs ZKVNjwmhE2KCDfh7MIFEUpU3LEj0h7ML8m+oYXdEKJhTv9hy9gc4w72j5+tx83vU2t7g mOPDCHHVxaUeKtbERi4NLvScRG2IakMiXN8m53KCwQyGjBxDSkhczUtmBX6EN3dlgi8/ j758QR7+YMgV5CRAMKphCigP1SaYUyDuK8hKY6YrrwXqElaGNEGn9r4yQ+aFePJk/i68 ebag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IbCbSZMDoolIYT4QTJLVLMs17uxD1iPtRBFug2ILkwU=; b=FWKCdWZqmRq1D1F/gqb4S21QHTRKuVRDnbN+HlGzO8CJQr8mi9qCJYgC2DkRA75o9/ JPg6pmwSArlqTR3oWXYNe3EggIgBrN9CRrK76sgsvhU0liSMf9OSGoaPGkyjmk7GWTcs f15AFmQlDj2LVG2uzQdyd84QiJiqlVhqGh2Lux+B8L2cK4PfPmnuBhqrV239RwDWVrC3 83VnhbvlO9UNynepSWRUzRuI6mY6gpjdXjmZHV9zm6VdAF3AMETRGixkm92e+j2Kb0rl oZWJc8uNnAdZ00DU8/RPBh4Dtt88nm/jT7ZPzapU49V29ptToKHUE+iIAt6eGQbUMBj+ wlng== X-Gm-Message-State: AO0yUKW2INGv4OI67nS9ldNWkfsxOZu1X+qy2pDiDINs1HTNxvsJdS1e wi+Rser9wGOnLPFdkkejP1HPCA== X-Google-Smtp-Source: AK7set9H/13butg6xLlG1KNCEtebGT6HdRa76qfXxIkiBRaYjFkm+4KsL1gIBDSnN+I8dUYeXvdEDQ== X-Received: by 2002:aa7:9407:0:b0:5a9:ea47:cd00 with SMTP id x7-20020aa79407000000b005a9ea47cd00mr8932796pfo.17.1677104016042; Wed, 22 Feb 2023 14:13:36 -0800 (PST) Received: from debug.ba.rivosinc.com ([66.220.2.162]) by smtp.gmail.com with ESMTPSA id k7-20020aa792c7000000b0058d92d6e4ddsm4895952pfa.5.2023.02.22.14.13.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Feb 2023 14:13:35 -0800 (PST) Date: Wed, 22 Feb 2023 14:13:33 -0800 From: Deepak Gupta To: David Hildenbrand Cc: "Edgecombe, Rick P" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "dave.hansen@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "Eranian, Stephane" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "bp@alien8.de" , "Lutomirski, Andy" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "x86@kernel.org" , "mike.kravetz@oracle.com" , "Yang, Weijiang" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" , "akpm@linux-foundation.org" , "Yu, Yu-cheng" Subject: Re: [PATCH v6 18/41] mm: Introduce VM_SHADOW_STACK for shadow stack memory Message-ID: <20230222221333.GA945966@debug.ba.rivosinc.com> References: <20230218211433.26859-1-rick.p.edgecombe@intel.com> <20230218211433.26859-19-rick.p.edgecombe@intel.com> <366c0af9-850f-24b1-3133-976fa92c51e2@redhat.com> <9e25a24f3783f3960e2c1e5e68a6c6fdf3d89442.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8B3794000D X-Rspam-User: X-Stat-Signature: 7ine69kw44g4tkxmmobhnoxx9ofwsh8b X-HE-Tag: 1677104017-792911 X-HE-Meta: U2FsdGVkX1/Ub4lgDiYR4l+ud2C2ECuJImfjoHKSinL793olymCFx3y0LPkEnWLhzfKDjxc/DZ0Q1VGMAnC/uHz3gjn7wEWt2sgUVi3yt02FofSPtRKMBPbiP2WWp/Twd1E3Dp/Exh7MWkkcRMbCOHTBnbL5fVycWgSRn1Y/iZcvksiig08Y9S8+GWkkx6CSHcMctoBhwsQ/O+3HjJ0yi+WfRKqPrP62cT3HlIA4Ei1dGCeI+UZvOg7f2R61tnqoHwWxzrI6+Lcz0L2gwISVrJeg/qj0TZWFmiSdlzA8i72r9NmWENytV/N2bcLDB1aVRW8Ct7Mzf0A8mHfI1TPqGhQuas0RmPIbLVbBGQ76BS6OvhpNxZ7sqUbWTRH6JYGIcKP4WUeSaTDvMPsL2meHJtpJ9brXoZIEBzwFzG3HtO87Cnh0MV3Te+fyOdKvaEw4m3jr+YorlSa9QmrDUSWD2GfHWGhvEf7DB9cWtVK/z+y1yapcbP4/pA83nY4Xupx4aJ+eibruWODlmhOLZBEou+mQFphoVDaMkRNmqrHnW7hAOW9rKiWToveE8TOe0TIGPBVUYdY8p05Eq2jTrAOVMJu4Qe+riH0pA17f1NYMaDbM+TkDKwOt+Ipmn+5U/i74z6YwR5cB9VqGGsE0ykJRTVvJKxc/PTPZ/RBVVJzdJuXNJnJG2qTrtG2Q/umIuQtknPFHz1tpZuOjz06/WfYwRzM1WqtV3gJ5uXG4fltP/kWu1F8Ss3sk6Lg3YE9RUsZUm9YbyCe5yco99raEkGr2CQpW479shTSj1tH5HMDG/9UGXWvnwLdwmeipcrCa6gOUFMCfoPcVEEH65W20OorMIL8HGYHfphu+oWnYJNm0kCAitZdG5JCKbh3QBJgldFg5SoC4bqM2B6Y0bVjuRp+TuXnz3mLbP4STVFbEMwMd/CYwTnkUtxBPjSt6obYeELw5dRBMFI35mBWXzbQ48Ig Q6rnXAwK jQQtLG9LDejyZpHaBkenHFm+4QAFwBP+UxFnuKN1c8Lj6DVABoQ9sTmHAswDUZxv5Q6bfovd+8KEOgmWHpHAJNQngSP3dyZZlU8w425gT46ddK+xGj4LVAgkO4CH1UomjzDftjSc2AmKBq32H7Fk66cNePI+eub+qMhi0mw4XQEid+QSvz2nT2sdbv66xhu1BtMzyo78sw4lv1cqfJvmPvvMCmv1ToTx5V36TgLvmtnpApWinFa31f74FB9iQw1Wh8QSgYkwsPPhHxOoi8AuKo/Jwb+YoeNhhlBwWJCZUP2myYmMo5uEJgYvjGN2nq0i6ON0Qu4jOIDXOOpRm8jwbMOUdFylvIRg8iHGmdyaQuOElYAmp9PbCDeqtElTCsZOWZF0q/Ev/mzaDdTIdfENtXcsGgpE3F4p5a1g/rFT0FX7tnbqQMgTa39jmYC9K75j42lbJZEGvrJVQIbSkEGPsOafRPhy3eaeOyQDxj36h0ujGqxDULhfX80AVDsuQHhYiyCTXdbFLWJ4q6yop5mGfzCeYNRm5wiLee9SrkuK4xXlJR0Zij0X7jcjh7o1jg4SJvtQthK1YXbQnxsF90stm1sqXHAmb4hL81WteyZZyKu+Xjd2Wz83S5DnuUT132yaNMSPeD80XJJ2nxHkEDGrx9XttaV3AwsVwesHVpAUUw6ntl4djluUzU9/OAA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 21, 2023 at 09:34:35AM +0100, David Hildenbrand wrote: >On 20.02.23 23:08, Edgecombe, Rick P wrote: >>On Mon, 2023-02-20 at 13:56 +0100, David Hildenbrand wrote: >>>On 18.02.23 22:14, Rick Edgecombe wrote: >>>>From: Yu-cheng Yu >>>> >>>>The x86 Control-flow Enforcement Technology (CET) feature includes >>>>a new >>>>type of memory called shadow stack. This shadow stack memory has >>>>some >>>>unusual properties, which requires some core mm changes to function >>>>properly. >>>> >>>>A shadow stack PTE must be read-only and have _PAGE_DIRTY set. >>>>However, >>>>read-only and Dirty PTEs also exist for copy-on-write (COW) pages. >>>>These >>>>two cases are handled differently for page faults. Introduce >>>>VM_SHADOW_STACK to track shadow stack VMAs. >>> >>>I suggest simplifying and abstracting that description. >>> >>>"New hardware extensions implement support for shadow stack memory, >>>such >>>as x86 Control-flow Enforcement Technology (CET). Let's add a new VM >>>flag to identify these areas, for example, to be used to properly >>>indicate shadow stack PTEs to the hardware." >> >>Ah yea, that top blurb was added to all the non-x86 arch patches after >>some feedback from Andrew Morton. He had said basically (in some more >>colorful language) that the changelogs (at the time) were written >>assuming the reader knows what a shadow stack is. > >Okay. It's a bit repetitive, though. > >Ideally, we'd just explain it in the cover letter in detail and >Andrews's script would include the cover letter in the first commit. >IIRC, that's what usually happens. > >> >>So it might be worth keeping a little more info in the log? > >Copying the same paragraph into each commit is IMHO a bit repetitive. >But these are just my 2 cents. > >[...] > >>>Should we abstract this to CONFIG_ARCH_USER_SHADOW_STACK, seeing >>>that >>>other architectures might similarly need it? >> >>There was an ARCH_HAS_SHADOW_STACK but it got removed following this >>discussion: >> >>https://lore.kernel.org/lkml/d09e952d8ae696f687f0787dfeb7be7699c02913.camel@intel.com/ >> >>Now we have this new RFC for riscv as potentially a second >>implementation. But it is still very early, and I'm not sure anyone >>knows exactly what the similarities will be in a mature version. So I >>think it would be better to refactor in an ARCH_HAS_SHADOW_STACK later >>(and similar abstractions) once that series is more mature and we have >>an idea of what pieces will be shared. I don't have a problem in >>principle with an ARCH config, just don't think we should do it yet. > >Okay, easy to factor out later. I would be more than happy if this config name would've been abstracted out and arches can choose to implement. It's a bit sad that it was generic earlier and was later changed due to lack of support from other architectures. Now there are three architectures who either already support shadow stack (x86), announced the support (aarch64) or are planning to support (riscv). However given patch reduction I will get due to `pte_mkwrite` refactor, I am in favor of future refactor for config. > >Acked-by: David Hildenbrand > >-- >Thanks, > >David / dhildenb >