From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@kernel.org>,
Balbir Singh <bsingharora@gmail.com>,
Borislav Petkov <bp@alien8.de>,
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>, Jann Horn <jannh@google.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>,
Weijiang Yang <weijiang.yang@intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
John Allen <john.allen@amd.com>,
kcc@google.com, eranian@google.com, rppt@kernel.org,
jamorris@linux.microsoft.com, dethoma@microsoft.com,
akpm@linux-foundation.org, Andrew.Cooper3@citrix.com,
christina.schimpe@intel.com, david@redhat.com,
debug@rivosinc.com, szabolcs.nagy@arm.com,
torvalds@linux-foundation.org, broonie@kernel.org
Cc: rick.p.edgecombe@intel.com
Subject: [PATCH v9 00/42] Shadow stacks for userspace
Date: Mon, 12 Jun 2023 17:10:26 -0700 [thread overview]
Message-ID: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> (raw)
Hi,
This series implements Shadow Stacks for userspace using x86's Control-flow
Enforcement Technology (CET). CET consists of two related security
features: shadow stacks and indirect branch tracking. This series
implements just the shadow stack part of this feature, and just for
userspace.
The main use case for shadow stack is providing protection against return
oriented programming attacks. It works by maintaining a secondary (shadow)
stack using a special memory type that has protections against
modification. When executing a CALL instruction, the processor pushes the
return address to both the normal stack and to the special permission
shadow stack. Upon RET, the processor pops the shadow stack copy and
compares it to the normal stack copy. For more details, see the
coverletter from v1 [0].
Shadow Stack was rejected by Linus for 6.4 [1][2]. This is a new version
that addresses his concerns. In the months since the series was queued in
tip, there were also some non-critical things that turned up, that I was
planning do as fast follow ups. Since we are doing a re-spin, I thought to
just include them in the initial series. (see 3 and 4) Also, the whole
series has been re-ordered, after some comments from Linus prompted some
reflection.
Most of the patches are the same, so I’ll specifically list the patches
with changes to help focus review.
1. Redo of the pte_mkwrite() refactoring patches
------------------------------------------------
The point of these patches was to make pte_mkwrite() take a VMA.
Unfortunately the original version of this refactor had a bug. Linus
suggested an alternate way of doing the refactor that would be less error
prone. It sounds like this will be used by the riscv and possibly arm
shadow stack features. It would be great to collect some Reviewed-by tags
on these from anyone else that would depend on them.
Changed (and renamed) patches:
mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
mm: Move pte/pmd_mkwrite() callers with no VMA to _novma()
mm: Make pte_mkwrite() take a VMA
2. SavedDirty overhaul
----------------------
The Shadow Stack PTEs are defined by the HW as Write=0,Dirty=1. Since
Linux usually creates PTEs like that when it write-protects dirty memory,
the series introduced a SavedDirty software bit. When a PTE gets
write-protected the Dirty bit shifts to the SavedDirty bit so it won't
become shadow stack. When it is made writable, the opposite happens.
In the previously queued version, the SavedDirty bit was only used when
shadow stack was configured and available on the CPU. But this created two
versions of the Dirty bit behavior on x86, adding complexity. Linus
objected to this, and also the use of conditional control flow logic
instead of bit math. After some trial and error, I ended up with something
that tries to incorporate the feedback, but with some adjustments on the
specifics. I would like some feedback on the maintainability tradeoffs
taken and some scrutiny on the correctness as well.
First of all, switching to bit math for the SavedDirty dance really seems
to be a big improvement. The conditional part is now branchless and
isolated to two functions. Descriptions of the other changes follows, and
a little less of a clear win to me.
One thing that came up in this discussion was the performance impact of
the CMPXCHG loop added to ptep_set_wrprotect() in order to atomically do
the shift of Dirty to SavedDirty when a live PTE is being write-protected.
The concern was that this could impact the performance of fork() where it
is used to write-protect memory in the parent MM.
Linus had suggested to optimize the single threaded fork case to offset
the concerns of a performance impact. However, trying to stress this case,
I was unable to concoct a microbenchmark to show any slowdown of the LOCK
CMPXCHG loop vs the original LOCK AND. Hypothetically the CMPXCHG could
scale worse, but since I couldn’t actually entice it to show any slowdown,
I was thinking that the original worries might have been misplaced and we
could get away with the unconditional CMPXCHG loop.
As Dave previously mentioned, the other wrinkle in all of this is that on
CPUs that don’t support shadow stack, a CPU could rarely set Dirty=1 on a
PTE with Write=0. So the kernel logic needs to be robust to PTEs that have
Write=0,Dirty=1 PTEs in non-shadow stack cases on these CPUs. And also
should be able to handle Write=0,Dirty=1,SavedDirty=1 PTEs. Similarly, a
KNL (Xeon Phi platform) erratum can result in Dirty=1 bits getting set on
Present=0 PTEs.
In order to make the core-MM logic work correctly with shadow stack,
pte_write() needs to also return true for Write=0,Dirty=1 memory. Since
those older platforms can cause Dirty=1,Write=0 PTEs despite the kernels
efforts to not create any itself, the kernel can’t have this shadow stack
pte_write() logic when running on them. So the kernel can only check for
shadow stack memory in pte_write() when shadow stack is supported by the
CPU. Also, the kernel needs to make sure to not trigger any warnings when
it sees a Dirty=0,Write=1 PTE in an unexpected place. So these are also
only done when shadow stack is supported on the CPU. These checks are
isolated to single place in pte_shstk().
So in the end, we can shift the Dirty bit around unconditionally, but the
kernels behavior around the Dirty bit still needs to adjust depending on
the CPU actually supporting shadow stack.
Refactoring the SavedDirty<->Dirty setting logic into bitmath made it so
it would be a lot easier to compile the SavedDirty bit out if needed.
Basically it can be removed with only two checks in
mksaveddirty_shift()/clear_saveddirty_shift() (see “x86/mm: Introduce
_PAGE_SAVED_DIRTY”).
That all makes me wonder if it would still be better to disable SavedDirty
when shadow stack is not supported. One aspect of the idea to make
SavedDirty unconditional, was to unify the sets of rules to have to
reason about. But due to the behavior of the pre-shadow stack CPUs, this
also comes at the increased runtime behaviors we need to worry about. The
other point brought up was the increased testing of having SavedDirty used
more widely. But since we have to turn off the warnings and other logic,
this testing isn’t fully happening on these older platforms either. So I’m
not sure if the unconditional SavedDirty is really a win or not. I thought
it was slightly.
So in this version SavedDirty is turned on universally for x86. Even for
32 bit, which, while seeming a bit silly, allows there to be only one
version of the ptep_set_wrprotect() logic.
Changed patches:
x86/mm: Start actually marking _PAGE_SAVED_DIRTY
x86/mm: Update ptep/pmdp_set_wrprotect() for _PAGE_SAVED_DIRTY
x86/mm: Introduce _PAGE_SAVED_DIRTY
mm: Warn on shadow stack memory in wrong vma
x86/mm: Warn if create Write=0,Dirty=1 with raw prot
3. Shadow stack protections enhancements
----------------------------------------
The shadow stack signal frame format uses a special shadow stack frame
pattern that should not occur naturally in order to avoid forgery on
sigreturn. Two patches are added to strengthen the forgery checks. These
could have been squashed into the signal patch, but I thought leaving them
separate might make review easier for those familiar with the last series.
I was waffling on whether to postpone them to minimize changes from the
previously queued changed to v9. In the end, as long as the series was
already getting re-spun, I thought the extra protections were worth
starting with.
The new mmap maple tree code needs to be taught specifically about
VM_SHADOW_STACK, instead of just relying on vm_start_gap() like the old RB
stuff, so that is added as well to retain the start guard gap with maple
tree.
Added/changes patches:
x86/shstk: Check that SSP is aligned on sigreturn
x86/shstk: Check that signal frame is shadow stack mem
mm: Add guard pages around a shadow stack
4. Selftest enhancements
------------------------
A few miscellaneous selftest enhancements that accumulated since the old
series landed in tip. Added a test for the shadow stack guard gap and the
shadow stack ptrace interface. Also fixed a race that caused the uffd test
to sometimes hang.
Changed patches:
selftests/x86: Add shadow stack test
Since some of the changes were extensive in the modified patches, I
dropped some review tags. But I left testing tags, testers please retest.
Thanks,
Rick
[0] https://lore.kernel.org/lkml/20220130211838.8382-1-rick.p.edgecombe@intel.com/
[1] https://lore.kernel.org/lkml/CAHk-=wiuVXTfgapmjYQvrEDzn3naF2oYnHuky+feEJSj_G_yFQ@mail.gmail.com/
[2] https://lore.kernel.org/lkml/CAHk-=wiB0wy6oXOsPtYU4DSbqJAY8z5iNBKdjdOp2LP23khUoA@mail.gmail.com/
Mike Rapoport (1):
x86/shstk: Add ARCH_SHSTK_UNLOCK
Rick Edgecombe (38):
mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
mm: Move pte/pmd_mkwrite() callers with no VMA to _novma()
mm: Make pte_mkwrite() take a VMA
x86/shstk: Add Kconfig option for shadow stack
x86/traps: Move control protection handler to separate file
x86/cpufeatures: Add CPU feature flags for shadow stacks
x86/mm: Move pmd_write(), pud_write() up in the file
x86/mm: Introduce _PAGE_SAVED_DIRTY
x86/mm: Update ptep/pmdp_set_wrprotect() for _PAGE_SAVED_DIRTY
x86/mm: Start actually marking _PAGE_SAVED_DIRTY
x86/mm: Remove _PAGE_DIRTY from kernel RO pages
x86/mm: Check shadow stack page fault errors
mm: Add guard pages around a shadow stack.
mm: Warn on shadow stack memory in wrong vma
x86/mm: Warn if create Write=0,Dirty=1 with raw prot
mm/mmap: Add shadow stack pages to memory accounting
x86/mm: Introduce MAP_ABOVE4G
x86/mm: Teach pte_mkwrite() about stack memory
mm: Don't allow write GUPs to shadow stack memory
Documentation/x86: Add CET shadow stack description
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
x86/fpu: Add helper for modifying xstate
x86: Introduce userspace API for shadow stack
x86/shstk: Add user control-protection fault handler
x86/shstk: Add user-mode shadow stack support
x86/shstk: Handle thread shadow stack
x86/shstk: Introduce routines modifying shstk
x86/shstk: Handle signals for shadow stack
x86/shstk: Check that SSP is aligned on sigreturn
x86/shstk: Check that signal frame is shadow stack mem
x86/shstk: Introduce map_shadow_stack syscall
x86/shstk: Support WRSS for userspace
x86: Expose thread features in /proc/$PID/status
x86/shstk: Wire in shadow stack interface
x86/cpufeatures: Enable CET CR4 bit for shadow stack
selftests/x86: Add shadow stack test
x86: Add PTRACE interface for shadow stack
x86/shstk: Add ARCH_SHSTK_STATUS
Yu-cheng Yu (3):
mm: Re-introduce vm_flags to do_mmap()
mm: Move VM_UFFD_MINOR_BIT from 37 to 38
mm: Introduce VM_SHADOW_STACK for shadow stack memory
Documentation/arch/x86/index.rst | 1 +
Documentation/arch/x86/shstk.rst | 179 ++++
Documentation/filesystems/proc.rst | 1 +
Documentation/mm/arch_pgtable_helpers.rst | 12 +-
arch/Kconfig | 3 +
arch/alpha/include/asm/pgtable.h | 2 +-
arch/arc/include/asm/hugepage.h | 2 +-
arch/arc/include/asm/pgtable-bits-arcv2.h | 2 +-
arch/arm/include/asm/pgtable-3level.h | 2 +-
arch/arm/include/asm/pgtable.h | 2 +-
arch/arm/kernel/signal.c | 2 +-
arch/arm64/include/asm/pgtable.h | 4 +-
arch/arm64/kernel/signal.c | 2 +-
arch/arm64/kernel/signal32.c | 2 +-
arch/arm64/mm/trans_pgd.c | 4 +-
arch/csky/include/asm/pgtable.h | 2 +-
arch/hexagon/include/asm/pgtable.h | 2 +-
arch/ia64/include/asm/pgtable.h | 2 +-
arch/loongarch/include/asm/pgtable.h | 4 +-
arch/m68k/include/asm/mcf_pgtable.h | 2 +-
arch/m68k/include/asm/motorola_pgtable.h | 2 +-
arch/m68k/include/asm/sun3_pgtable.h | 2 +-
arch/microblaze/include/asm/pgtable.h | 2 +-
arch/mips/include/asm/pgtable.h | 6 +-
arch/nios2/include/asm/pgtable.h | 2 +-
arch/openrisc/include/asm/pgtable.h | 2 +-
arch/parisc/include/asm/pgtable.h | 2 +-
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
arch/powerpc/include/asm/nohash/32/pgtable.h | 4 +-
arch/powerpc/include/asm/nohash/32/pte-8xx.h | 4 +-
arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
arch/riscv/include/asm/pgtable.h | 6 +-
arch/s390/include/asm/hugetlb.h | 2 +-
arch/s390/include/asm/pgtable.h | 4 +-
arch/s390/mm/pageattr.c | 4 +-
arch/sh/include/asm/pgtable_32.h | 4 +-
arch/sparc/include/asm/pgtable_32.h | 2 +-
arch/sparc/include/asm/pgtable_64.h | 6 +-
arch/sparc/kernel/signal32.c | 2 +-
arch/sparc/kernel/signal_64.c | 2 +-
arch/um/include/asm/pgtable.h | 2 +-
arch/x86/Kconfig | 24 +
arch/x86/Kconfig.assembler | 5 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/disabled-features.h | 16 +-
arch/x86/include/asm/fpu/api.h | 9 +
arch/x86/include/asm/fpu/regset.h | 7 +-
arch/x86/include/asm/fpu/sched.h | 3 +-
arch/x86/include/asm/fpu/types.h | 16 +-
arch/x86/include/asm/fpu/xstate.h | 6 +-
arch/x86/include/asm/idtentry.h | 2 +-
arch/x86/include/asm/mmu_context.h | 2 +
arch/x86/include/asm/pgtable.h | 302 +++++-
arch/x86/include/asm/pgtable_types.h | 46 +-
arch/x86/include/asm/processor.h | 8 +
arch/x86/include/asm/shstk.h | 38 +
arch/x86/include/asm/special_insns.h | 13 +
arch/x86/include/asm/tlbflush.h | 3 +-
arch/x86/include/asm/trap_pf.h | 2 +
arch/x86/include/asm/traps.h | 12 +
arch/x86/include/uapi/asm/mman.h | 4 +
arch/x86/include/uapi/asm/prctl.h | 12 +
arch/x86/kernel/Makefile | 4 +
arch/x86/kernel/cet.c | 152 +++
arch/x86/kernel/cpu/common.c | 35 +-
arch/x86/kernel/cpu/cpuid-deps.c | 1 +
arch/x86/kernel/cpu/proc.c | 23 +
arch/x86/kernel/fpu/core.c | 54 +-
arch/x86/kernel/fpu/regset.c | 81 ++
arch/x86/kernel/fpu/xstate.c | 90 +-
arch/x86/kernel/idt.c | 2 +-
arch/x86/kernel/process.c | 21 +-
arch/x86/kernel/process_64.c | 8 +
arch/x86/kernel/ptrace.c | 12 +
arch/x86/kernel/shstk.c | 529 +++++++++++
arch/x86/kernel/signal.c | 1 +
arch/x86/kernel/signal_32.c | 2 +-
arch/x86/kernel/signal_64.c | 8 +-
arch/x86/kernel/sys_x86_64.c | 6 +-
arch/x86/kernel/traps.c | 87 --
arch/x86/mm/fault.c | 22 +
arch/x86/mm/pat/set_memory.c | 4 +-
arch/x86/mm/pgtable.c | 40 +
arch/x86/xen/enlighten_pv.c | 2 +-
arch/x86/xen/mmu_pv.c | 2 +-
arch/x86/xen/xen-asm.S | 2 +-
arch/xtensa/include/asm/pgtable.h | 2 +-
fs/aio.c | 2 +-
fs/proc/array.c | 6 +
fs/proc/task_mmu.c | 3 +
include/asm-generic/hugetlb.h | 2 +-
include/linux/mm.h | 67 +-
include/linux/mman.h | 4 +
include/linux/pgtable.h | 28 +
include/linux/proc_fs.h | 2 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/siginfo.h | 3 +-
include/uapi/asm-generic/unistd.h | 2 +-
include/uapi/linux/elf.h | 2 +
ipc/shm.c | 2 +-
kernel/sys_ni.c | 1 +
mm/debug_vm_pgtable.c | 12 +-
mm/gup.c | 2 +-
mm/huge_memory.c | 11 +-
mm/internal.h | 4 +-
mm/memory.c | 5 +-
mm/migrate.c | 2 +-
mm/migrate_device.c | 2 +-
mm/mmap.c | 14 +-
mm/mprotect.c | 2 +-
mm/nommu.c | 4 +-
mm/userfaultfd.c | 2 +-
mm/util.c | 2 +-
tools/testing/selftests/x86/Makefile | 2 +-
.../testing/selftests/x86/test_shadow_stack.c | 884 ++++++++++++++++++
117 files changed, 2789 insertions(+), 307 deletions(-)
create mode 100644 Documentation/arch/x86/shstk.rst
create mode 100644 arch/x86/include/asm/shstk.h
create mode 100644 arch/x86/kernel/cet.c
create mode 100644 arch/x86/kernel/shstk.c
create mode 100644 tools/testing/selftests/x86/test_shadow_stack.c
--
2.34.1
next reply other threads:[~2023-06-13 0:12 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 0:10 Rick Edgecombe [this message]
2023-06-13 0:10 ` [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma() Rick Edgecombe
2023-06-13 7:19 ` Geert Uytterhoeven
2023-06-13 16:14 ` Edgecombe, Rick P
2023-06-13 7:43 ` Mike Rapoport
2023-06-13 16:14 ` Edgecombe, Rick P
2023-06-13 12:26 ` David Hildenbrand
2023-06-13 16:14 ` Edgecombe, Rick P
2023-07-14 22:57 ` Mark Brown
2023-07-17 15:55 ` Edgecombe, Rick P
2023-07-17 16:51 ` Mark Brown
2023-06-13 0:10 ` [PATCH v9 02/42] mm: Move pte/pmd_mkwrite() callers with no VMA to _novma() Rick Edgecombe
2023-06-13 7:44 ` Mike Rapoport
2023-06-13 16:19 ` Edgecombe, Rick P
2023-06-13 17:00 ` David Hildenbrand
2023-06-14 17:00 ` Edgecombe, Rick P
2023-06-13 12:27 ` David Hildenbrand
2023-06-13 16:20 ` Edgecombe, Rick P
2023-06-13 0:10 ` [PATCH v9 03/42] mm: Make pte_mkwrite() take a VMA Rick Edgecombe
2023-06-13 7:42 ` Mike Rapoport
2023-06-13 16:20 ` Edgecombe, Rick P
2023-06-13 12:28 ` David Hildenbrand
2023-06-13 16:21 ` Edgecombe, Rick P
2023-06-13 0:10 ` [PATCH v9 04/42] mm: Re-introduce vm_flags to do_mmap() Rick Edgecombe
2023-06-14 8:49 ` David Hildenbrand
2023-06-14 23:30 ` Mark Brown
2023-06-13 0:10 ` [PATCH v9 05/42] mm: Move VM_UFFD_MINOR_BIT from 37 to 38 Rick Edgecombe
2023-06-14 8:50 ` David Hildenbrand
2023-06-13 0:10 ` [PATCH v9 06/42] x86/shstk: Add Kconfig option for shadow stack Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 07/42] x86/traps: Move control protection handler to separate file Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 08/42] x86/cpufeatures: Add CPU feature flags for shadow stacks Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 09/42] x86/mm: Move pmd_write(), pud_write() up in the file Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 10/42] x86/mm: Introduce _PAGE_SAVED_DIRTY Rick Edgecombe
2023-06-13 16:01 ` Edgecombe, Rick P
2023-06-13 17:58 ` Linus Torvalds
2023-06-13 19:37 ` Edgecombe, Rick P
2023-06-13 0:10 ` [PATCH v9 11/42] x86/mm: Update ptep/pmdp_set_wrprotect() for _PAGE_SAVED_DIRTY Rick Edgecombe
2023-06-13 18:01 ` Linus Torvalds
2023-06-13 0:10 ` [PATCH v9 12/42] x86/mm: Start actually marking _PAGE_SAVED_DIRTY Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 13/42] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 14/42] mm: Introduce VM_SHADOW_STACK for shadow stack memory Rick Edgecombe
2023-06-14 8:50 ` David Hildenbrand
2023-06-14 23:31 ` Mark Brown
2023-06-13 0:10 ` [PATCH v9 15/42] x86/mm: Check shadow stack page fault errors Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 16/42] mm: Add guard pages around a shadow stack Rick Edgecombe
2023-06-14 23:34 ` Mark Brown
2023-06-22 18:21 ` Matthew Wilcox
2023-06-22 18:27 ` Edgecombe, Rick P
2023-06-23 7:40 ` Mike Rapoport
2023-06-23 12:17 ` Mark Brown
2023-06-25 16:44 ` Edgecombe, Rick P
2023-06-26 12:45 ` Mark Brown
2023-07-06 23:32 ` [PATCH] x86/shstk: Move arch detail comment out of core mm Rick Edgecombe
2023-07-07 15:08 ` Mark Brown
2023-08-01 16:52 ` Mike Rapoport
2023-06-13 0:10 ` [PATCH v9 17/42] mm: Warn on shadow stack memory in wrong vma Rick Edgecombe
2023-06-14 23:35 ` Mark Brown
2023-06-13 0:10 ` [PATCH v9 18/42] x86/mm: Warn if create Write=0,Dirty=1 with raw prot Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 19/42] mm/mmap: Add shadow stack pages to memory accounting Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 20/42] x86/mm: Introduce MAP_ABOVE4G Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 21/42] x86/mm: Teach pte_mkwrite() about stack memory Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 22/42] mm: Don't allow write GUPs to shadow " Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 23/42] Documentation/x86: Add CET shadow stack description Rick Edgecombe
2023-06-13 11:55 ` Mark Brown
2023-06-13 12:37 ` Florian Weimer
2023-06-13 15:15 ` Mark Brown
2023-06-13 17:11 ` Edgecombe, Rick P
2023-06-13 17:57 ` Mark Brown
2023-06-13 19:57 ` Edgecombe, Rick P
2023-06-14 10:43 ` szabolcs.nagy
2023-06-14 16:57 ` Edgecombe, Rick P
2023-06-19 8:47 ` szabolcs.nagy
2023-06-19 16:44 ` Edgecombe, Rick P
2023-06-20 9:17 ` szabolcs.nagy
2023-06-20 19:34 ` Edgecombe, Rick P
2023-06-21 11:36 ` szabolcs.nagy
2023-06-21 18:54 ` Edgecombe, Rick P
2023-06-21 22:22 ` Edgecombe, Rick P
2023-06-21 23:05 ` H.J. Lu
2023-06-21 23:15 ` Edgecombe, Rick P
2023-06-22 1:07 ` Edgecombe, Rick P
2023-06-22 3:23 ` H.J. Lu
2023-06-22 8:27 ` szabolcs.nagy
2023-06-22 16:47 ` Edgecombe, Rick P
2023-06-23 16:25 ` szabolcs.nagy
2023-06-25 18:48 ` Edgecombe, Rick P
2023-06-21 23:02 ` H.J. Lu
2023-06-22 7:40 ` szabolcs.nagy
2023-06-22 16:46 ` Edgecombe, Rick P
2023-06-26 14:08 ` szabolcs.nagy
2023-06-28 1:23 ` Edgecombe, Rick P
2023-06-22 9:18 ` szabolcs.nagy
2023-06-22 15:26 ` Andy Lutomirski
2023-06-22 16:42 ` szabolcs.nagy
2023-06-22 23:18 ` Edgecombe, Rick P
2023-06-29 16:07 ` szabolcs.nagy
2023-07-02 18:03 ` Edgecombe, Rick P
2023-07-03 13:32 ` Mark Brown
2023-07-03 18:19 ` szabolcs.nagy
2023-07-03 18:38 ` Mark Brown
2023-07-03 18:49 ` Florian Weimer
2023-07-04 11:33 ` Szabolcs Nagy
2023-07-05 18:45 ` Edgecombe, Rick P
2023-07-05 19:10 ` Mark Brown
2023-07-05 19:17 ` Edgecombe, Rick P
2023-07-05 19:29 ` Mark Brown
2023-07-06 13:14 ` szabolcs.nagy
2023-07-06 14:24 ` Mark Brown
2023-07-06 16:59 ` Edgecombe, Rick P
2023-07-06 19:03 ` Mark Brown
2023-07-06 13:07 ` szabolcs.nagy
2023-07-06 18:25 ` Edgecombe, Rick P
2023-07-07 15:25 ` szabolcs.nagy
2023-07-07 17:37 ` Edgecombe, Rick P
2023-07-10 16:54 ` szabolcs.nagy
2023-07-10 22:56 ` Edgecombe, Rick P
2023-07-11 8:08 ` szabolcs.nagy
2023-07-12 9:39 ` Szabolcs Nagy
2023-06-25 23:52 ` Andy Lutomirski
2023-06-14 13:12 ` Mark Brown
2023-07-18 19:32 ` Szabolcs Nagy
2023-06-13 0:10 ` [PATCH v9 24/42] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 25/42] x86/fpu: Add helper for modifying xstate Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 26/42] x86: Introduce userspace API for shadow stack Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 27/42] x86/shstk: Add user control-protection fault handler Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 28/42] x86/shstk: Add user-mode shadow stack support Rick Edgecombe
2023-06-27 17:20 ` Mark Brown
2023-06-27 23:46 ` Dave Hansen
2023-06-28 0:37 ` Edgecombe, Rick P
2023-07-06 23:38 ` [PATCH] x86/shstk: Don't retry vm_munmap() on -EINTR Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 29/42] x86/shstk: Handle thread shadow stack Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 30/42] x86/shstk: Introduce routines modifying shstk Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 31/42] x86/shstk: Handle signals for shadow stack Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 32/42] x86/shstk: Check that SSP is aligned on sigreturn Rick Edgecombe
2023-06-13 0:10 ` [PATCH v9 33/42] x86/shstk: Check that signal frame is shadow stack mem Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 34/42] x86/shstk: Introduce map_shadow_stack syscall Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 35/42] x86/shstk: Support WRSS for userspace Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 36/42] x86: Expose thread features in /proc/$PID/status Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 37/42] x86/shstk: Wire in shadow stack interface Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 38/42] x86/cpufeatures: Enable CET CR4 bit for shadow stack Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 39/42] selftests/x86: Add shadow stack test Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 40/42] x86: Add PTRACE interface for shadow stack Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 41/42] x86/shstk: Add ARCH_SHSTK_UNLOCK Rick Edgecombe
2023-06-13 0:11 ` [PATCH v9 42/42] x86/shstk: Add ARCH_SHSTK_STATUS Rick Edgecombe
2023-06-13 1:34 ` [PATCH v9 00/42] Shadow stacks for userspace Linus Torvalds
2023-06-13 3:12 ` Edgecombe, Rick P
2023-06-13 17:44 ` Linus Torvalds
2023-06-13 18:27 ` Linus Torvalds
2023-06-13 19:38 ` Edgecombe, Rick P
2023-06-14 23:45 ` Mark Brown
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=20230613001108.3040476-1-rick.p.edgecombe@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--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=szabolcs.nagy@arm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=weijiang.yang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).