[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZJWNWeqQ8ON9NNfs@finisterre.sirena.org.uk>
Date: Fri, 23 Jun 2023 13:17:29 +0100
From: Mark Brown <broonie@...nel.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"willy@...radead.org" <willy@...radead.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"Xu, Pengfei" <pengfei.xu@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"kcc@...gle.com" <kcc@...gle.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"nadav.amit@...il.com" <nadav.amit@...il.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"david@...hat.com" <david@...hat.com>,
"Schimpe, Christina" <christina.schimpe@...el.com>,
"Torvalds, Linus" <torvalds@...ux-foundation.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jannh@...gle.com" <jannh@...gle.com>,
"dethoma@...rosoft.com" <dethoma@...rosoft.com>,
"mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
"pavel@....cz" <pavel@....cz>, "bp@...en8.de" <bp@...en8.de>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"john.allen@....com" <john.allen@....com>,
"arnd@...db.de" <arnd@...db.de>,
"jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
"bsingharora@...il.com" <bsingharora@...il.com>,
"x86@...nel.org" <x86@...nel.org>,
"oleg@...hat.com" <oleg@...hat.com>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"gorcunov@...il.com" <gorcunov@...il.com>,
"Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"szabolcs.nagy@....com" <szabolcs.nagy@....com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"debug@...osinc.com" <debug@...osinc.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"Syromiatnikov, Eugene" <esyr@...hat.com>,
"Yang, Weijiang" <weijiang.yang@...el.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"Eranian, Stephane" <eranian@...gle.com>
Subject: Re: [PATCH v9 16/42] mm: Add guard pages around a shadow stack.
On Fri, Jun 23, 2023 at 10:40:00AM +0300, Mike Rapoport wrote:
> On Thu, Jun 22, 2023 at 06:27:40PM +0000, Edgecombe, Rick P wrote:
> > 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
This isn't an x86 specific concept, arm64 has a very similar extension
called Guarded Control Stack (which I should be publishing changes for
in the not too distant future) and riscv also has something. For arm64
I'm using the generic mm changes wholesale, we have a similar need for
guard pages around the GCS and while the mechanics of accessing are
different the requirement ends up being the same. Perhaps we could just
rewrite the comment to say that guard pages prevent over/underflow of
the stack by userspace and that a single page is sufficient for all
current architectures, with the details of the working for x86 put in
some x86 specific place?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists