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>,
"Ravi V . Shankar" <ravi.v.shankar@intel.com>,
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
Cc: rick.p.edgecombe@intel.com
Subject: [PATCH v3 00/37] Shadow stacks for userspace
Date: Fri, 4 Nov 2022 15:35:27 -0700 [thread overview]
Message-ID: <20221104223604.29615-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 permissioned 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].
Thanks to all the reviewers of v2 [1]. There was a lot of very helpful
feedback. For v3 there are a lot of small changes, but not really any big ones.
I think the only remaining unresolved big issue is what to do about the
existing binaries that will fail if glibc is updated to utilize the shadow
stack kernel support. I am honestly not sure what is the right way forward.
More discussion on this below.
Other notable changes were:
- Dropping sigaltshstk support. It sounded like this could be a future
enhancement.
- Remove AMD patch (Thanks for Tested-by from John Allen)
- Promote ptrace/criu patches from OPTIONAL. If we might not have a new shadow
stack bit on day 1, we should give ptrace users something to work with.
- Detangle arch_prctl() numbers from LAM
Smaller changes are in the patches after the break.
This is off of v6.1-rc3 and this cleanup series [2]. Find the full tree here
[3].
Existing package compatibility problems
=======================================
This feature has a history of compatibility issues with existing userspace due
to the userspace enabling landing upstream ahead of the kernel support. The
first major issue encountered was the classic bad kernel regression - that some
existing distros would fail to boot on CET enabled kernels. This was due to
upstream glibc targeting an old abandoned CET kernel interface. It was resolved
with v1 of this series by switching the kernel enabling interface so old glibc
can’t find it, and is no longer an issue.
However there are still some lesser compatibility issues that are worth
discussing, and possibly help avoid on the kernel's side. These are around apps
being marked as shadow stack compatible when they actually are not.
When a binary is compatible with shadow stack it is supposed to be marked with
a specific elf bit . The design of the shadow stack implementation is that
glibc will detect this bit, and call kernel APIs to enable shadow stack.
Upstream glibc does not yet know how to do this. So the kernel’s shadow stack
implementation, and any compatibility issues, will remain dormant until these
CET glibc changes make it there. But many application binaries with the bit
marked exist today, and critically, it was applied widely and automatically by
some popular distro builds without verification that the packages actually
support shadow stack. So when glibc is updated, shadow stack will suddenly turn
on very widely with some missing verification.
In an ideal world this would be ok, because glibc has resolved many of the
shadow stack violating conditions internally. So as long as apps stick to the
normal usage of the glibc implementations for doing exotic stack things, then
apps *should* just work. However, in the real world there are apps that don't
stick to this. Especially JITs can violate the shadow stack enforcement.
In internal testing we have found one popular package, node.js, crashes on
startup. It's unknown how many other apps would crash with more complicated
usage than a basic startup test. My assumption is that there are more that
would.
The other compatibility issue that comes from the widespread presence of this
elf bit, is ptrace using applications. Some like, CRIU, do unusual
shadow-stack-violating things to the seized process as part of basic operation.
So while the application may not have issues in itself, they run into trouble
working with shadow stack enabled tracees. Others, like GDB, would fail when
doing some limited specific things like the "call a function" operation. While
it’s not unusual to have a new feature break saving and restoring an individual
target app, it is a bit unusual to have a new feature break CRIU usage for most
apps on the system. The kernel changes required for a fixed CRIU and GDB are
included in this series, but the userspace fixes are not upstream.
Blocking CET for the existing binaries
======================================
So we are not talking about a traditional kernel regression, where a fresh
kernel update breaks userspace. Instead we are talking about a userspace
component choosing to break existing apps by using new kernel functionality.
I’m not sure if it is the kernel’s job to stop this or not. But the kernel
actually could. It could detect the shadow stack elf bit and then later return
failure for the APIs that enable shadow stack. This would result in these apps
simply running normally without shadow stack.
Florian Weimer points out that this is a bit nasty, and I have to agree. I
think the workaround for this belongs in glibc. The best thing would be to pick
a new elf bit and have glibc look for this new one instead when deciding to
call the kernel shadow stack APIs. Then the old binaries could continue to work
without shadow stack, and new, more highly tested ones could be marked with the
new bit. Since there would then be kernel support and also there is a lot of
supporting HW out there, any CET enabling issues would be caught much earlier
when starting over with a new bit. So you could have a normal slow rollout
instead of a big bang.
But it doesn’t seem like the glibc developers are interested in working on a
solution. So I included a patch to do the detection and disable on the kernel
side and marked it RFC.
Distro’s could easily remove any kernel side check, and they can also fix
userspace regressions with package updates, or even before they turn on shadow
stack for their kernels. So we are talking about protecting users who will want
to use bleeding edge kernels and glibcs they build themselves. Probably not the
biggest category of users, but a helpful one to upstream developers.
This RFC patch also includes the ability for the kernel to allow broken
binaries by Kconfig, gated by CONFIG_EXPERT. So with this kernel patch, a user
who wants to try out CET would end up reading the Kconfig option and
understanding the situation before encountering breakage. But having this
release valve also is less of a forcing function to drive creation of a new elf
bit. So if that never happens, allowing broken binaries (ones with the existing
elf bit) would probably eventually have to become the default.
Another option might be a sysctl knob to toggle allowing these binaries instead
of a Kconfig option.
[0] https://lore.kernel.org/lkml/20220130211838.8382-1-rick.p.edgecombe@intel.com/
[1] https://lore.kernel.org/lkml/20220929222936.14584-1-rick.p.edgecombe@intel.com/
[2] https://lore.kernel.org/lkml/20221021221803.10910-1-rick.p.edgecombe@intel.com/
[3] https://github.com/rpedgeco/linux/tree/user_shstk_v3
Kirill A. Shutemov (1):
x86: Introduce userspace API for CET enabling
Mike Rapoport (1):
x86/cet/shstk: Add ARCH_CET_UNLOCK
Rick Edgecombe (10):
x86/fpu: Add helper for modifying xstate
mm: Don't allow write GUPs to shadow stack memory
mm: Warn on shadow stack memory in wrong vma
x86/shstk: Introduce map_shadow_stack syscall
x86/shstk: Support wrss for userspace
x86: Expose thread features in /proc/$PID/status
x86/cet/shstk: Wire in CET interface
selftests/x86: Add shadow stack test
x86/fpu: Add helper for initing features
fs/binfmt_elf: Block old shstk elf bit
Yu-cheng Yu (25):
Documentation/x86: Add CET description
x86/cet/shstk: Add Kconfig option for Shadow Stack
x86/cpufeatures: Add CPU feature flags for shadow stacks
x86/cpufeatures: Enable CET CR4 bit for shadow stack
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
x86/cet: Add user control-protection fault handler
x86/mm: Remove _PAGE_DIRTY from kernel RO pages
x86/mm: Move pmd_write(), pud_write() up in the file
x86/mm: Introduce _PAGE_COW
x86/mm: Update pte_modify for _PAGE_COW
x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for
transition from _PAGE_DIRTY to _PAGE_COW
mm: Move VM_UFFD_MINOR_BIT from 37 to 38
mm: Introduce VM_SHADOW_STACK for shadow stack memory
x86/mm: Check Shadow Stack page fault errors
x86/mm: Update maybe_mkwrite() for shadow stack
mm: Fixup places that call pte_mkwrite() directly
mm: Add guard pages around a shadow stack.
mm/mmap: Add shadow stack pages to memory accounting
mm/mprotect: Exclude shadow stack from preserve_write
mm: Re-introduce vm_flags to do_mmap()
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/cet: Add PTRACE interface for CET
Documentation/filesystems/proc.rst | 1 +
Documentation/x86/cet.rst | 151 +++++
Documentation/x86/index.rst | 1 +
arch/arm/kernel/signal.c | 2 +-
arch/arm64/include/asm/elf.h | 5 +
arch/arm64/kernel/signal.c | 2 +-
arch/arm64/kernel/signal32.c | 2 +-
arch/sparc/kernel/signal32.c | 2 +-
arch/sparc/kernel/signal_64.c | 2 +-
arch/x86/Kconfig | 37 ++
arch/x86/Kconfig.assembler | 5 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/x86/ia32/ia32_signal.c | 1 +
arch/x86/include/asm/cet.h | 42 ++
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/disabled-features.h | 17 +-
arch/x86/include/asm/elf.h | 11 +
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 | 14 +-
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/msr-index.h | 5 +
arch/x86/include/asm/msr.h | 11 +
arch/x86/include/asm/pgtable.h | 321 ++++++++--
arch/x86/include/asm/pgtable_types.h | 65 +-
arch/x86/include/asm/processor.h | 9 +
arch/x86/include/asm/special_insns.h | 13 +
arch/x86/include/asm/trap_pf.h | 2 +
arch/x86/include/uapi/asm/mman.h | 3 +
arch/x86/include/uapi/asm/prctl.h | 11 +
arch/x86/kernel/Makefile | 2 +
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 | 60 +-
arch/x86/kernel/fpu/regset.c | 90 +++
arch/x86/kernel/fpu/xstate.c | 148 +++--
arch/x86/kernel/fpu/xstate.h | 6 +
arch/x86/kernel/idt.c | 2 +-
arch/x86/kernel/process.c | 18 +-
arch/x86/kernel/process_64.c | 41 +-
arch/x86/kernel/ptrace.c | 20 +
arch/x86/kernel/shstk.c | 499 +++++++++++++++
arch/x86/kernel/signal.c | 7 +
arch/x86/kernel/signal_compat.c | 2 +-
arch/x86/kernel/traps.c | 107 +++-
arch/x86/mm/fault.c | 26 +
arch/x86/mm/mmap.c | 23 +
arch/x86/mm/pat/set_memory.c | 2 +-
arch/x86/mm/pgtable.c | 6 +
arch/x86/xen/enlighten_pv.c | 2 +-
arch/x86/xen/xen-asm.S | 2 +-
fs/aio.c | 2 +-
fs/binfmt_elf.c | 24 +-
fs/proc/array.c | 6 +
fs/proc/task_mmu.c | 3 +
include/linux/elf.h | 6 +
include/linux/mm.h | 37 +-
include/linux/pgtable.h | 35 ++
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 | 16 +
ipc/shm.c | 2 +-
kernel/sys_ni.c | 1 +
mm/gup.c | 2 +-
mm/huge_memory.c | 19 +-
mm/memory.c | 7 +-
mm/migrate_device.c | 4 +-
mm/mmap.c | 19 +-
mm/mprotect.c | 7 +
mm/nommu.c | 4 +-
mm/userfaultfd.c | 10 +-
mm/util.c | 2 +-
tools/testing/selftests/x86/Makefile | 4 +-
.../testing/selftests/x86/test_shadow_stack.c | 574 ++++++++++++++++++
80 files changed, 2502 insertions(+), 179 deletions(-)
create mode 100644 Documentation/x86/cet.rst
create mode 100644 arch/x86/include/asm/cet.h
create mode 100644 arch/x86/kernel/shstk.c
create mode 100644 tools/testing/selftests/x86/test_shadow_stack.c
--
2.17.1
next reply other threads:[~2022-11-04 22:39 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 22:35 Rick Edgecombe [this message]
2022-11-04 22:35 ` [PATCH v3 01/37] Documentation/x86: Add CET description Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 02/37] x86/cet/shstk: Add Kconfig option for Shadow Stack Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 03/37] x86/cpufeatures: Add CPU feature flags for shadow stacks Rick Edgecombe
2022-11-07 17:41 ` Borislav Petkov
2022-11-04 22:35 ` [PATCH v3 04/37] x86/cpufeatures: Enable CET CR4 bit for shadow stack Rick Edgecombe
2022-11-07 18:00 ` Borislav Petkov
2022-11-07 18:19 ` Edgecombe, Rick P
2022-11-07 18:37 ` Borislav Petkov
2022-11-07 19:19 ` Edgecombe, Rick P
2022-11-07 19:30 ` Borislav Petkov
2022-11-07 19:33 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 05/37] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 06/37] x86/fpu: Add helper for modifying xstate Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 07/37] x86/cet: Add user control-protection fault handler Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 08/37] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 09/37] x86/mm: Move pmd_write(), pud_write() up in the file Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 10/37] x86/mm: Introduce _PAGE_COW Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 11/37] x86/mm: Update pte_modify for _PAGE_COW Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 12/37] x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for transition from _PAGE_DIRTY to _PAGE_COW Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 13/37] mm: Move VM_UFFD_MINOR_BIT from 37 to 38 Rick Edgecombe
2022-11-15 11:20 ` Peter Zijlstra
2022-11-15 17:18 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 14/37] mm: Introduce VM_SHADOW_STACK for shadow stack memory Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 15/37] x86/mm: Check Shadow Stack page fault errors Rick Edgecombe
2022-11-15 11:47 ` Peter Zijlstra
2022-11-15 20:03 ` Edgecombe, Rick P
2022-11-15 21:07 ` Peter Zijlstra
2022-11-15 23:13 ` Edgecombe, Rick P
2022-11-16 10:09 ` Peter Zijlstra
2022-11-04 22:35 ` [PATCH v3 16/37] x86/mm: Update maybe_mkwrite() for shadow stack Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 17/37] mm: Fixup places that call pte_mkwrite() directly Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 18/37] mm: Add guard pages around a shadow stack Rick Edgecombe
2022-11-15 12:04 ` Peter Zijlstra
2022-11-15 20:40 ` Edgecombe, Rick P
2022-11-15 20:56 ` Peter Zijlstra
2022-11-15 21:49 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 19/37] mm/mmap: Add shadow stack pages to memory accounting Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 20/37] mm/mprotect: Exclude shadow stack from preserve_write Rick Edgecombe
2022-11-15 12:05 ` Peter Zijlstra
2022-11-15 20:41 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 21/37] mm: Re-introduce vm_flags to do_mmap() Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 22/37] mm: Don't allow write GUPs to shadow stack memory Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 23/37] mm: Warn on shadow stack memory in wrong vma Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 24/37] x86: Introduce userspace API for CET enabling Rick Edgecombe
2022-11-15 12:26 ` Peter Zijlstra
2022-11-15 13:03 ` Peter Zijlstra
2022-11-15 20:55 ` Edgecombe, Rick P
2022-11-15 14:25 ` Peter Zijlstra
2022-11-15 20:55 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 25/37] x86/shstk: Add user-mode shadow stack support Rick Edgecombe
2022-11-15 12:32 ` Peter Zijlstra
2022-11-15 21:46 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 26/37] x86/shstk: Handle thread shadow stack Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 27/37] x86/shstk: Introduce routines modifying shstk Rick Edgecombe
2022-11-15 14:18 ` Peter Zijlstra
2022-11-15 23:42 ` Edgecombe, Rick P
2022-11-16 10:18 ` Peter Zijlstra
2022-11-16 22:38 ` Edgecombe, Rick P
2022-11-17 14:17 ` Peter Zijlstra
2022-11-18 17:05 ` Edgecombe, Rick P
2022-11-15 14:22 ` Peter Zijlstra
2022-11-15 20:56 ` Edgecombe, Rick P
2022-11-04 22:35 ` [PATCH v3 28/37] x86/shstk: Handle signals for shadow stack Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 29/37] x86/shstk: Introduce map_shadow_stack syscall Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 30/37] x86/shstk: Support wrss for userspace Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 31/37] x86: Expose thread features in /proc/$PID/status Rick Edgecombe
2022-11-04 22:35 ` [PATCH v3 32/37] x86/cet/shstk: Wire in CET interface Rick Edgecombe
2022-11-04 22:36 ` [PATCH v3 33/37] selftests/x86: Add shadow stack test Rick Edgecombe
2022-11-04 22:36 ` [PATCH v3 34/37] x86/fpu: Add helper for initing features Rick Edgecombe
2022-11-04 22:36 ` [PATCH v3 35/37] x86/cet: Add PTRACE interface for CET Rick Edgecombe
2022-11-15 14:43 ` Peter Zijlstra
2022-11-15 22:23 ` Edgecombe, Rick P
2022-11-17 12:25 ` Schimpe, Christina
2022-11-17 14:14 ` Peter Zijlstra
2022-11-18 17:20 ` Edgecombe, Rick P
2022-11-18 17:25 ` Schimpe, Christina
2022-11-17 19:57 ` Edgecombe, Rick P
2022-11-18 16:21 ` Schimpe, Christina
2022-11-18 17:18 ` Edgecombe, Rick P
2022-11-21 7:40 ` Mike Rapoport
2022-11-21 15:52 ` Edgecombe, Rick P
2022-11-22 9:36 ` Mike Rapoport
2022-11-04 22:36 ` [PATCH v3 36/37] x86/cet/shstk: Add ARCH_CET_UNLOCK Rick Edgecombe
2022-11-15 14:47 ` Peter Zijlstra
2022-11-15 20:01 ` Edgecombe, Rick P
2022-11-15 20:57 ` Peter Zijlstra
2022-11-15 21:00 ` Dave Hansen
2022-11-15 21:21 ` Peter Zijlstra
2022-11-04 22:36 ` [RFC 37/37] fs/binfmt_elf: Block old shstk elf bit Rick Edgecombe
2022-11-04 22:56 ` H.J. Lu
2022-11-06 9:33 ` Florian Weimer
2022-11-07 16:49 ` Edgecombe, Rick P
2022-11-07 16:55 ` Florian Weimer
2022-11-07 17:37 ` Edgecombe, Rick P
2022-11-07 19:10 ` H.J. Lu
2022-11-07 21:10 ` Edgecombe, Rick P
2022-11-07 21:21 ` H.J. Lu
2022-11-07 21:34 ` Edgecombe, Rick P
2022-11-07 21:47 ` H.J. Lu
2022-11-07 22:46 ` Edgecombe, Rick P
2022-11-07 23:45 ` H.J. Lu
2022-11-08 9:14 ` Florian Weimer
2022-11-07 16:49 ` 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=20221104223604.29615-1-rick.p.edgecombe@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.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=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--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 NNTP newsgroup(s).