All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jann Horn <jannh@google.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	hjl.tools@gmail.com, Jonathan Corbet <corbet@lwn.net>,
	keescook@chromium.org, Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
	ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com
Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW
Date: Fri, 14 Sep 2018 13:39:03 -0700	[thread overview]
Message-ID: <1536957543.12990.9.camel@intel.com> (raw)
In-Reply-To: <20180831162920.GQ24124@hirez.programming.kicks-ass.net>

On Fri, 2018-08-31 at 18:29 +0200, Peter Zijlstra wrote:
> On Fri, Aug 31, 2018 at 08:58:39AM -0700, Dave Hansen wrote:
> > 
> > On 08/31/2018 08:48 AM, Yu-cheng Yu wrote:
> > > 
> > > To trigger a race in ptep_set_wrprotect(), we need to fork from one of
> > > three pthread siblings.
> > > 
> > > Or do we measure only how much this affects fork?
> > > If there is no racing, the effect should be minimal.
> > We don't need a race.
> > 
> > I think the cmpxchg will be slower, even without a race, than the code
> > that was there before.  The cmpxchg is a simple, straightforward
> > solution, but we're putting it in place of a plain memory write, which
> > is suboptimal.
> Note quite, the clear_bit() is LOCK prefixed.

With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow
stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less
efficient than the other.  So can we say this is probably fine in terms of
efficiency?

Yu-cheng




--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1203,7 +1203,36 @@ static inline pte_t ptep_get_and_clear_full(struct
mm_struct *mm,
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pte_t *ptep)
 {
+#ifdef CONFIG_X86_INTEL_SHADOW_STACK_USER
+	pte_t new_pte, pte = READ_ONCE(*ptep);
+
+	/*
+	 * Some processors can start a write, but end up
+	 * seeing a read-only PTE by the time they get
+	 * to the Dirty bit.  In this case, they will
+	 * set the Dirty bit, leaving a read-only, Dirty
+	 * PTE which looks like a Shadow Stack PTE.
+	 *
+	 * However, this behavior has been improved and
+	 * will not occur on processors supporting
+	 * Shadow Stacks.  Without this guarantee, a
+	 * transition to a non-present PTE and flush the
+	 * TLB would be needed.
+	 *
+	 * When changing a writable PTE to read-only and
+	 * if the PTE has _PAGE_DIRTY_HW set, we move
+	 * that bit to _PAGE_DIRTY_SW so that the PTE is
+	 * not a valid Shadow Stack PTE.
+	 */
+	do {
+		new_pte = pte_wrprotect(pte);
+		new_pte.pte |= (new_pte.pte & _PAGE_DIRTY_HW) >>
+				_PAGE_BIT_DIRTY_HW << _PAGE_BIT_DIRTY_SW;
+		new_pte.pte &= ~_PAGE_DIRTY_HW;
+	} while (!try_cmpxchg(ptep, &pte, new_pte));
+#else
 	clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte);
+#endif
 }

WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jann Horn <jannh@google.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	hjl.tools@gmail.com, Jonathan Corbet <corbet@lwn.net>,
	keescook@chromium.org, Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW
Date: Fri, 14 Sep 2018 13:39:03 -0700	[thread overview]
Message-ID: <1536957543.12990.9.camel@intel.com> (raw)
In-Reply-To: <20180831162920.GQ24124@hirez.programming.kicks-ass.net>

On Fri, 2018-08-31 at 18:29 +0200, Peter Zijlstra wrote:
> On Fri, Aug 31, 2018 at 08:58:39AM -0700, Dave Hansen wrote:
> > 
> > On 08/31/2018 08:48 AM, Yu-cheng Yu wrote:
> > > 
> > > To trigger a race in ptep_set_wrprotect(), we need to fork from one of
> > > three pthread siblings.
> > > 
> > > Or do we measure only how much this affects fork?
> > > If there is no racing, the effect should be minimal.
> > We don't need a race.
> > 
> > I think the cmpxchg will be slower, even without a race, than the code
> > that was there before.  The cmpxchg is a simple, straightforward
> > solution, but we're putting it in place of a plain memory write, which
> > is suboptimal.
> Note quite, the clear_bit() is LOCK prefixed.

With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow
stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less
efficient than the other.  So can we say this is probably fine in terms of
efficiency?

Yu-cheng




--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1203,7 +1203,36 @@ static inline pte_t ptep_get_and_clear_full(struct
mm_struct *mm,
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pte_t *ptep)
 {
+#ifdef CONFIG_X86_INTEL_SHADOW_STACK_USER
+	pte_t new_pte, pte = READ_ONCE(*ptep);
+
+	/*
+	 * Some processors can start a write, but end up
+	 * seeing a read-only PTE by the time they get
+	 * to the Dirty bit.  In this case, they will
+	 * set the Dirty bit, leaving a read-only, Dirty
+	 * PTE which looks like a Shadow Stack PTE.
+	 *
+	 * However, this behavior has been improved and
+	 * will not occur on processors supporting
+	 * Shadow Stacks.  Without this guarantee, a
+	 * transition to a non-present PTE and flush the
+	 * TLB would be needed.
+	 *
+	 * When changing a writable PTE to read-only and
+	 * if the PTE has _PAGE_DIRTY_HW set, we move
+	 * that bit to _PAGE_DIRTY_SW so that the PTE is
+	 * not a valid Shadow Stack PTE.
+	 */
+	do {
+		new_pte = pte_wrprotect(pte);
+		new_pte.pte |= (new_pte.pte & _PAGE_DIRTY_HW) >>
+				_PAGE_BIT_DIRTY_HW << _PAGE_BIT_DIRTY_SW;
+		new_pte.pte &= ~_PAGE_DIRTY_HW;
+	} while (!try_cmpxchg(ptep, &pte, new_pte));
+#else
 	clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte);
+#endif
 }

WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jann Horn <jannh@google.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	hjl.tools@gmail.com, Jonathan Corbet <corbet@lwn.net>,
	keescook@chromium.org, Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
	ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com
Subject: Re: [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW
Date: Fri, 14 Sep 2018 13:39:03 -0700	[thread overview]
Message-ID: <1536957543.12990.9.camel@intel.com> (raw)
In-Reply-To: <20180831162920.GQ24124@hirez.programming.kicks-ass.net>

On Fri, 2018-08-31 at 18:29 +0200, Peter Zijlstra wrote:
> On Fri, Aug 31, 2018 at 08:58:39AM -0700, Dave Hansen wrote:
> > 
> > On 08/31/2018 08:48 AM, Yu-cheng Yu wrote:
> > > 
> > > To trigger a race in ptep_set_wrprotect(), we need to fork from one of
> > > three pthread siblings.
> > > 
> > > Or do we measure only how much this affects fork?
> > > If there is no racing, the effect should be minimal.
> > We don't need a race.
> > 
> > I think the cmpxchg will be slower, even without a race, than the code
> > that was there before.A A The cmpxchg is a simple, straightforward
> > solution, but we're putting it in place of a plain memory write, which
> > is suboptimal.
> Note quite, the clear_bit() is LOCK prefixed.

With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow
stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less
efficient than the other. A So can we say this is probably fine in terms of
efficiency?

Yu-cheng




--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1203,7 +1203,36 @@ static inline pte_t ptep_get_and_clear_full(struct
mm_struct *mm,
A static inline void ptep_set_wrprotect(struct mm_struct *mm,
A 				A A A A A A unsigned long addr, pte_t *ptep)
A {
+#ifdef CONFIG_X86_INTEL_SHADOW_STACK_USER
+	pte_t new_pte, pte = READ_ONCE(*ptep);
+
+	/*
+	A * Some processors can start a write, but end up
+	A * seeing a read-only PTE by the time they get
+	A * to the Dirty bit.A A In this case, they will
+	A * set the Dirty bit, leaving a read-only, Dirty
+	A * PTE which looks like a Shadow Stack PTE.
+	A *
+	A * However, this behavior has been improved and
+	A * will not occur on processors supporting
+	A * Shadow Stacks.A A Without this guarantee, a
+	A * transition to a non-present PTE and flush the
+	A * TLB would be needed.
+	A *
+	A * When changing a writable PTE to read-only and
+	A * if the PTE has _PAGE_DIRTY_HW set, we move
+	A * that bit to _PAGE_DIRTY_SW so that the PTE is
+	A * not a valid Shadow Stack PTE.
+	A */
+	do {
+		new_pte = pte_wrprotect(pte);
+		new_pte.pte |= (new_pte.pte & _PAGE_DIRTY_HW) >>
+				_PAGE_BIT_DIRTY_HW << _PAGE_BIT_DIRTY_SW;
+		new_pte.pte &= ~_PAGE_DIRTY_HW;
+	} while (!try_cmpxchg(ptep, &pte, new_pte));
+#else
A 	clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte);
+#endif
A }

  reply	other threads:[~2018-09-14 20:43 UTC|newest]

Thread overview: 167+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 14:38 [RFC PATCH v3 00/24] Control Flow Enforcement: Shadow Stack Yu-cheng Yu
2018-08-30 14:38 ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 01/24] x86/cpufeatures: Add CPUIDs for Control-flow Enforcement Technology (CET) Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 02/24] x86/fpu/xstate: Change some names to separate XSAVES system and user states Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 03/24] x86/fpu/xstate: Enable XSAVES system states Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 04/24] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 05/24] Documentation/x86: Add CET description Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 20:39   ` Pavel Machek
2018-08-30 20:39     ` Pavel Machek
2018-08-30 22:49     ` Yu-cheng Yu
2018-08-30 22:49       ` Yu-cheng Yu
2018-08-30 22:49       ` Yu-cheng Yu
2018-09-14 21:17     ` Yu-cheng Yu
2018-09-14 21:17       ` Yu-cheng Yu
2018-09-14 21:17       ` Yu-cheng Yu
2018-09-03  2:56   ` Randy Dunlap
2018-09-03  2:56     ` Randy Dunlap
2018-08-30 14:38 ` [RFC PATCH v3 06/24] x86/cet: Control protection exception handler Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-31 15:01   ` Jann Horn
2018-08-31 15:01     ` Jann Horn
2018-08-31 16:20     ` Yu-cheng Yu
2018-08-31 16:20       ` Yu-cheng Yu
2018-08-31 16:20       ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 07/24] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 08/24] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 09/24] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 10/24] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 11/24] drm/i915/gvt: Update _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 15:49   ` Jann Horn
2018-08-30 15:49     ` Jann Horn
2018-08-30 16:02     ` Yu-cheng Yu
2018-08-30 16:02       ` Yu-cheng Yu
2018-08-30 16:02       ` Yu-cheng Yu
2018-08-30 16:08     ` Dave Hansen
2018-08-30 16:08       ` Dave Hansen
2018-08-30 16:23       ` Jann Horn
2018-08-30 16:23         ` Jann Horn
2018-08-30 17:19         ` Dave Hansen
2018-08-30 17:19           ` Dave Hansen
2018-08-30 17:26           ` Yu-cheng Yu
2018-08-30 17:26             ` Yu-cheng Yu
2018-08-30 17:26             ` Yu-cheng Yu
2018-08-30 17:33             ` Dave Hansen
2018-08-30 17:33               ` Dave Hansen
2018-08-30 17:54               ` Yu-cheng Yu
2018-08-30 17:54                 ` Yu-cheng Yu
2018-08-30 17:54                 ` Yu-cheng Yu
2018-08-30 17:59                 ` Jann Horn
2018-08-30 17:59                   ` Jann Horn
2018-08-30 20:21                   ` Yu-cheng Yu
2018-08-30 20:21                     ` Yu-cheng Yu
2018-08-30 20:21                     ` Yu-cheng Yu
2018-08-30 20:44                     ` Jann Horn
2018-08-30 20:44                       ` Jann Horn
2018-08-30 20:52                       ` Yu-cheng Yu
2018-08-30 20:52                         ` Yu-cheng Yu
2018-08-30 20:52                         ` Yu-cheng Yu
2018-08-30 21:01                         ` Jann Horn
2018-08-30 21:01                           ` Jann Horn
2018-08-30 21:47                           ` Jann Horn
2018-08-30 21:47                             ` Jann Horn
2018-08-31  9:53                             ` Peter Zijlstra
2018-08-31  9:53                               ` Peter Zijlstra
2018-08-31 14:33                               ` Yu-cheng Yu
2018-08-31 14:33                                 ` Yu-cheng Yu
2018-08-31 14:33                                 ` Yu-cheng Yu
2018-08-31 14:47                                 ` Dave Hansen
2018-08-31 14:47                                   ` Dave Hansen
2018-08-31 15:48                                   ` Yu-cheng Yu
2018-08-31 15:48                                     ` Yu-cheng Yu
2018-08-31 15:48                                     ` Yu-cheng Yu
2018-08-31 15:58                                     ` Dave Hansen
2018-08-31 15:58                                       ` Dave Hansen
2018-08-31 16:29                                       ` Peter Zijlstra
2018-08-31 16:29                                         ` Peter Zijlstra
2018-09-14 20:39                                         ` Yu-cheng Yu [this message]
2018-09-14 20:39                                           ` Yu-cheng Yu
2018-09-14 20:39                                           ` Yu-cheng Yu
2018-09-14 20:46                                           ` Dave Hansen
2018-09-14 20:46                                             ` Dave Hansen
2018-09-14 20:46                                             ` Dave Hansen
2018-09-14 21:08                                             ` Yu-cheng Yu
2018-09-14 21:08                                               ` Yu-cheng Yu
2018-09-14 21:08                                               ` Yu-cheng Yu
2018-09-14 21:33                                               ` Dave Hansen
2018-09-14 21:33                                                 ` Dave Hansen
2018-09-14 21:33                                                 ` Dave Hansen
2018-08-31  1:23                   ` Andy Lutomirski
2018-08-31  1:23                     ` Andy Lutomirski
2018-08-30 17:34           ` Andy Lutomirski
2018-08-30 17:34             ` Andy Lutomirski
2018-08-30 18:55             ` Dave Hansen
2018-08-30 18:55               ` Dave Hansen
2018-08-31 17:46               ` Andy Lutomirski
2018-08-31 17:46                 ` Andy Lutomirski
2018-08-31 17:52                 ` Dave Hansen
2018-08-31 17:52                   ` Dave Hansen
2018-08-31 17:52                   ` Dave Hansen
2018-08-30 19:59   ` Randy Dunlap
2018-08-30 19:59     ` Randy Dunlap
2018-08-30 20:23     ` Yu-cheng Yu
2018-08-30 20:23       ` Yu-cheng Yu
2018-08-30 20:23       ` Yu-cheng Yu
2018-08-31 16:29   ` Dave Hansen
2018-08-31 16:29     ` Dave Hansen
2018-08-30 14:38 ` [RFC PATCH v3 13/24] x86/mm: Shadow stack page fault error checking Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 14/24] mm: Handle shadow stack page fault Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 15/24] mm: Handle THP/HugeTLB " Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 16/24] mm: Update can_follow_write_pte/pmd for shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 17/24] mm: Introduce do_mmap_locked() Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 18/24] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 16:10   ` Jann Horn
2018-08-30 16:10     ` Jann Horn
2018-08-30 16:20     ` Yu-cheng Yu
2018-08-30 16:20       ` Yu-cheng Yu
2018-08-30 16:20       ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 19/24] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 15:39   ` Jann Horn
2018-08-30 15:39     ` Jann Horn
2018-08-30 15:55     ` Andy Lutomirski
2018-08-30 15:55       ` Andy Lutomirski
2018-08-30 16:22       ` Yu-cheng Yu
2018-08-30 16:22         ` Yu-cheng Yu
2018-08-30 16:22         ` Yu-cheng Yu
2018-08-31 21:49         ` Yu-cheng Yu
2018-08-31 21:49           ` Yu-cheng Yu
2018-08-31 21:49           ` Yu-cheng Yu
2018-08-31 22:16           ` Andy Lutomirski
2018-08-31 22:16             ` Andy Lutomirski
2018-09-14 20:46             ` Yu-cheng Yu
2018-09-14 20:46               ` Yu-cheng Yu
2018-09-14 20:46               ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 20/24] x86/cet/shstk: Signal handling for shadow stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 21/24] x86/cet/shstk: ELF header parsing of Shadow Stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 22/24] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 23/24] x86/cet/shstk: Add arch_prctl functions for Shadow Stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 24/24] x86/cet/shstk: Add Shadow Stack instructions to opcode map Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-09-02  8:13 ` [RFC PATCH v3 00/24] Control Flow Enforcement: Shadow Stack Balbir Singh
2018-09-02  8:13   ` Balbir Singh
2018-09-04 14:47   ` Yu-cheng Yu
2018-09-04 14:47     ` Yu-cheng Yu
2018-09-04 14:47     ` Yu-cheng Yu

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=1536957543.12990.9.camel@intel.com \
    --to=yu-cheng.yu@intel.com \
    --cc=arnd@arndb.de \
    --cc=bsingharora@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=fweimer@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --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@amacapital.net \
    --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=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vedvyas.shanbhogue@intel.com \
    --cc=x86@kernel.org \
    /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.