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 4AD94EB64D7 for ; Fri, 23 Jun 2023 07:41:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B62BB8D0002; Fri, 23 Jun 2023 03:41:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEC438D0001; Fri, 23 Jun 2023 03:41:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93D278D0002; Fri, 23 Jun 2023 03:41:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7D7758D0001 for ; Fri, 23 Jun 2023 03:41:00 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 45C54B0969 for ; Fri, 23 Jun 2023 07:41:00 +0000 (UTC) X-FDA: 80933216280.22.627FEEE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 75A13120012 for ; Fri, 23 Jun 2023 07:40:58 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gVLTca81; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687506058; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Fhi+7Oz9w5Qvfj7fYdBAq9/IJ4Xxj+iyWNjf8w1ANDo=; b=lJraYsqzp2a+v9WYK7TmqYWwTaLDq3+nwaTCIdsZIweFgH+svBHglQQK6OTojXPnYHdfIx 1YvqwxinnolZu4a450GwpwUR/h8+q1qN11vve4S8bemqXF/6RJmkB4xP3G3Q3tm2USin8q o/fro/EiyD+m15Zhot5rFxD3I8PhWhQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gVLTca81; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687506058; a=rsa-sha256; cv=none; b=Lz6Fh9oT6y70XZaJWZ8bCuLWz88A99mBdcUFwCh2z/b+pkFshpWVSP6qANAKDRoHmLLUNa ZjiX816Pg5mvytlwVqOFucX9Z6VHzWVEn8XcHrJ90z82JAtsMhLwSvBPULomnkyq/kik4L ZiDu4uAl8kDyIz+IdGrrelODMk9d8Wk= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5AA9F61995; Fri, 23 Jun 2023 07:40:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1A5AC433C9; Fri, 23 Jun 2023 07:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687506056; bh=GzKdhhzyZ+iRj8RsJgARuHLY4EfLvN1z9hAE+ocFSf4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gVLTca81VyzmWJPHZ1XRM8wpGx91F1ehz6zWo5RgDcGgnNrGRYv7gwb4L8wSaGQy6 58p0kAqTEBX2B+ZhmkdkRtK4OvS0N3nBtO/44NvxnRTtG37M80tqbPxBCpuGVBVrYX Lc19vX6RLlULkBWswy35J1yqets3vasDgQMBrgRL0Zn8iEhGuVJhxJ7pgB+M1uwTSc DFIOaUc/RIZzLpDYhxqAvr1dmKC+B3faD6nBtFLTYETHitmbTxBp0g06mbo6hSa9eN zfW1VF5vpbIaUC/aVJixw/BgmmMoectkQsyn5DDvCQHDrA4bEgMdkhqgO/a0SXycWj q5TvSNFtlbpug== Date: Fri, 23 Jun 2023 10:40:00 +0300 From: Mike Rapoport To: "Edgecombe, Rick P" Cc: "willy@infradead.org" , "akpm@linux-foundation.org" , "Xu, Pengfei" , "tglx@linutronix.de" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "Torvalds, Linus" , "peterz@infradead.org" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "jannh@google.com" , "dethoma@microsoft.com" , "broonie@kernel.org" , "mike.kravetz@oracle.com" , "pavel@ucw.cz" , "bp@alien8.de" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "john.allen@amd.com" , "arnd@arndb.de" , "jamorris@linux.microsoft.com" , "bsingharora@gmail.com" , "x86@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "gorcunov@gmail.com" , "Yu, Yu-cheng" , "andrew.cooper3@citrix.com" , "hpa@zytor.com" , "mingo@redhat.com" , "szabolcs.nagy@arm.com" , "hjl.tools@gmail.com" , "debug@rivosinc.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "Yang, Weijiang" , "linux-doc@vger.kernel.org" , "dave.hansen@linux.intel.com" , "Eranian, Stephane" Subject: Re: [PATCH v9 16/42] mm: Add guard pages around a shadow stack. Message-ID: <20230623074000.GG52412@kernel.org> References: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> <20230613001108.3040476-17-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 75A13120012 X-Rspam-User: X-Stat-Signature: weytur6snswtwrspwx7gejhwcmgrs81w X-Rspamd-Server: rspam01 X-HE-Tag: 1687506058-50440 X-HE-Meta: U2FsdGVkX18bYTaQHh56RkwYXkUkZeJO4VFItGG6DT1ToFGYuDVjOucjbs6xjUVXCFJPiY0nosxiabuf1Uz8dEIw6GR4p6tAvBkiQjN3eK4KpeZonYc/qyqvYxII0EmsRGOY/8H+Bsl4BH47quiFh8ExTPJHqWWm4dXWjkQbLGARpZfA28y7AMqVNs9lkq8bRIv/LLq6Vfd12QdY7syywa9FPVdTC7ZSaFYKdFeuZVuWGcSKkNn0xycOQnd59yoBQHVQSRU7M5GOZwCfRusc3Y/VyTWoKfsPh2o1Lh2dDPTKIZUTJZzPFl8HDZgYf3hJtwChYJGqKKmc+E2lOwDy0bwSXZh8eY5wE4l5KtXneO83aitvYU8b8WIDVwWPgGXFovwdAq8G/8rWdWPv70aqrBkvUG+HyeWxfAunflR4/fFPCiDE0FG/sVSUc47fgmIgW4eT3fNS5yq/C6+r2BKaNiT4WvLXf+un+1rlXO7A0/pYHnFpSYEJWDwAbUNLSHph8p8/5qbEWY6uvvIlEMLdotyyWxJTHbFdBCPMio8BgOXOvuuaqNEOyt/sbJC6aeH3ql9HQas9wcvJ7HnlS6X4oUDmtb97iZzAfoi+g7/c3rSpq5JtQpi4TQEc1ZCCyFsMDzhmsZNMnnmTXmBIpmHWC104jdACzlrLlID19SWzTYMMVe2T7iYcCHsThJXqwKi0m8XCYz23Jqguka0LdvCc1hN+F3/1qgMk8m4+N9AqAQB3MebwQ8zqgQxLvVpjJqAgFQ35pvO9+k8SxqYRR40iJXTeSbpq/R7UHI3pnmL3v9FFPX2D3uJHuLSI2ENb6MsOTo0ZRgSufDhcx/01Unp+KJ90B+aG1pSfFmptCFNcZP5jKX0OBGe8OCb6JDeWOdrkkh9tdccnGWDCR0HWLRuiEwbb5pg4FeXGxJwCwWxSon6gTp5/LX95B6sxC/Ljtgw1j8XH1TWyEa0k6hVVwC5 zam0XYnw R6InnM683p2m0a/P/cC0sx6cwZCGNzS1hpktvO8V1X0vuE1Y1yxp83Va1sn9KLtDJPcIF/hkngijpGhlKLnh9rBxkduD0k7qWrT6SSQl2geomzMfeIQXUvhAuw8ePGXSciCEBu70v0kKsSeP3If/S0yeewueH3iuhpK9IHIihAvasH1gL32VB30DqeARygrTFV00/t5QRz4WDuuTTLP62QX3mqQOuSghf0yP4TzGnyptmr4UfJ2yivgS0aQWAp8rOGjEIE3oeGwjwOK2hNB++2TPPQOlp6NySmv+1dog4TRmjKPCb2dQDaU+xtYQ21Hcys5LUn+Ob+QQq5+2eaRRNfW9iBEd+mv2XUbudGfNG00q0gGfy3EhlCbtR9D0VrM+N0vjVIys8KtHWMotaRdlUDbm2MzDZoYTUNY6DhSrRlNh6+PCJa13TRomDVPTEcGX0Kj6ohtqPEVqB1KlD5xkomnbxe1kTdolCQrdG 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 Thu, Jun 22, 2023 at 06:27:40PM +0000, Edgecombe, Rick P wrote: > On Thu, 2023-06-22 at 19:21 +0100, Matthew Wilcox wrote: > > On Mon, Jun 12, 2023 at 05:10:42PM -0700, Rick Edgecombe wrote: > > > +++ b/include/linux/mm.h > > > @@ -342,7 +342,36 @@ extern unsigned int kobjsize(const void > > > *objp); > > >   #endif /* CONFIG_ARCH_HAS_PKEYS */ > > >   > > >   #ifdef CONFIG_X86_USER_SHADOW_STACK > > > -# define VM_SHADOW_STACK       VM_HIGH_ARCH_5 /* Should not be set > > > with VM_SHARED */ > > > +/* > > > + * This flag should not be set with VM_SHARED because of lack of > > > support > > > + * core mm. It will also get a guard page. This helps userspace > > > protect > > > + * itself from attacks. The reasoning is as follows: > > > + * > > > + * The shadow stack pointer(SSP) is moved by CALL, RET, and > > > INCSSPQ. The > > > + * INCSSP instruction can increment the shadow stack pointer. It > > > is the > > > + * shadow stack analog of an instruction like: > > > + * > > > + *   addq $0x80, %rsp > > > + * > > > + * However, there is one important difference between an ADD on > > > %rsp > > > + * and INCSSP. In addition to modifying SSP, INCSSP also reads > > > from the > > > + * memory of the first and last elements that were "popped". It > > > can be > > > + * thought of as acting like this: > > > + * > > > + * READ_ONCE(ssp);       // read+discard top element on stack > > > + * ssp += nr_to_pop * 8; // move the shadow stack > > > + * READ_ONCE(ssp-8);     // read+discard last popped stack element > > > + * > > > + * The maximum distance INCSSP can move the SSP is 2040 bytes, > > > before > > > + * it would read the memory. Therefore a single page gap will be > > > enough > > > + * to prevent any operation from shifting the SSP to an adjacent > > > stack, > > > + * since it would have to land in the gap at least once, causing a > > > + * fault. > > > + * > > > + * Prevent using INCSSP to move the SSP between shadow stacks by > > > + * having a PAGE_SIZE guard gap. > > > + */ > > > +# define VM_SHADOW_STACK       VM_HIGH_ARCH_5 > > >   #else > > >   # define VM_SHADOW_STACK      VM_NONE > > >   #endif > > > > This is a lot of very x86-specific language in a generic header file. > > I'm sure there's a better place for all this text. > > Yes, I couldn't find another place for it. This was the reasoning: > https://lore.kernel.org/lkml/07deaffc10b1b68721bbbce370e145d8fec2a494.camel@intel.com/ > > Did you have any particular place in mind? Since it's near CONFIG_X86_USER_SHADOW_STACK the comment in mm.h could be /* * VMA is used for shadow stack and implies guard pages. * See arch/x86/kernel/shstk.c for details */ and the long reasoning comment can be moved near alloc_shstk in arch/x86/kernel/shstk.h -- Sincerely yours, Mike.