All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Andy Lutomirski <luto@amacapital.net>, Jann Horn <jannh@google.com>
Cc: X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	LKML <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>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Eugene Syromiatnikov <esyr@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	"H. J. Lu" <hjl.tools@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <keescook@chromium.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pave>
Subject: Re: [PATCH v5 07/27] mm/mmap: Create a guard area between VMAs
Date: Fri, 12 Oct 2018 14:49:28 -0700	[thread overview]
Message-ID: <1d293d2fb0df99fdb0048825b4e39640840bfabb.camel@intel.com> (raw)
In-Reply-To: <CALCETrUJ1t_K=FQExa_K0yg+aXkPot6wn6RHBPDc3BsAxtmMBw@mail.gmail.com>

On Thu, 2018-10-11 at 13:55 -0700, Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 1:39 PM Jann Horn <jannh@google.com> wrote:
> > 
> > On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> > > Create a guard area between VMAs to detect memory corruption.
> > 
> > [...]
> > > +config VM_AREA_GUARD
> > > +       bool "VM area guard"
> > > +       default n
> > > +       help
> > > +         Create a guard area between VM areas so that access beyond
> > > +         limit can be detected.
> > > +
> > >  endmenu
> > 
> > Sorry to bring this up so late, but Daniel Micay pointed out to me
> > that, given that VMA guards will raise the number of VMAs by
> > inhibiting vma_merge(), people are more likely to run into
> > /proc/sys/vm/max_map_count (which limits the number of VMAs to ~65k by
> > default, and can't easily be raised without risking an overflow of
> > page->_mapcount on systems with over ~800GiB of RAM, see
> > https://lore.kernel.org/lkml/20180208021112.GB14918@bombadil.infradead.org/
> > and replies) with this change.
> > 
> > Playing with glibc's memory allocator, it looks like glibc will use
> > mmap() for 128KB allocations; so at 65530*128KB=8GB of memory usage in
> > 128KB chunks, an application could run out of VMAs.
> 
> Ugh.
> 
> Do we have a free VM flag so we could do VM_GUARD to force a guard
> page?  (And to make sure that, when a new VMA is allocated, it won't
> be directly adjacent to a VM_GUARD VMA.)

Maybe something like the following?  These vm_start_gap()/vm_end_gap() are used
in many architectures.  Do we want to put them in a different series?  Comments?

Yu-cheng




diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0416a7204be3..92b580542411 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -224,11 +224,13 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HIGH_ARCH_BIT_2	34	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_BIT_3	35	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_BIT_4	36	/* bit only usable on 64-bit
architectures */
+#define VM_HIGH_ARCH_BIT_5	37	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_0	BIT(VM_HIGH_ARCH_BIT_0)
 #define VM_HIGH_ARCH_1	BIT(VM_HIGH_ARCH_BIT_1)
 #define VM_HIGH_ARCH_2	BIT(VM_HIGH_ARCH_BIT_2)
 #define VM_HIGH_ARCH_3	BIT(VM_HIGH_ARCH_BIT_3)
 #define VM_HIGH_ARCH_4	BIT(VM_HIGH_ARCH_BIT_4)
+#define VM_HIGH_ARCH_5	BIT(VM_HIGH_ARCH_BIT_5)
 #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
 
 #ifdef CONFIG_ARCH_HAS_PKEYS
@@ -266,6 +268,12 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_MPX		VM_NONE
 #endif
 
+#ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS
+#define VM_GUARD	VM_HIGH_ARCH_5
+#else
+#define VM_GUARD	VM_NONE
+#endif
+
 #ifndef VM_GROWSUP
 # define VM_GROWSUP	VM_NONE
 #endif
@@ -2417,24 +2425,34 @@ static inline struct vm_area_struct *
find_vma_intersection(struct mm_struct * m
-static inline unsigned long vm_start_gap(struct vm_area_struct *vma)
+static inline unsigned long vm_start_gap(struct vm_area_struct *vma, vm_flags_t
flags)
 {
 	unsigned long vm_start = vma->vm_start;
+	unsigned long gap = 0;
+
+	if (vma->vm_flags & VM_GROWSDOWN)
+		gap = stack_guard_gap;
+	else if ((vma->vm_flags & VM_GUARD) || (flags & VM_GUARD))
+		gap = PAGE_SIZE;
+
+	vm_start -= gap;
+	if (vm_start > vma->vm_start)
+		vm_start = 0;
 
-	if (vma->vm_flags & VM_GROWSDOWN) {
-		vm_start -= stack_guard_gap;
-		if (vm_start > vma->vm_start)
-			vm_start = 0;
-	}
 	return vm_start;
 }
 
-static inline unsigned long vm_end_gap(struct vm_area_struct *vma)
+static inline unsigned long vm_end_gap(struct vm_area_struct *vma, vm_flags_t
flags)
 {
 	unsigned long vm_end = vma->vm_end;
+	unsigned long gap = 0;
+
+	if (vma->vm_flags & VM_GROWSUP)
+		gap = stack_guard_gap;
+	else if ((vma->vm_flags & VM_GUARD) || (flags & VM_GUARD))
+		gap = PAGE_SIZE;
+
+	vm_end += gap;
+	if (vm_end < vma->vm_end)
+		vm_end = -PAGE_SIZE;
 
-	if (vma->vm_flags & VM_GROWSUP) {
-		vm_end += stack_guard_gap;
-		if (vm_end < vma->vm_end)
-			vm_end = -PAGE_SIZE;
-	}
 	return vm_end;
 }

WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Andy Lutomirski <luto@amacapital.net>, Jann Horn <jannh@google.com>
Cc: X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	LKML <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>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Eugene Syromiatnikov <esyr@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	"H. J. Lu" <hjl.tools@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <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>,
	Peter Zijlstra <peterz@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@intel.com>,
	Daniel Micay <danielmicay@gmail.com>
Subject: Re: [PATCH v5 07/27] mm/mmap: Create a guard area between VMAs
Date: Fri, 12 Oct 2018 14:49:28 -0700	[thread overview]
Message-ID: <1d293d2fb0df99fdb0048825b4e39640840bfabb.camel@intel.com> (raw)
Message-ID: <20181012214928.hvcjc9ru2h6OvMaPgx9b-CweOm3S8lvfj1a3U4ft2V0@z> (raw)
In-Reply-To: <CALCETrUJ1t_K=FQExa_K0yg+aXkPot6wn6RHBPDc3BsAxtmMBw@mail.gmail.com>

On Thu, 2018-10-11 at 13:55 -0700, Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 1:39 PM Jann Horn <jannh@google.com> wrote:
> > 
> > On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> > > Create a guard area between VMAs to detect memory corruption.
> > 
> > [...]
> > > +config VM_AREA_GUARD
> > > +       bool "VM area guard"
> > > +       default n
> > > +       help
> > > +         Create a guard area between VM areas so that access beyond
> > > +         limit can be detected.
> > > +
> > >  endmenu
> > 
> > Sorry to bring this up so late, but Daniel Micay pointed out to me
> > that, given that VMA guards will raise the number of VMAs by
> > inhibiting vma_merge(), people are more likely to run into
> > /proc/sys/vm/max_map_count (which limits the number of VMAs to ~65k by
> > default, and can't easily be raised without risking an overflow of
> > page->_mapcount on systems with over ~800GiB of RAM, see
> > https://lore.kernel.org/lkml/20180208021112.GB14918@bombadil.infradead.org/
> > and replies) with this change.
> > 
> > Playing with glibc's memory allocator, it looks like glibc will use
> > mmap() for 128KB allocations; so at 65530*128KB=8GB of memory usage in
> > 128KB chunks, an application could run out of VMAs.
> 
> Ugh.
> 
> Do we have a free VM flag so we could do VM_GUARD to force a guard
> page?  (And to make sure that, when a new VMA is allocated, it won't
> be directly adjacent to a VM_GUARD VMA.)

Maybe something like the following?  These vm_start_gap()/vm_end_gap() are used
in many architectures.  Do we want to put them in a different series?  Comments?

Yu-cheng




diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0416a7204be3..92b580542411 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -224,11 +224,13 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_HIGH_ARCH_BIT_2	34	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_BIT_3	35	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_BIT_4	36	/* bit only usable on 64-bit
architectures */
+#define VM_HIGH_ARCH_BIT_5	37	/* bit only usable on 64-bit
architectures */
 #define VM_HIGH_ARCH_0	BIT(VM_HIGH_ARCH_BIT_0)
 #define VM_HIGH_ARCH_1	BIT(VM_HIGH_ARCH_BIT_1)
 #define VM_HIGH_ARCH_2	BIT(VM_HIGH_ARCH_BIT_2)
 #define VM_HIGH_ARCH_3	BIT(VM_HIGH_ARCH_BIT_3)
 #define VM_HIGH_ARCH_4	BIT(VM_HIGH_ARCH_BIT_4)
+#define VM_HIGH_ARCH_5	BIT(VM_HIGH_ARCH_BIT_5)
 #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
 
 #ifdef CONFIG_ARCH_HAS_PKEYS
@@ -266,6 +268,12 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_MPX		VM_NONE
 #endif
 
+#ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS
+#define VM_GUARD	VM_HIGH_ARCH_5
+#else
+#define VM_GUARD	VM_NONE
+#endif
+
 #ifndef VM_GROWSUP
 # define VM_GROWSUP	VM_NONE
 #endif
@@ -2417,24 +2425,34 @@ static inline struct vm_area_struct *
find_vma_intersection(struct mm_struct * m
-static inline unsigned long vm_start_gap(struct vm_area_struct *vma)
+static inline unsigned long vm_start_gap(struct vm_area_struct *vma, vm_flags_t
flags)
 {
 	unsigned long vm_start = vma->vm_start;
+	unsigned long gap = 0;
+
+	if (vma->vm_flags & VM_GROWSDOWN)
+		gap = stack_guard_gap;
+	else if ((vma->vm_flags & VM_GUARD) || (flags & VM_GUARD))
+		gap = PAGE_SIZE;
+
+	vm_start -= gap;
+	if (vm_start > vma->vm_start)
+		vm_start = 0;
 
-	if (vma->vm_flags & VM_GROWSDOWN) {
-		vm_start -= stack_guard_gap;
-		if (vm_start > vma->vm_start)
-			vm_start = 0;
-	}
 	return vm_start;
 }
 
-static inline unsigned long vm_end_gap(struct vm_area_struct *vma)
+static inline unsigned long vm_end_gap(struct vm_area_struct *vma, vm_flags_t
flags)
 {
 	unsigned long vm_end = vma->vm_end;
+	unsigned long gap = 0;
+
+	if (vma->vm_flags & VM_GROWSUP)
+		gap = stack_guard_gap;
+	else if ((vma->vm_flags & VM_GUARD) || (flags & VM_GUARD))
+		gap = PAGE_SIZE;
+
+	vm_end += gap;
+	if (vm_end < vma->vm_end)
+		vm_end = -PAGE_SIZE;
 
-	if (vma->vm_flags & VM_GROWSUP) {
-		vm_end += stack_guard_gap;
-		if (vm_end < vma->vm_end)
-			vm_end = -PAGE_SIZE;
-	}
 	return vm_end;
 }

  reply	other threads:[~2018-10-12 21:49 UTC|newest]

Thread overview: 161+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 15:14 [PATCH v5 00/27] Control Flow Enforcement: Shadow Stack Yu-cheng Yu
2018-10-11 15:14 ` Yu-cheng Yu
2018-10-11 15:14 ` [PATCH v5 01/27] x86/cpufeatures: Add CPUIDs for Control Flow Enforcement Technology (CET) Yu-cheng Yu
2018-10-11 15:14   ` Yu-cheng Yu
2018-10-11 16:43   ` Borislav Petkov
2018-10-11 16:43     ` Borislav Petkov
2018-10-11 16:45     ` Yu-cheng Yu
2018-10-11 16:45       ` Yu-cheng Yu
2018-10-11 15:14 ` [PATCH v5 02/27] x86/fpu/xstate: Change names to separate XSAVES system and user states Yu-cheng Yu
2018-10-11 15:14   ` Yu-cheng Yu
2018-10-15 17:03   ` Borislav Petkov
2018-10-15 17:03     ` Borislav Petkov
2018-10-11 15:14 ` [PATCH v5 03/27] x86/fpu/xstate: Introduce XSAVES system states Yu-cheng Yu
2018-10-11 15:14   ` Yu-cheng Yu
2018-10-17 10:41   ` Borislav Petkov
2018-10-17 10:41     ` Borislav Petkov
2018-10-17 22:39     ` Randy Dunlap
2018-10-17 22:39       ` Randy Dunlap
2018-10-17 22:58       ` Borislav Petkov
2018-10-17 22:58         ` Borislav Petkov
2018-10-17 23:17         ` Randy Dunlap
2018-10-17 23:17           ` Randy Dunlap
2018-10-18  9:26           ` Borislav Petkov
2018-10-18  9:26             ` Borislav Petkov
2018-10-18  9:31             ` Pavel Machek
2018-10-18  9:31               ` Pavel Machek
2018-10-18 12:10               ` Borislav Petkov
2018-10-18 12:10                 ` Borislav Petkov
2018-10-18 18:33             ` Randy Dunlap
2018-10-18 18:33               ` Randy Dunlap
2018-10-18  9:24         ` Pavel Machek
2018-10-18  9:24           ` Pavel Machek
2018-10-11 15:15 ` [PATCH v5 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-11-08 18:40   ` Borislav Petkov
2018-11-08 18:40     ` Borislav Petkov
2018-11-08 20:40     ` Yu-cheng Yu
2018-11-08 20:40       ` Yu-cheng Yu
2018-11-08 23:52       ` Borislav Petkov
2018-11-08 23:52         ` Borislav Petkov
2018-11-11 11:31       ` Pavel Machek
2018-11-11 11:31         ` Pavel Machek
2018-11-11 11:31     ` Pavel Machek
2018-11-11 11:31       ` Pavel Machek
2018-11-11 14:59       ` Andy Lutomirski
2018-11-11 14:59         ` Andy Lutomirski
2018-11-11 19:02         ` Pavel Machek
2018-11-11 19:02           ` Pavel Machek
2018-11-08 20:46   ` Andy Lutomirski
2018-11-08 20:46     ` Andy Lutomirski
2018-11-08 21:01     ` Yu-cheng Yu
2018-11-08 21:01       ` Yu-cheng Yu
2018-11-08 21:22       ` Andy Lutomirski
2018-11-08 21:22         ` Andy Lutomirski
2018-11-08 21:31         ` Cyrill Gorcunov
2018-11-08 21:31           ` Cyrill Gorcunov
2018-11-08 22:01           ` Andy Lutomirski
2018-11-08 22:01             ` Andy Lutomirski
2018-11-08 22:18             ` Cyrill Gorcunov
2018-11-08 22:18               ` Cyrill Gorcunov
2018-11-08 21:48         ` Dave Hansen
2018-11-08 21:48           ` Dave Hansen
2018-11-08 22:00           ` Matthew Wilcox
2018-11-08 22:00             ` Matthew Wilcox
2018-11-08 23:35             ` Dave Hansen
2018-11-08 23:35               ` Dave Hansen
2018-11-09  0:32               ` Matthew Wilcox
2018-11-09  0:32                 ` Matthew Wilcox
2018-11-09  0:45                 ` Andy Lutomirski
2018-11-09  0:45                   ` Andy Lutomirski
2018-11-09 17:13                 ` Dave Hansen
2018-11-09 17:13                   ` Dave Hansen
2018-11-09 17:17                   ` Matthew Wilcox
2018-11-09 17:17                     ` Matthew Wilcox
2018-11-09 17:20                     ` Dave Hansen
2018-11-09 17:20                       ` Dave Hansen
2018-11-09 17:28                       ` Dave Hansen
2018-11-09 17:28                         ` Dave Hansen
2018-11-11 11:31         ` Pavel Machek
2018-11-11 11:31           ` Pavel Machek
2018-10-11 15:15 ` [PATCH v5 05/27] Documentation/x86: Add CET description Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-11-13 18:43   ` Borislav Petkov
2018-11-13 18:43     ` Borislav Petkov
2018-11-13 21:02     ` Yu-cheng Yu
2018-11-13 21:02       ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 06/27] x86/cet: Control protection exception handler Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-11-14 18:44   ` Borislav Petkov
2018-11-14 18:44     ` Borislav Petkov
2018-11-14 18:44     ` Borislav Petkov
2018-11-14 20:19     ` Yu-cheng Yu
2018-11-14 20:19       ` Yu-cheng Yu
2018-11-14 20:28       ` Borislav Petkov
2018-11-14 20:28         ` Borislav Petkov
2018-10-11 15:15 ` [PATCH v5 07/27] mm/mmap: Create a guard area between VMAs Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 20:39   ` Jann Horn
2018-10-11 20:39     ` Jann Horn
2018-10-11 20:49     ` Yu-cheng Yu
2018-10-11 20:49       ` Yu-cheng Yu
2018-10-11 20:55     ` Andy Lutomirski
2018-10-11 20:55       ` Andy Lutomirski
2018-10-12 21:49       ` Yu-cheng Yu [this message]
2018-10-12 21:49         ` Yu-cheng Yu
2018-10-12 13:17     ` Matthew Wilcox
2018-10-12 13:17       ` Matthew Wilcox
2018-10-11 20:49   ` Dave Hansen
2018-10-11 20:49     ` Dave Hansen
2018-10-12 10:24     ` Florian Weimer
2018-10-12 10:24       ` Florian Weimer
2018-10-11 15:15 ` [PATCH v5 08/27] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 09/27] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 10/27] mm/mmap: Prevent Shadow Stack VMA merges Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 11/27] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 12/27] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 13/27] drm/i915/gvt: Update _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 14/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 15/27] x86/mm: Shadow stack page fault error checking Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 16/27] mm: Handle shadow stack page fault Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 17/27] mm: Handle THP/HugeTLB " Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 18/27] mm: Update can_follow_write_pte/pmd for shadow stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 19/27] mm: Introduce do_mmap_locked() Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 20/27] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 21/27] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-11-06 18:43   ` Dave Hansen
2018-11-06 18:43     ` Dave Hansen
2018-11-06 18:55     ` Andy Lutomirski
2018-11-06 18:55       ` Andy Lutomirski
2018-11-06 20:21     ` Yu-cheng Yu
2018-11-06 20:21       ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 22/27] x86/cet/shstk: Signal handling for shadow stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 23/27] x86/cet/shstk: ELF header parsing of Shadow Stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 24/27] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 25/27] mm/mmap: Add Shadow stack pages to memory accounting Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 26/27] x86/cet/shstk: Add arch_prctl functions for Shadow Stack Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 15:15 ` [PATCH v5 27/27] x86/cet/shstk: Add Shadow Stack instructions to opcode map Yu-cheng Yu
2018-10-11 15:15   ` Yu-cheng Yu
2018-10-11 19:21 ` [PATCH v5 00/27] Control Flow Enforcement: Shadow Stack Dave Hansen
2018-10-11 19:21   ` Dave Hansen
2018-10-11 19:29   ` Yu-cheng Yu
2018-10-11 19:29     ` 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=1d293d2fb0df99fdb0048825b4e39640840bfabb.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=esyr@redhat.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=tglx@linutronix.de \
    --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.