All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "david@redhat.com" <david@redhat.com>,
	"bsingharora@gmail.com" <bsingharora@gmail.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"Syromiatnikov, Eugene" <esyr@redhat.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"Eranian, Stephane" <eranian@google.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"fweimer@redhat.com" <fweimer@redhat.com>,
	"nadav.amit@gmail.com" <nadav.amit@gmail.com>,
	"jannh@google.com" <jannh@google.com>,
	"dethoma@microsoft.com" <dethoma@microsoft.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"kcc@google.com" <kcc@google.com>, "pavel@ucw.cz" <pavel@ucw.cz>,
	"oleg@redhat.com" <oleg@redhat.com>,
	"hjl.tools@gmail.com" <hjl.tools@gmail.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"Schimpe, Christina" <christina.schimpe@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
	"Yang, Weijiang" <weijiang.yang@intel.com>,
	"debug@rivosinc.com" <debug@rivosinc.com>,
	"jamorris@linux.microsoft.com" <jamorris@linux.microsoft.com>,
	"john.allen@amd.com" <john.allen@amd.com>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"gorcunov@gmail.com" <gorcunov@gmail.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
Subject: Re: [PATCH v6 14/41] x86/mm: Introduce _PAGE_SAVED_DIRTY
Date: Mon, 20 Feb 2023 21:38:27 +0000	[thread overview]
Message-ID: <6f19d7c7ad9f61fa8f6c9bd09d24524dbe17463f.camel@intel.com> (raw)
In-Reply-To: <70681787-0d33-a9ed-7f2a-747be1490932@redhat.com>

On Mon, 2023-02-20 at 12:32 +0100, David Hildenbrand wrote:
> On 18.02.23 22:14, Rick Edgecombe wrote:
> > Some OSes have a greater dependence on software available bits in
> > PTEs than
> > Linux. That left the hardware architects looking for a way to
> > represent a
> > new memory type (shadow stack) within the existing bits. They chose
> > to
> > repurpose a lightly-used state: Write=0,Dirty=1. So in order to
> > support
> > shadow stack memory, Linux should avoid creating memory with this
> > PTE bit
> > combination unless it intends for it to be shadow stack.
> > 
> > The reason it's lightly used is that Dirty=1 is normally set by HW
> > _before_ a write. A write with a Write=0 PTE would typically only
> > generate
> > a fault, not set Dirty=1. Hardware can (rarely) both set Dirty=1
> > *and*
> > generate the fault, resulting in a Write=0,Dirty=1 PTE. Hardware
> > which
> > supports shadow stacks will no longer exhibit this oddity.
> > 
> > So that leaves Write=0,Dirty=1 PTEs created in software. To achieve
> > this,
> > in places where Linux normally creates Write=0,Dirty=1, it can use
> > the
> > software-defined _PAGE_SAVED_DIRTY in place of the hardware
> > _PAGE_DIRTY.
> > In other words, whenever Linux needs to create Write=0,Dirty=1, it
> > instead
> > creates Write=0,SavedDirty=1 except for shadow stack, which is
> > Write=0,Dirty=1. Further differentiated by VMA flags, these PTE bit
> > combinations would be set as follows for various types of memory:
> 
> I would simplify (see below) and not repeat what the patch contains
> as 
> comments already that detailed.

This verbiage has had quite a bit of x86 maintainer attention already.
I hear what you are saying, but I'm a bit hesitant to take style
suggestions at this point for fear of the situation where people ask
for changes back and forth across different versions. Unless any x86
maintainers want to chime in again? More responses below.

> 
> > 
> > (Write=0,SavedDirty=1,Dirty=0):
> >   - A modified, copy-on-write (COW) page. Previously when a typical
> >     anonymous writable mapping was made COW via fork(), the kernel
> > would
> >     mark it Write=0,Dirty=1. Now it will instead use the SavedDirty
> > bit.
> >     This happens in copy_present_pte().
> >   - A R/O page that has been COW'ed. The user page is in a R/O VMA,
> >     and get_user_pages(FOLL_FORCE) needs a writable copy. The page
> > fault
> >     handler creates a copy of the page and sets the new copy's PTE
> > as
> >     Write=0 and SavedDirty=1.
> >   - A shared shadow stack PTE. When a shadow stack page is being
> > shared
> >     among processes (this happens at fork()), its PTE is made
> > Dirty=0, so
> >     the next shadow stack access causes a fault, and the page is
> >     duplicated and Dirty=1 is set again. This is the COW equivalent
> > for
> >     shadow stack pages, even though it's copy-on-access rather than
> >     copy-on-write.
> > 
> > (Write=0,SavedDirty=0,Dirty=1):
> >   - A shadow stack PTE.
> >   - A Cow PTE created when a processor without shadow stack support
> > set
> >     Dirty=1.
> > 
> > There are six bits left available to software in the 64-bit PTE
> > after
> > consuming a bit for _PAGE_SAVED_DIRTY. No space is consumed in 32-
> > bit
> > kernels because shadow stacks are not enabled there.
> > 
> > Implement only the infrastructure for _PAGE_SAVED_DIRTY. Changes to
> > start
> > creating _PAGE_SAVED_DIRTY PTEs will follow once other pieces are
> > in place.
> > 
> > Tested-by: Pengfei Xu <pengfei.xu@intel.com>
> > Tested-by: John Allen <john.allen@amd.com>
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > 
> > ---
> > v6:
> >   - Rename _PAGE_COW to _PAGE_SAVED_DIRTY (David Hildenbrand)
> >   - Add _PAGE_SAVED_DIRTY to _PAGE_CHG_MASK
> > 
> > v5:
> >   - Fix log, comments and whitespace (Boris)
> >   - Remove capitalization on shadow stack (Boris)
> > 
> > v4:
> >   - Teach pte_flags_need_flush() about _PAGE_COW bit
> >   - Break apart patch for better bisectability
> > 
> > v3:
> >   - Add comment around _PAGE_TABLE in response to comment
> >     from (Andrew Cooper)
> >   - Check for PSE in pmd_shstk (Andrew Cooper)
> >   - Get to the point quicker in commit log (Andrew Cooper)
> >   - Clarify and reorder commit log for why the PTE bit examples
> > have
> >     multiple entries. Apply same changes for comment. (peterz)
> >   - Fix comment that implied dirty bit for COW was a specific x86
> > thing
> >     (peterz)
> >   - Fix swapping of Write/Dirty (PeterZ)
> > ---
> >   arch/x86/include/asm/pgtable.h       | 79
> > ++++++++++++++++++++++++++++
> >   arch/x86/include/asm/pgtable_types.h | 65 ++++++++++++++++++++---
> >   arch/x86/include/asm/tlbflush.h      |  3 +-
> >   3 files changed, 138 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/pgtable.h
> > b/arch/x86/include/asm/pgtable.h
> > index 2b423d697490..110e552eb602 100644
> > --- a/arch/x86/include/asm/pgtable.h
> > +++ b/arch/x86/include/asm/pgtable.h
> > @@ -301,6 +301,45 @@ static inline pte_t pte_clear_flags(pte_t pte,
> > pteval_t clear)
> >   	return native_make_pte(v & ~clear);
> >   }
> >   
> > +/*
> > + * COW and other write protection operations can result in
> > Dirty=1,Write=0
> > + * PTEs. But in the case of X86_FEATURE_USER_SHSTK, the software
> > SavedDirty bit
> > + * is used, since the Dirty=1,Write=0 will result in the memory
> > being treated as
> > + * shadow stack by the HW. So when creating dirty, write-protected 
> > memory, a
> > + * software bit is used _PAGE_BIT_SAVED_DIRTY. The following
> > functions
> > + * pte_mksaveddirty() and pte_clear_saveddirty() take a
> > conventional dirty,
> > + * write-protected PTE (Write=0,Dirty=1) and transition it to the
> > shadow stack
> > + * compatible version. (Write=0,SavedDirty=1).
> > + */
> > +static inline pte_t pte_mksaveddirty(pte_t pte)
> > +{
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pte;
> > +
> > +	pte = pte_clear_flags(pte, _PAGE_DIRTY);
> > +	return pte_set_flags(pte, _PAGE_SAVED_DIRTY);
> > +}
> > +
> > +static inline pte_t pte_clear_saveddirty(pte_t pte)
> > +{
> > +	/*
> > +	 * _PAGE_SAVED_DIRTY is unnecessary on !X86_FEATURE_USER_SHSTK
> > kernels,
> > +	 * since the HW dirty bit can be used without creating shadow
> > stack
> > +	 * memory. See the _PAGE_SAVED_DIRTY definition for more
> > details.
> > +	 */
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pte;
> > +
> > +	/*
> > +	 * PTE is getting copied-on-write, so it will be dirtied
> > +	 * if writable, or made shadow stack if shadow stack and
> > +	 * being copied on access. Set the dirty bit for both
> > +	 * cases.
> > +	 */
> > +	pte = pte_set_flags(pte, _PAGE_DIRTY);
> > +	return pte_clear_flags(pte, _PAGE_SAVED_DIRTY);
> > +}
> > +
> >   #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
> >   static inline int pte_uffd_wp(pte_t pte)
> >   {
> > @@ -420,6 +459,26 @@ static inline pmd_t pmd_clear_flags(pmd_t pmd,
> > pmdval_t clear)
> >   	return native_make_pmd(v & ~clear);
> >   }
> >   
> > +/* See comments above pte_mksaveddirty() */
> > +static inline pmd_t pmd_mksaveddirty(pmd_t pmd)
> > +{
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pmd;
> > +
> > +	pmd = pmd_clear_flags(pmd, _PAGE_DIRTY);
> > +	return pmd_set_flags(pmd, _PAGE_SAVED_DIRTY);
> > +}
> > +
> > +/* See comments above pte_mksaveddirty() */
> > +static inline pmd_t pmd_clear_saveddirty(pmd_t pmd)
> > +{
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pmd;
> > +
> > +	pmd = pmd_set_flags(pmd, _PAGE_DIRTY);
> > +	return pmd_clear_flags(pmd, _PAGE_SAVED_DIRTY);
> > +}
> > +
> >   #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
> >   static inline int pmd_uffd_wp(pmd_t pmd)
> >   {
> > @@ -491,6 +550,26 @@ static inline pud_t pud_clear_flags(pud_t pud,
> > pudval_t clear)
> >   	return native_make_pud(v & ~clear);
> >   }
> >   
> > +/* See comments above pte_mksaveddirty() */
> > +static inline pud_t pud_mksaveddirty(pud_t pud)
> > +{
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pud;
> > +
> > +	pud = pud_clear_flags(pud, _PAGE_DIRTY);
> > +	return pud_set_flags(pud, _PAGE_SAVED_DIRTY);
> > +}
> > +
> > +/* See comments above pte_mksaveddirty() */
> > +static inline pud_t pud_clear_saveddirty(pud_t pud)
> > +{
> > +	if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> > +		return pud;
> > +
> > +	pud = pud_set_flags(pud, _PAGE_DIRTY);
> > +	return pud_clear_flags(pud, _PAGE_SAVED_DIRTY);
> > +}
> > +
> >   static inline pud_t pud_mkold(pud_t pud)
> >   {
> >   	return pud_clear_flags(pud, _PAGE_ACCESSED);
> > diff --git a/arch/x86/include/asm/pgtable_types.h
> > b/arch/x86/include/asm/pgtable_types.h
> > index 0646ad00178b..3b420b6c0584 100644
> > --- a/arch/x86/include/asm/pgtable_types.h
> > +++ b/arch/x86/include/asm/pgtable_types.h
> > @@ -21,7 +21,8 @@
> >   #define _PAGE_BIT_SOFTW2	10	/* " */
> >   #define _PAGE_BIT_SOFTW3	11	/* " */
> >   #define _PAGE_BIT_PAT_LARGE	12	/* On 2MB or 1GB pages */
> > -#define _PAGE_BIT_SOFTW4	58	/* available for programmer */
> > +#define _PAGE_BIT_SOFTW4	57	/* available for programmer */
> > +#define _PAGE_BIT_SOFTW5	58	/* available for programmer */
> >   #define _PAGE_BIT_PKEY_BIT0	59	/* Protection Keys, bit 1/4
> > */
> >   #define _PAGE_BIT_PKEY_BIT1	60	/* Protection Keys, bit 2/4
> > */
> >   #define _PAGE_BIT_PKEY_BIT2	61	/* Protection Keys, bit 3/4
> > */
> > @@ -34,6 +35,15 @@
> >   #define _PAGE_BIT_SOFT_DIRTY	_PAGE_BIT_SOFTW3 /* software
> > dirty tracking */
> >   #define _PAGE_BIT_DEVMAP	_PAGE_BIT_SOFTW4
> >   
> > +/*
> > + * Indicates a Saved Dirty bit page.
> > + */
> > +#ifdef CONFIG_X86_USER_SHADOW_STACK
> > +#define _PAGE_BIT_SAVED_DIRTY		_PAGE_BIT_SOFTW5 /*
> > copy-on-write */
> 
> Nope, not "copy-on-write" :) It's more like "dirty bit when the hw-
> dirty 
> bit cannot be used". Maybe simply drop the comment.

Oops, I missed this when I scrubbed _PAGE_COW. Thanks. Will fix.

> 
> > +#else
> > +#define _PAGE_BIT_SAVED_DIRTY		0
> > +#endif
> > +
> >   /* If _PAGE_BIT_PRESENT is clear, we use these: */
> >   /* - if the user mapped it with PROT_NONE; pte_present gives true
> > */
> >   #define _PAGE_BIT_PROTNONE	_PAGE_BIT_GLOBAL
> > @@ -117,6 +127,40 @@
> >   #define _PAGE_SOFTW4	(_AT(pteval_t, 0))
> >   #endif
> >   
> > +/*
> > + * The hardware requires shadow stack to be read-only and Dirty.
> > + * _PAGE_SAVED_DIRTY is a software-only bit used to separate copy-
> > on-write
> > + * PTEs from shadow stack PTEs:
> 
> I'd suggest phrasing this differently. COW is just one scenario
> where 
> this can happen. Also, I don't think that the description of 
> "separation" is correct.
> 
> Something like the following maybe?
> 
> "
> However, there are valid cases where the kernel might create read-
> only 
> PTEs that are dirty (e.g., fork(), mprotect(), uffd-wp(), soft-dirty 
> tracking). In this case, the _PAGE_SAVED_DIRTY bit is used instead
> of 
> the HW-dirty bit, to avoid creating a wrong "shadow stack" PTEs.
> Such 
> PTEs have (Write=0,SavedDirty=1,Dirty=0) set.
> 
> Note that on processors without shadow stack support, the 
> _PAGE_SAVED_DIRTY remains unused.
> "
> 
> The I would simply drop below (which is also too COW-specific I
> think).

COW is the main situation where shadow stacks become read-only. So, as
an example it is nice in that COW covers all the scenarios discussed.
Again, do any x86 maintainers want to weigh in here?

> 
> > + *
> > + * (Write=0,SavedDirty=1,Dirty=0):
> > + *  - A modified, copy-on-write (COW) page. Previously when a
> > typical
> > + *    anonymous writable mapping was made COW via fork(), the
> > kernel would
> > + *    mark it Write=0,Dirty=1. Now it will instead use the Cow
> > bit. This
> > + *    happens in copy_present_pte().
> > + *  - A R/O page that has been COW'ed. The user page is in a R/O
> > VMA,
> > + *    and get_user_pages(FOLL_FORCE) needs a writable copy. The
> > page fault
> > + *    handler creates a copy of the page and sets the new copy's
> > PTE as
> > + *    Write=0 and SavedDirty=1.
> > + *  - A shared shadow stack PTE. When a shadow stack page is being
> > shared
> > + *    among processes (this happens at fork()), its PTE is made
> > Dirty=0, so
> > + *    the next shadow stack access causes a fault, and the page is
> > + *    duplicated and Dirty=1 is set again. This is the COW
> > equivalent for
> > + *    shadow stack pages, even though it's copy-on-access rather
> > than
> > + *    copy-on-write.
> > + *
> > + * (Write=0,SavedDirty=0,Dirty=1):
> > + *  - A shadow stack PTE.
> > + *  - A Cow PTE created when a processor without shadow stack
> > support set
> > + *    Dirty=1.
> > + */
> 
> 

  reply	other threads:[~2023-02-20 21:38 UTC|newest]

Thread overview: 163+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18 21:13 [PATCH v6 00/41] Shadow stacks for userspace Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 01/41] Documentation/x86: Add CET shadow stack description Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 02/41] x86/shstk: Add Kconfig option for shadow stack Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 03/41] x86/cpufeatures: Add CPU feature flags for shadow stacks Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 04/41] x86/cpufeatures: Enable CET CR4 bit for shadow stack Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 05/41] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 06/41] x86/fpu: Add helper for modifying xstate Rick Edgecombe
2023-02-18 21:13 ` [PATCH v6 07/41] x86: Move control protection handler to separate file Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 08/41] x86/shstk: Add user control-protection fault handler Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 09/41] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 10/41] x86/mm: Move pmd_write(), pud_write() up in the file Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 11/41] mm: Introduce pte_mkwrite_kernel() Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-19 20:38   ` Kees Cook
2023-02-19 20:38     ` Kees Cook
2023-02-20 11:17     ` David Hildenbrand
2023-02-20 11:17       ` David Hildenbrand
2023-02-20 11:19   ` David Hildenbrand
2023-02-20 11:19     ` David Hildenbrand
2023-03-01 15:39   ` Deepak Gupta
2023-03-01 15:39     ` Deepak Gupta
2023-02-18 21:14 ` [PATCH v6 12/41] s390/mm: Introduce pmd_mkwrite_kernel() Rick Edgecombe
2023-02-19 20:39   ` Kees Cook
2023-02-20 11:21   ` David Hildenbrand
2023-02-23 12:14   ` Heiko Carstens
2023-02-23 17:59     ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-18 21:14   ` Rick Edgecombe
2023-02-19 20:40   ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-19 20:40   ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-19 20:40     ` Kees Cook
2023-02-20  1:00   ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20  1:00     ` Michael Ellerman
2023-02-20 21:24     ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 21:24       ` Edgecombe, Rick P
2023-02-20 11:23   ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 11:23     ` David Hildenbrand
2023-02-20 22:56     ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-02-20 22:56       ` Edgecombe, Rick P
2023-03-01 15:41   ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-03-01 15:41     ` Deepak Gupta
2023-02-18 21:14 ` [PATCH v6 14/41] x86/mm: Introduce _PAGE_SAVED_DIRTY Rick Edgecombe
2023-02-20 11:32   ` David Hildenbrand
2023-02-20 21:38     ` Edgecombe, Rick P [this message]
2023-02-21  8:38       ` David Hildenbrand
2023-02-21 20:08         ` Edgecombe, Rick P
2023-02-21 20:13         ` Dave Hansen
2023-02-22  1:02           ` Edgecombe, Rick P
2023-02-22  9:05           ` David Hildenbrand
2023-02-22 17:23             ` Dave Hansen
2023-02-22 17:27               ` David Hildenbrand
2023-02-22 17:42                 ` Kees Cook
2023-02-22 17:54                   ` Dave Hansen
2023-02-22 19:39                     ` Kees Cook
2023-02-18 21:14 ` [PATCH v6 15/41] x86/mm: Update ptep/pmdp_set_wrprotect() for _PAGE_SAVED_DIRTY Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 16/41] x86/mm: Start actually marking _PAGE_SAVED_DIRTY Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 17/41] mm: Move VM_UFFD_MINOR_BIT from 37 to 38 Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 18/41] mm: Introduce VM_SHADOW_STACK for shadow stack memory Rick Edgecombe
2023-02-20 12:56   ` David Hildenbrand
2023-02-20 22:08     ` Edgecombe, Rick P
2023-02-21  8:34       ` David Hildenbrand
2023-02-22 22:13         ` Deepak Gupta
2023-02-18 21:14 ` [PATCH v6 19/41] x86/mm: Check shadow stack page fault errors Rick Edgecombe
2023-02-20 12:57   ` David Hildenbrand
2023-02-22 23:07     ` Edgecombe, Rick P
2023-02-23 12:55       ` David Hildenbrand
2023-02-18 21:14 ` [PATCH v6 20/41] x86/mm: Teach pte_mkwrite() about stack memory Rick Edgecombe
2023-02-19 20:41   ` Kees Cook
2023-02-20 22:52     ` Edgecombe, Rick P
2023-03-01 15:42   ` Deepak Gupta
2023-02-18 21:14 ` [PATCH v6 21/41] mm: Add guard pages around a shadow stack Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 22/41] mm/mmap: Add shadow stack pages to memory accounting Rick Edgecombe
2023-02-20 12:58   ` David Hildenbrand
2023-02-20 22:44     ` Edgecombe, Rick P
2023-02-21  8:31       ` David Hildenbrand
2023-02-22  0:06         ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 23/41] mm: Re-introduce vm_flags to do_mmap() Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 24/41] mm: Don't allow write GUPs to shadow stack memory Rick Edgecombe
2023-02-21  8:42   ` David Hildenbrand
2023-02-21 20:02     ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 25/41] x86/mm: Introduce MAP_ABOVE4G Rick Edgecombe
2023-02-19 20:43   ` Kees Cook
2023-02-20 22:38     ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 26/41] mm: Warn on shadow stack memory in wrong vma Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 27/41] x86/mm: Warn if create Write=0,Dirty=1 with raw prot Rick Edgecombe
2023-02-19 20:45   ` Kees Cook
2023-02-20 22:32     ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 28/41] x86: Introduce userspace API for shadow stack Rick Edgecombe
2023-02-24 12:20   ` Borislav Petkov
2023-02-24 18:37     ` Edgecombe, Rick P
2023-02-28 10:58       ` Borislav Petkov
2023-02-28 22:35         ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 29/41] x86/shstk: Add user-mode shadow stack support Rick Edgecombe
2023-02-24 12:22   ` Borislav Petkov
2023-02-24 18:25     ` Edgecombe, Rick P
2023-02-24 18:33       ` Borislav Petkov
2023-02-18 21:14 ` [PATCH v6 30/41] x86/shstk: Handle thread shadow stack Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 31/41] x86/shstk: Introduce routines modifying shstk Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 32/41] x86/shstk: Handle signals for shadow stack Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 33/41] x86/shstk: Introduce map_shadow_stack syscall Rick Edgecombe
2023-02-23  0:03   ` Deepak Gupta
2023-02-23  1:11     ` Edgecombe, Rick P
2023-02-23 21:20       ` Deepak Gupta
2023-02-23 23:42         ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 34/41] x86/shstk: Support WRSS for userspace Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 35/41] x86: Expose thread features in /proc/$PID/status Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 36/41] x86/shstk: Wire in shadow stack interface Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 37/41] selftests/x86: Add shadow stack test Rick Edgecombe
2023-02-19 20:47   ` Kees Cook
2023-02-21  8:48   ` David Hildenbrand
2023-02-21 20:02     ` Edgecombe, Rick P
2023-02-23 13:47   ` Borislav Petkov
2023-02-23 17:54     ` Edgecombe, Rick P
2023-02-24 11:45       ` Borislav Petkov
2023-02-24 18:39         ` Edgecombe, Rick P
2023-02-18 21:14 ` [PATCH v6 38/41] x86/fpu: Add helper for initing features Rick Edgecombe
2023-02-19 20:48   ` Kees Cook
2023-02-18 21:14 ` [PATCH v6 39/41] x86: Add PTRACE interface for shadow stack Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 40/41] x86/shstk: Add ARCH_SHSTK_UNLOCK Rick Edgecombe
2023-02-18 21:14 ` [PATCH v6 41/41] x86/shstk: Add ARCH_SHSTK_STATUS Rick Edgecombe
2023-02-20  3:42 ` [PATCH v6 00/41] Shadow stacks for userspace Kees Cook
2023-02-20 22:54   ` Edgecombe, Rick P
2023-02-20  6:50 ` Mike Rapoport
2023-02-20 21:23   ` Edgecombe, Rick P
2023-02-20 20:22 ` John Allen
2023-02-21  2:38 ` Pengfei Xu
2023-02-22 19:28 ` Borislav Petkov
2023-02-22 19:31   ` Edgecombe, Rick P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f19d7c7ad9f61fa8f6c9bd09d24524dbe17463f.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=bsingharora@gmail.com \
    --cc=christina.schimpe@intel.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=debug@rivosinc.com \
    --cc=dethoma@microsoft.com \
    --cc=eranian@google.com \
    --cc=esyr@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=jannh@google.com \
    --cc=john.allen@amd.com \
    --cc=kcc@google.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=weijiang.yang@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.