@@ -0,0 +1,136 @@+.. SPDX-License-Identifier: GPL-2.0++=========================================+Control-flow Enforcement Technology (CET)+=========================================++[1] Overview+============++Control-flow Enforcement Technology (CET) is an Intel processor feature+that provides protection against return/jump-oriented programming (ROP)+attacks. It can be set up to protect both applications and the kernel.+Only user-mode protection is implemented in the 64-bit kernel, including+support for running legacy 32-bit applications.++CET introduces Shadow Stack and Indirect Branch Tracking. Shadow stack is+a secondary stack allocated from memory and cannot be directly modified by+applications. When executing a CALL instruction, the processor pushes the+return address to both the normal stack and the shadow stack. Upon+function return, the processor pops the shadow stack copy and compares it+to the normal stack copy. If the two differ, the processor raises a+control-protection fault. Indirect branch tracking verifies indirect+CALL/JMP targets are intended as marked by the compiler with 'ENDBR'+opcodes.++There is a Kconfig option:++ X86_CET.++To build a CET-enabled kernel, Binutils v2.31 and GCC v8.1 or LLVM v10.0.1+or later are required. To build a CET-enabled application, GLIBC v2.28 or+later is also required.++There are two command-line options for disabling CET features::++ no_user_shstk - disables user shadow stack, and+ no_user_ibt - disables user indirect branch tracking.++At run time, /proc/cpuinfo shows CET features if the processor supports+CET.++[2] Application Enabling+========================++An application's CET capability is marked in its ELF header and can be+verified from readelf/llvm-readelf output:++ readelf -n <application> | grep -a SHSTK+ properties: x86 feature: IBT, SHSTK++If an application supports CET and is statically linked, it will run with+CET protection. If the application needs any shared libraries, the loader+checks all dependencies and enables CET when all requirements are met.++[3] Backward Compatibility+==========================++GLIBC provides a few CET tunables via the GLIBC_TUNABLES environment+variable:++GLIBC_TUNABLES=glibc.tune.hwcaps=-SHSTK,-IBT+ Turn off SHSTK/IBT.++GLIBC_TUNABLES=glibc.tune.x86_shstk=<on, permissive>+ This controls how dlopen() handles SHSTK legacy libraries::++ on - continue with SHSTK enabled;+ permissive - continue with SHSTK off.++Details can be found in the GLIBC manual pages.++[4] CET arch_prctl()'s+======================++Several arch_prctl()'s have been added for CET:++arch_prctl(ARCH_X86_CET_STATUS, u64 *addr)+ Return CET feature status.++ The parameter 'addr' is a pointer to a user buffer.+ On returning to the caller, the kernel fills the following+ information::++ *addr = shadow stack/indirect branch tracking status+ *(addr + 1) = shadow stack base address+ *(addr + 2) = shadow stack size++arch_prctl(ARCH_X86_CET_DISABLE, unsigned int features)+ Disable shadow stack and/or indirect branch tracking as specified in+ 'features'. Return -EPERM if CET is locked.++arch_prctl(ARCH_X86_CET_LOCK)+ Lock in all CET features. They cannot be turned off afterwards.++Note:+ There is no CET-enabling arch_prctl function. By design, CET is enabled+ automatically if the binary and the system can support it.++[5] The implementation of the Shadow Stack+==========================================++Shadow Stack size+-----------------++A task's shadow stack is allocated from memory to a fixed size of+MIN(RLIMIT_STACK, 4 GB). In other words, the shadow stack is allocated to+the maximum size of the normal stack, but capped to 4 GB. However,+a compat-mode application's address space is smaller, each of its thread's+shadow stack size is MIN(1/4 RLIMIT_STACK, 4 GB).++Signal+------++The main program and its signal handlers use the same shadow stack.+Because the shadow stack stores only return addresses, a large shadow+stack covers the condition that both the program stack and the signal+alternate stack run out.++The kernel creates a restore token for the shadow stack restoring address+and verifies that token when restoring from the signal handler.++Fork+----++The shadow stack's vma has VM_SHSTK flag set; its PTEs are required to be+read-only and dirty. When a shadow stack PTE is not RO and dirty, a+shadow access triggers a page fault with the shadow stack access bit set+in the page fault error code.++When a task forks a child, its shadow stack PTEs are copied and both the+parent's and the child's shadow stack PTEs are cleared of the dirty bit.+Upon the next shadow stack access, the resulting shadow stack page fault+is handled by page copy/re-use.++When a pthread child is created, the kernel allocates a new shadow stack+for the new thread.
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-Shadow Stack applications continue to work, but without protection.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/Kconfig | 22 ++++++++++++++++++++++
arch/x86/Kconfig.assembler | 5 +++++
2 files changed, 27 insertions(+)
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This results in ambiguity between shadow stack and
kernel read-only pages. To resolve this, removed Dirty from kernel read-
only pages.
Signed-off-by: Yu-cheng Yu <redacted>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
---
arch/x86/include/asm/pgtable_types.h | 6 +++---
arch/x86/mm/pat/set_memory.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
@@ -1932,7 +1932,7 @@ int set_memory_nx(unsigned long addr, int numpages)intset_memory_ro(unsignedlongaddr,intnumpages){-returnchange_page_attr_clear(&addr,numpages,__pgprot(_PAGE_RW),0);+returnchange_page_attr_clear(&addr,numpages,__pgprot(_PAGE_RW|_PAGE_DIRTY),0);}intset_memory_rw(unsignedlongaddr,intnumpages)
To prepare the introduction of _PAGE_COW, move pmd_write() and
pud_write() up in the file, so that they can be used by other
helpers below.
Signed-off-by: Yu-cheng Yu <redacted>
---
arch/x86/include/asm/pgtable.h | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
Control-flow Enforcement Technology (CET) introduces these MSRs:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode shadow stack pointer),
MSR_IA32_PL0_SSP (kernel-mode shadow stack pointer),
MSR_IA32_PL1_SSP (Privilege Level 1 shadow stack pointer),
MSR_IA32_PL2_SSP (Privilege Level 2 shadow stack pointer),
MSR_IA32_S_CET (kernel-mode CET settings),
MSR_IA32_INT_SSP_TAB (exception shadow stack table).
The two user-mode MSRs belong to XFEATURE_CET_USER. The first three of
kernel-mode MSRs belong to XFEATURE_CET_KERNEL. Both XSAVES states are
supervisor states. This means that there is no direct, unprivileged access
to these states, making it harder for an attacker to subvert CET.
For sigreturn and future ptrace() support, shadow stack address and MSR
reserved bits are checked before written to the supervisor states.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/fpu/types.h | 23 +++++++++++++++++++++--
arch/x86/include/asm/fpu/xstate.h | 6 ++++--
arch/x86/include/asm/msr-index.h | 19 +++++++++++++++++++
arch/x86/kernel/fpu/xstate.c | 10 +++++++++-
4 files changed, 53 insertions(+), 5 deletions(-)
@@ -35,7 +35,8 @@XFEATURE_MASK_BNDCSR)/* All currently supported supervisor features */-#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (XFEATURE_MASK_PASID)+#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (XFEATURE_MASK_PASID | \+XFEATURE_MASK_CET_USER)/**Asupervisorstatecomponentmaynotalwayscontainvaluableinformation,
@@ -62,7 +63,8 @@*Unsupportedsupervisorfeatures.Whenasupervisorfeatureinthismaskis*supportedinthefuture,moveittothesupportedsupervisorfeaturemask.*/-#define XFEATURE_MASK_SUPERVISOR_UNSUPPORTED (XFEATURE_MASK_PT)+#define XFEATURE_MASK_SUPERVISOR_UNSUPPORTED (XFEATURE_MASK_PT | \+XFEATURE_MASK_CET_KERNEL)/* All supervisor states including supported and unsupported states. */#define XFEATURE_MASK_SUPERVISOR_ALL (XFEATURE_MASK_SUPERVISOR_SUPPORTED | \
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix, arrives at a non-ENDBR opcode.
The control-protection fault handler works in a similar way as the general
protection fault handler. It provides the si_code SEGV_CPERR to the signal
handler.
Signed-off-by: Yu-cheng Yu <redacted>
Cc: Michael Kerrisk <redacted>
---
arch/x86/include/asm/idtentry.h | 4 ++
arch/x86/kernel/idt.c | 4 ++
arch/x86/kernel/signal_compat.c | 2 +-
arch/x86/kernel/traps.c | 63 ++++++++++++++++++++++++++++++
include/uapi/asm-generic/siginfo.h | 3 +-
5 files changed, 74 insertions(+), 2 deletions(-)
@@ -571,6 +571,10 @@ DECLARE_IDTENTRY_ERRORCODE(X86_TRAP_SS, exc_stack_segment);DECLARE_IDTENTRY_ERRORCODE(X86_TRAP_GP,exc_general_protection);DECLARE_IDTENTRY_ERRORCODE(X86_TRAP_AC,exc_alignment_check);+#ifdef CONFIG_X86_CET+DECLARE_IDTENTRY_ERRORCODE(X86_TRAP_CP,exc_control_protection);+#endif+/* Raw exception entries which need extra work */DECLARE_IDTENTRY_RAW(X86_TRAP_UD,exc_invalid_op);DECLARE_IDTENTRY_RAW(X86_TRAP_BP,exc_int3);
@@ -606,6 +607,68 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)cond_local_irq_disable(regs);}+#ifdef CONFIG_X86_CET+staticconstchar*constcontrol_protection_err[]={+"unknown",+"near-ret",+"far-ret/iret",+"endbranch",+"rstorssp",+"setssbsy",+"unknown",+};++staticDEFINE_RATELIMIT_STATE(cpf_rate,DEFAULT_RATELIMIT_INTERVAL,+DEFAULT_RATELIMIT_BURST);++/*+*Whenacontrolprotectionexceptionoccurs,sendasignaltotheresponsible+*application.Currently,controlprotectionisonlyenabledforusermode.+*Thisexceptionshouldnotcomefromkernelmode.+*/+DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)+{+structtask_struct*tsk;++if(!user_mode(regs)){+pr_emerg("PANIC: unexpected kernel control protection fault\n");+die("kernel control protection fault",regs,error_code);+panic("Machine halted.");+}++cond_local_irq_enable(regs);++if(!boot_cpu_has(X86_FEATURE_CET))+WARN_ONCE(1,"Control protection fault with CET support disabled\n");++tsk=current;+tsk->thread.error_code=error_code;+tsk->thread.trap_nr=X86_TRAP_CP;++/*+*Ratelimittopreventlogspamming.+*/+if(show_unhandled_signals&&unhandled_signal(tsk,SIGSEGV)&&+__ratelimit(&cpf_rate)){+unsignedlongssp;+intcpf_type;++cpf_type=array_index_nospec(error_code,ARRAY_SIZE(control_protection_err));++rdmsrl(MSR_IA32_PL3_SSP,ssp);+pr_emerg("%s[%d] control protection ip:%lx sp:%lx ssp:%lx error:%lx(%s)",+tsk->comm,task_pid_nr(tsk),+regs->ip,regs->sp,ssp,error_code,+control_protection_err[cpf_type]);+print_vma_addr(KERN_CONT" in ",regs->ip);+pr_cont("\n");+}++force_sig_fault(SIGSEGV,SEGV_CPERR,(void__user*)0);+cond_local_irq_disable(regs);+}+#endif+staticbooldo_int3(structpt_regs*regs){intres;
When serving a page fault, maybe_mkwrite() makes a PTE writable if its vma
has VM_WRITE.
A shadow stack vma has VM_SHSTK. Its PTEs have _PAGE_DIRTY, but not
_PAGE_WRITE. In fork(), _PAGE_DIRTY is cleared to effect copy-on-write,
and in page fault, _PAGE_DIRTY is restored and the shadow stack page is
writable again.
Update maybe_mkwrite() by introducing arch_maybe_mkwrite(), which sets
_PAGE_DIRTY for a shadow stack PTE.
Apply the same changes to maybe_pmd_mkwrite().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/Kconfig | 4 ++++
arch/x86/mm/pgtable.c | 18 ++++++++++++++++++
include/linux/mm.h | 2 ++
include/linux/pgtable.h | 24 ++++++++++++++++++++++++
mm/huge_memory.c | 2 ++
5 files changed, 50 insertions(+)
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can start a write but end up seeing
a read-only PTE by the time they get to the Dirty bit, creating a transient
shadow stack PTE. However, this will not occur on processors supporting
Shadow Stack, and a TLB flush is not necessary.
The second case is that when _PAGE_DIRTY is replaced with _PAGE_COW non-
atomically, a transient shadow stack PTE can be created as a result.
Thus, prevent that with cmpxchg.
Dave Hansen, Jann Horn, Andy Lutomirski, and Peter Zijlstra provided many
insights to the issue. Jann Horn provided the cmpxchg solution.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/pgtable.h | 36 ++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
pte_*() are updated.
Pte_modify() changes a PTE to 'newprot', but it doesn't use the pte_*().
Introduce fixup_dirty_pte(), which sets a dirty PTE, based on _PAGE_RW,
to either _PAGE_DIRTY or _PAGE_COW.
Apply the same changes to pmd_modify().
Signed-off-by: Yu-cheng Yu <redacted>
---
arch/x86/include/asm/pgtable.h | 37 ++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY or _PAGE_COW. Change _PAGE_DIRTY to _PAGE_DIRTY_BITS.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: David Airlie <redacted>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <redacted>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Zhenyu Wang <redacted>
Cc: Zhi Wang <redacted>
---
drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce vm_flags to do_mmap(), but without the old wrapper
do_mmap_pgoff(). Instead, make all callers of the wrapper pass a zero
vm_flags to do_mmap().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Peter Collingbourne <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-mm@kvack.org
---
fs/aio.c | 2 +-
include/linux/mm.h | 3 ++-
ipc/shm.c | 2 +-
mm/mmap.c | 10 +++++-----
mm/nommu.c | 4 ++--
mm/util.c | 2 +-
6 files changed, 12 insertions(+), 11 deletions(-)
@@ -1071,6 +1071,7 @@ unsigned long do_mmap(struct file *file,unsignedlonglen,unsignedlongprot,unsignedlongflags,+vm_flags_tvm_flags,unsignedlongpgoff,unsignedlong*populate,structlist_head*uf)
@@ -1078,7 +1079,6 @@ unsigned long do_mmap(struct file *file,structvm_area_struct*vma;structvm_region*region;structrb_node*rb;-vm_flags_tvm_flags;unsignedlongcapabilities,result;intret;
@@ -1097,7 +1097,7 @@ unsigned long do_mmap(struct file *file,/* we've determined that we can make the mapping, now translate what we*nowknowintoVMAflags*/-vm_flags=determine_vm_flags(file,prot,flags,capabilities);+vm_flags|=determine_vm_flags(file,prot,flags,capabilities);/* we're going to need to record the mapping */region=kmem_cache_zalloc(vm_region_jar,GFP_KERNEL);
There is essentially no room left in the x86 hardware PTEs on some OSes
(not 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.
The reason it's lightly used is that Dirty=1 is normally set by hardware
and cannot normally be set by hardware on a Write=0 PTE. Software must
normally be involved to create one of these PTEs, so software can simply
opt to not create them.
In places where Linux normally creates Write=0, Dirty=1, it can use the
software-defined _PAGE_COW in place of the hardware _PAGE_DIRTY. In other
words, whenever Linux needs to create Write=0, Dirty=1, it instead creates
Write=0, Cow=1, except for shadow stack, which is Write=0, Dirty=1. This
clearly separates shadow stack from other data, and results in the
following:
(a) A modified, copy-on-write (COW) page: (Write=0, Cow=1)
(b) A R/O page that has been COW'ed: (Write=0, Cow=1)
The user page is in a R/O VMA, and get_user_pages() 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 Cow=1.
(c) A shadow stack PTE: (Write=0, Dirty=1)
(d) A shared shadow stack PTE: (Write=0, Cow=1)
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.
(e) A page where the processor observed a Write=1 PTE, started a write, set
Dirty=1, but then observed a Write=0 PTE. That's possible today, but
will not happen on processors that support shadow stack.
Define _PAGE_COW and update pte_*() helpers and apply the same changes to
pmd and pud.
After this, there are six free bits left in the 64-bit PTE, and no more
free bits in the 32-bit PTE (except for PAE) and Shadow Stack is not
implemented for the 32-bit kernel.
Signed-off-by: Yu-cheng Yu <redacted>
---
arch/x86/include/asm/pgtable.h | 195 ++++++++++++++++++++++++---
arch/x86/include/asm/pgtable_types.h | 42 +++++-
2 files changed, 216 insertions(+), 21 deletions(-)
@@ -23,7 +23,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 */
@@ -36,6 +37,15 @@#define _PAGE_BIT_SOFT_DIRTY _PAGE_BIT_SOFTW3 /* software dirty tracking */#define _PAGE_BIT_DEVMAP _PAGE_BIT_SOFTW4+/*+*Indicatesacopy-on-writepage.+*/+#ifdef CONFIG_X86_CET+#define _PAGE_BIT_COW _PAGE_BIT_SOFTW5 /* copy-on-write */+#else+#define _PAGE_BIT_COW 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
Can_follow_write_pte() ensures a read-only page is COWed by checking the
FOLL_COW flag, and uses pte_dirty() to validate the flag is still valid.
Like a writable data page, a shadow stack page is writable, and becomes
read-only during copy-on-write, but it is always dirty. Thus, in the
can_follow_write_pte() check, it belongs to the writable page case and
should be excluded from the read-only page pte_dirty() check. Apply
the same changes to can_follow_write_pmd().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
mm/gup.c | 8 +++++---
mm/huge_memory.c | 8 +++++---
2 files changed, 10 insertions(+), 6 deletions(-)
In change_pte_range(), when a PTE is changed for prot_numa, _PAGE_RW is
preserved to avoid the additional write fault after the NUMA hinting fault.
However, pte_write() now includes both normal writable and shadow stack
(RW=0, Dirty=1) PTEs, but the latter does not have _PAGE_RW and has no need
to preserve it.
Exclude shadow stack from preserve_write test, and apply the same change to
change_huge_pmd().
Signed-off-by: Yu-cheng Yu <redacted>
---
mm/huge_memory.c | 7 ++++++-
mm/mprotect.c | 9 ++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
Shadow stacks accesses to shadow-stack mapping can see faults in normal,
valid operation just like regular accesses to regular mappings. Shadow
stacks need some of the same features like delayed allocation, swap and
copy-on-write.
Shadow stack accesses can also result in errors, such as when a shadow
stack overflows, or if a shadow stack access occurs to a non-shadow-stack
mapping.
In handling a shadow stack page fault, verify it occurs within a shadow
stack mapping. It is always an error otherwise. For valid shadow stack
accesses, set FAULT_FLAG_WRITE to effect copy-on-write. Because clearing
_PAGE_DIRTY (vs. _PAGE_RW) is used to trigger the fault, shadow stack read
fault and shadow stack write fault are not differentiated and both are
handled as a write access.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/trap_pf.h | 2 ++
arch/x86/mm/fault.c | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the
first and the last elements in the range, effectively touches those memory
areas.
The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and
255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE.
Thus, putting a gap page on both ends of a shadow stack prevents INCSSP,
CALL, and RET from going beyond.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/page_64_types.h | 10 ++++++++++
include/linux/mm.h | 24 ++++++++++++++++++++----
2 files changed, 30 insertions(+), 4 deletions(-)
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but effect the
same result as from maybe_mkwrite(). These sites need to be updated for
shadow stack as well. Thus, change them to maybe_mkwrite():
- do_anonymous_page() and migrate_vma_insert_page() check VM_WRITE directly
and call pte_mkwrite(), which is the same as maybe_mkwrite(). Change
them to maybe_mkwrite().
- In do_numa_page(), if the numa entry 'was-writable', then pte_mkwrite()
is called directly. Fix it by doing maybe_mkwrite().
- In change_pte_range(), pte_mkwrite() is called directly. Replace it with
maybe_mkwrite().
A shadow stack vma is writable but has different vma
flags, and handled accordingly in maybe_mkwrite().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
mm/memory.c | 5 ++---
mm/migrate.c | 3 +--
mm/mprotect.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack, and
the address in a token must point directly above the token, which is within
the same shadow stack. This is distinctively different from other pointers
on the shadow stack; those pointers point to executable code area.
In sigreturn, restoring from a token ensures the target address is the
location pointed by the token.
Introduce WRUSS, which is a kernel-mode instruction but writes directly to
user shadow stack. It is used to construct the user signal stack as
described above.
Currently there is no systematic facility for extending a signal context.
Introduce a signal context extension 'struct sc_ext', which is used to save
shadow stack restore token address and WAIT_ENDBR status. WAIT_ENDBR will
be introduced later in the Indirect Branch Tracking (IBT) series, but add
that into sc_ext now to keep the struct stable in case the IBT series is
applied later.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/ia32/ia32_signal.c | 17 +++
arch/x86/include/asm/cet.h | 8 ++
arch/x86/include/asm/fpu/internal.h | 10 ++
arch/x86/include/asm/special_insns.h | 32 ++++++
arch/x86/include/uapi/asm/sigcontext.h | 9 ++
arch/x86/kernel/cet.c | 152 +++++++++++++++++++++++++
arch/x86/kernel/fpu/signal.c | 100 ++++++++++++++++
arch/x86/kernel/signal.c | 10 ++
8 files changed, 338 insertions(+)
@@ -196,6 +196,15 @@ struct _xstate {/* New processor state extensions go here: */};+/*+*Locatedattheendofsigcontext->fpstate,alignedto8.+*/+structsc_ext{+unsignedlongtotal_size;+unsignedlongssp;+unsignedlongwait_endbr;+};+/**The32-bitsignalframe:*/
@@ -72,6 +74,80 @@ static unsigned long alloc_shstk(unsigned long size, int flags)returnaddr;}+#define TOKEN_MODE_MASK 3UL+#define TOKEN_MODE_64 1UL+#define IS_TOKEN_64(token) (((token) & TOKEN_MODE_MASK) == TOKEN_MODE_64)+#define IS_TOKEN_32(token) (((token) & TOKEN_MODE_MASK) == 0)++/*+*Verifytherestoretokenattheaddressof'ssp'is+*validandthensetshadowstackpointeraccordingtothe+*token.+*/+intcet_verify_rstor_token(boolia32,unsignedlongssp,+unsignedlong*new_ssp)+{+unsignedlongtoken;++*new_ssp=0;++if(!IS_ALIGNED(ssp,8))+return-EINVAL;++if(get_user(token,(unsignedlong__user*)ssp))+return-EFAULT;++/* Is 64-bit mode flag correct? */+if(!ia32&&!IS_TOKEN_64(token))+return-EINVAL;+elseif(ia32&&!IS_TOKEN_32(token))+return-EINVAL;++token&=~TOKEN_MODE_MASK;++/*+*Restoreaddressproperlyaligned?+*/+if((!ia32&&!IS_ALIGNED(token,8))||!IS_ALIGNED(token,4))+return-EINVAL;++/*+*Tokenwasplacedproperly?+*/+if(((ALIGN_DOWN(token,8)-8)!=ssp)||token>=TASK_SIZE_MAX)+return-EINVAL;++*new_ssp=token;+return0;+}++/*+*Createarestoretokenontheshadowstack.+*Atokenisalways8-byteandalignedto8.+*/+staticintcreate_rstor_token(boolia32,unsignedlongssp,+unsignedlong*new_ssp)+{+unsignedlongaddr;++*new_ssp=0;++if((!ia32&&!IS_ALIGNED(ssp,8))||!IS_ALIGNED(ssp,4))+return-EINVAL;++addr=ALIGN_DOWN(ssp,8)-8;++/* Is the token for 64-bit? */+if(!ia32)+ssp|=TOKEN_MODE_64;++if(write_user_shstk_64(addr,ssp))+return-EFAULT;++*new_ssp=addr;+return0;+}+intcet_setup_shstk(void){unsignedlongaddr,size;
@@ -535,6 +536,10 @@ struct thread_struct {unsignedintsig_on_uaccess_err:1;+#ifdef CONFIG_X86_CET+structcet_statuscet;+#endif+/* Floating point and extended processor state */structfpufpu;/*
The kernel allocates (and frees on thread exit) a new shadow stack for a
pthread child.
It is possible for the kernel to complete the clone syscall and set the
child's shadow stack pointer to NULL and let the child thread allocate
a shadow stack for itself. There are two issues in this approach: It
is not compatible with existing code that does inline syscall and it
cannot handle signals before the child can successfully allocate a
shadow stack.
Use stack_size passed from clone3() syscall for thread shadow stack size,
but cap it to min(RLIMIT_STACK, 4 GB). A compat-mode thread shadow stack
size is further reduced to 1/4. This allows more threads to run in a 32-
bit address space.
Signed-off-by: Yu-cheng Yu <redacted>
---
arch/x86/include/asm/cet.h | 5 +++
arch/x86/include/asm/mmu_context.h | 3 ++
arch/x86/kernel/cet.c | 49 ++++++++++++++++++++++++++++++
arch/x86/kernel/process.c | 15 +++++++--
4 files changed, 69 insertions(+), 3 deletions(-)
@@ -172,6 +172,55 @@ int cet_setup_shstk(void)return0;}+intcet_setup_thread_shstk(structtask_struct*tsk,unsignedlongclone_flags,+unsignedlongstack_size)+{+unsignedlongaddr,size;+structcet_user_state*state;+structcet_status*cet=&tsk->thread.cet;++if(!cet->shstk_size)+return0;++if((clone_flags&(CLONE_VFORK|CLONE_VM))!=CLONE_VM)+return0;++state=get_xsave_addr(&tsk->thread.fpu.state.xsave,+XFEATURE_CET_USER);++if(!state)+return-EINVAL;++if(stack_size==0)+return-EINVAL;++/* Cap shadow stack size to 4 GB */+size=min(rlimit(RLIMIT_STACK),1UL<<32);+size=min(size,stack_size);++/*+*Compat-modepthreadssharealimitedaddressspace.+*Ifeachfunctioncalltakesanaverageoffourslots+*stackspace,allocate1/4ofstacksizeforshadowstack.+*/+if(in_compat_syscall())+size/=4;+size=round_up(size,PAGE_SIZE);+addr=alloc_shstk(size,0);++if(IS_ERR_VALUE(addr)){+cet->shstk_base=0;+cet->shstk_size=0;+returnPTR_ERR((void*)addr);+}++fpu__prepare_write(&tsk->thread.fpu);+state->user_ssp=(u64)(addr+size);+cet->shstk_base=addr;+cet->shstk_size=size;+return0;+}+voidcet_disable_shstk(void){structcet_status*cet=¤t->thread.cet;
@@ -122,8 +124,9 @@ static int set_new_tls(struct task_struct *p, unsigned long tls)returndo_set_thread_area_64(p,ARCH_SET_FS,tls);}-intcopy_thread(unsignedlongclone_flags,unsignedlongsp,unsignedlongarg,-structtask_struct*p,unsignedlongtls)+intcopy_thread(unsignedlongclone_flags,unsignedlongsp,+unsignedlongstack_size,structtask_struct*p,+unsignedlongtls){structinactive_task_frame*frame;structfork_frame*fork_frame;
@@ -163,7 +166,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, unsigned long arg,/* Kernel thread ? */if(unlikely(p->flags&(PF_KTHREAD|PF_IO_WORKER))){memset(childregs,0,sizeof(structpt_regs));-kthread_frame_init(frame,sp,arg);+kthread_frame_init(frame,sp,stack_size);return0;}
@@ -181,6 +184,12 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, unsigned long arg,if(clone_flags&CLONE_SETTLS)ret=set_new_tls(p,tls);+#ifdef CONFIG_X86_64+/* Allocate a new shadow stack for pthread */+if(!ret)+ret=cet_setup_thread_shstk(p,clone_flags,stack_size);+#endif+if(!ret&&unlikely(test_tsk_thread_flag(current,TIF_IO_BITMAP)))io_bitmap_share(p);
An ELF file's .note.gnu.property indicates arch features supported by the
file. These features are extracted by arch_parse_elf_property() and stored
in 'arch_elf_state'.
Introduce x86 feature definitions and arch_setup_elf_property(), which
enables such features. The first use-case of this function is Shadow
Stack.
ARM64 is the other arch that has ARCH_USE_GNU_PROPERTY and arch_parse_elf_
property(). Add arch_setup_elf_property() for it.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/elf.h | 5 +++++
arch/x86/Kconfig | 2 ++
arch/x86/include/asm/elf.h | 13 +++++++++++++
arch/x86/kernel/process_64.c | 32 ++++++++++++++++++++++++++++++++
fs/binfmt_elf.c | 4 ++++
include/linux/elf.h | 6 ++++++
include/uapi/linux/elf.h | 9 +++++++++
7 files changed, 71 insertions(+)
A shadow stack PTE must be read-only and have _PAGE_DIRTY set. However,
read-only and Dirty PTEs also exist for copy-on-write (COW) pages. These
two cases are handled differently for page faults. Introduce VM_SHSTK to
track shadow stack VMAs.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
Documentation/filesystems/proc.rst | 1 +
arch/x86/mm/mmap.c | 2 ++
fs/proc/task_mmu.c | 3 +++
include/linux/mm.h | 8 ++++++++
4 files changed, 14 insertions(+)
@@ -549,6 +549,7 @@ encoded manner. The codes are the following: mg mergable advise flag bt arm64 BTI guarded page mt arm64 MTE allocation tags are enabled+ ss shadow stack page == ======================================= Note that there is no guarantee that every flag and associated mnemonic will
To prepare changes to arch_calc_vm_prot_bits() in the next patch, and be
consistent with other architectures, move arch_vm_get_page_prot() and
arch_calc_vm_prot_bits() to arch/x86/include/asm/mman.h.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/mman.h | 30 ++++++++++++++++++++++++++++++
arch/x86/include/uapi/asm/mman.h | 27 +++------------------------
2 files changed, 33 insertions(+), 24 deletions(-)
create mode 100644 arch/x86/include/asm/mman.h
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT status
*(args + 1) = shadow stack base address
*(args + 2) = shadow stack size
32-bit binaries use the same interface, but only lower 32-bits of each
item.
arch_prctl(ARCH_X86_CET_DISABLE, unsigned int features)
Disable CET features specified in 'features'. Return -EPERM if CET is
locked.
arch_prctl(ARCH_X86_CET_LOCK)
Lock in CET features.
Also change do_arch_prctl_common()'s parameter 'cpuid_enabled' to
'arg2', as it is now also passed to prctl_cet().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/cet.h | 3 ++
arch/x86/include/uapi/asm/prctl.h | 4 +++
arch/x86/kernel/Makefile | 2 +-
arch/x86/kernel/cet_prctl.c | 60 +++++++++++++++++++++++++++++++
arch/x86/kernel/process.c | 6 ++--
5 files changed, 71 insertions(+), 4 deletions(-)
create mode 100644 arch/x86/kernel/cet_prctl.c
@@ -26,6 +28,7 @@ int cet_verify_rstor_token(bool ia32, unsigned long ssp, unsigned long *new_ssp)voidcet_restore_signal(structsc_ext*sc);intcet_setup_signal(boolia32,unsignedlongrstor,structsc_ext*sc);#else+staticinlineintprctl_cet(intoption,u64arg2){return-EINVAL;}staticinlineintcet_setup_thread_shstk(structtask_struct*p,unsignedlongclone_flags,unsignedlongstack_size){return0;}
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters. Multiple parameters must be
passed in a memory buffer. There is a proposal to pass more parameters in
registers [1], but no active discussion on that.
A new syscall minimizes compatibility issues and offers an extensible frame
work to other architectures, but this will likely result in some overlap of
mmap()/mprotect().
The introduction of PROT_SHSTK to mmap()/mprotect() takes advantage of
existing APIs. The x86-specific PROT_SHSTK is translated to VM_SHSTK and
a shadow stack mapping is created without reinventing the wheel. There are
potential pitfalls though. The most obvious one would be using this as a
bypass to shadow stack protection. However, the attacker would have to get
to the syscall first.
[1] https://lore.kernel.org/lkml/20200828121624.108243-1-hjl.tools@gmail.com/
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/mman.h | 57 +++++++++++++++++++++++++++++++-
arch/x86/include/uapi/asm/mman.h | 1 +
include/linux/mm.h | 1 +
mm/mmap.c | 8 ++++-
4 files changed, 65 insertions(+), 2 deletions(-)
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
We used to have shadow stack and ibt under separate Kconfig options, but
in a few places they actually share same code path, such as the XSAVES
supervisor states and ELF header for example. Anyways I will be happy
to make changes again if there is agreement.
In fact, I think all of this would improve is you remove the CET name
from all of this entirely. Put this series under CONFIG_X86_SHSTK (or
_SS) and use CONFIG_X86_IBT for the other one.
Similarly with the .c file.
All this CET business is just pure confusion.
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-03-16 21:52:37
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
In fact, I think all of this would improve is you remove the CET name
from all of this entirely. Put this series under CONFIG_X86_SHSTK (or
_SS) and use CONFIG_X86_IBT for the other one.
Similarly with the .c file.
All this CET business is just pure confusion.
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
We used to have shadow stack and ibt under separate Kconfig options, but in
a few places they actually share same code path, such as the XSAVES
supervisor states and ELF header for example. Anyways I will be happy to
make changes again if there is agreement.
I was look at:
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
didn't see any IBT logic - it's essentially all shadow stack state.
Which is not surprising, forward call edge integrity protection (IBT)
requires very little state, does it?
With IBT there's no nesting, no stack - the IBT state machine
basically requires the next instruction to be and ENDBR instruction,
and that's essentially it, right?
Thanks,
Ingo
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-03-17 10:16:24
On Wed, Mar 17, 2021 at 10:18:00AM +0100, Ingo Molnar wrote:
* Yu, Yu-cheng [off-list ref] wrote:
quoted
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
quoted
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
We used to have shadow stack and ibt under separate Kconfig options, but in
a few places they actually share same code path, such as the XSAVES
supervisor states and ELF header for example. Anyways I will be happy to
make changes again if there is agreement.
I was look at:
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
didn't see any IBT logic - it's essentially all shadow stack state.
Which is not surprising, forward call edge integrity protection (IBT)
requires very little state, does it?
They hid the IBT enable bit in the U_CET MSR, which is in the XSAVE
thing.
On Tue, Mar 16, 2021 at 08:10:41AM -0700, Yu-cheng Yu wrote:
When serving a page fault, maybe_mkwrite() makes a PTE writable if its vma
has VM_WRITE.
A shadow stack vma has VM_SHSTK. Its PTEs have _PAGE_DIRTY, but not
_PAGE_WRITE. In fork(), _PAGE_DIRTY is cleared to effect copy-on-write,
to cause
and in page fault, _PAGE_DIRTY is restored and the shadow stack page is
in the page fault handler...
writable again.
Update maybe_mkwrite() by introducing arch_maybe_mkwrite(), which sets
_PAGE_DIRTY for a shadow stack PTE.
Apply the same changes to maybe_pmd_mkwrite().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/Kconfig | 4 ++++
arch/x86/mm/pgtable.c | 18 ++++++++++++++++++
include/linux/mm.h | 2 ++
include/linux/pgtable.h | 24 ++++++++++++++++++++++++
mm/huge_memory.c | 2 ++
5 files changed, 50 insertions(+)
On Tue, Mar 16, 2021 at 08:10:42AM -0700, Yu-cheng Yu wrote:
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but effect the
same result as from maybe_mkwrite(). These sites need to be updated for
s/effect the same result/have the same result/
shadow stack as well. Thus, change them to maybe_mkwrite():
- do_anonymous_page() and migrate_vma_insert_page() check VM_WRITE directly
and call pte_mkwrite(), which is the same as maybe_mkwrite(). Change
them to maybe_mkwrite().
- In do_numa_page(), if the numa entry 'was-writable', then pte_mkwrite()
You can simply say "was writable" instead of trying to hint at the
variable there.
is called directly. Fix it by doing maybe_mkwrite().
- In change_pte_range(), pte_mkwrite() is called directly. Replace it with
maybe_mkwrite().
A shadow stack vma is writable but has different vma
flags, and handled accordingly in maybe_mkwrite().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
mm/memory.c | 5 ++---
mm/migrate.c | 3 +--
mm/mprotect.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
On Tue, Mar 16, 2021 at 08:10:47AM -0700, Yu-cheng Yu wrote:
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce vm_flags to do_mmap(), but without the old wrapper
do_mmap_pgoff().
You're operating on current here merrily but what's protecting all those
paths operating on current from getting current changed underneath them
due to scheduling? IOW, is preemption safely disabled in all those
paths ending up here?
+
+ while (1) {
Uuh, an endless loop. What guarantees we'll exit it relatively timely...
+ int r;
+
+ r = vm_munmap(cet->shstk_base, cet->shstk_size);
+
+ /*
+ * Retry if mmap_lock is not available.
+ */
+ if (r == -EINTR) {
+ cond_resched();
On Tue, Mar 16, 2021 at 08:10:47AM -0700, Yu-cheng Yu wrote:
quoted
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce vm_flags to do_mmap(), but without the old wrapper
do_mmap_pgoff().
Why does this matter at all?
$ git grep do_mmap_pgoff
$
Right, do_mmap_pgoff() was removed by commit 45e55300f114. This patch
does not add back the wrapper. Instead, add vm_flags to do_mmap().
Please advice if I misunderstand the question.
Thanks,
Yu-cheng
On Thu, Mar 18, 2021 at 08:59:28AM -0700, Yu, Yu-cheng wrote:
Right, do_mmap_pgoff() was removed by commit 45e55300f114. This patch does
not add back the wrapper. Instead, add vm_flags to do_mmap(). Please advice
if I misunderstand the question.
You're operating on current here merrily but what's protecting all those
paths operating on current from getting current changed underneath them
due to scheduling? IOW, is preemption safely disabled in all those
paths ending up here?
Good thought. Indeed, this looks like scheduling would bring some
trouble. However, when this instance is running, the current task must
be current, context switch or not. The purpose of this check is
described below.
When fork() fails, it calls exit_thread(), then cet_free_shstk().
Normally the child tsk->mm != current->mm (parent). There is no need to
free shadow stack.
For CLONE_VM, however, the kernel has already allocated a shadow stack
for the child and needs to free it because fork() failed.
Maybe I would add comments here.
quoted
+
+ while (1) {
Uuh, an endless loop. What guarantees we'll exit it relatively timely...
quoted
+ int r;
+
+ r = vm_munmap(cet->shstk_base, cet->shstk_size);
+
+ /*
+ * Retry if mmap_lock is not available.
+ */
+ if (r == -EINTR) {
+ cond_resched();
... that thing?
If vm_munmap() returns -EINTR, mmap_lock is held by something else.
That lock should not be held forever. For other types of error, the
loop stops.
On Thu, Mar 18, 2021 at 12:05:58PM -0700, Yu, Yu-cheng wrote:
Maybe I would add comments here.
Yap.
Also, looking forward in the set, I see prctl_set() and that is also
done on current so should be ok.
In any case, yes, documenting the assumptions and expectations wrt
current here is a good idea.
If vm_munmap() returns -EINTR, mmap_lock is held by something else. That
lock should not be held forever. For other types of error, the loop stops.
On Tue, Mar 16, 2021 at 08:10:49AM -0700, Yu-cheng Yu wrote:
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack, and
the address in a token must point directly above the token, which is within
the same shadow stack. This is distinctively different from other pointers
on the shadow stack; those pointers point to executable code area.
In sigreturn, restoring from a token ensures the target address is the
location pointed by the token.
Introduce WRUSS, which is a kernel-mode instruction but writes directly to
user shadow stack. It is used to construct the user signal stack as
described above.
Currently there is no systematic facility for extending a signal context.
Introduce a signal context extension 'struct sc_ext', which is used to save
shadow stack restore token address and WAIT_ENDBR status. WAIT_ENDBR will
be introduced later in the Indirect Branch Tracking (IBT) series, but add
that into sc_ext now to keep the struct stable in case the IBT series is
applied later.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/ia32/ia32_signal.c | 17 +++
arch/x86/include/asm/cet.h | 8 ++
arch/x86/include/asm/fpu/internal.h | 10 ++
arch/x86/include/asm/special_insns.h | 32 ++++++
arch/x86/include/uapi/asm/sigcontext.h | 9 ++
arch/x86/kernel/cet.c | 152 +++++++++++++++++++++++++
arch/x86/kernel/fpu/signal.c | 100 ++++++++++++++++
arch/x86/kernel/signal.c | 10 ++
8 files changed, 338 insertions(+)
On Thu, Mar 18, 2021 at 12:05:58PM -0700, Yu, Yu-cheng wrote:
quoted
Maybe I would add comments here.
Yap.
Also, looking forward in the set, I see prctl_set() and that is also
done on current so should be ok.
In any case, yes, documenting the assumptions and expectations wrt
current here is a good idea.
quoted
If vm_munmap() returns -EINTR, mmap_lock is held by something else. That
lock should not be held forever. For other types of error, the loop stops.
Ok I guess. The subsequent WARN_ON_ONCE() looks weird too but that
should not fire, right? :)
Thx.
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
We used to have shadow stack and ibt under separate Kconfig options, but in
a few places they actually share same code path, such as the XSAVES
supervisor states and ELF header for example. Anyways I will be happy to
make changes again if there is agreement.
I was look at:
x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states
didn't see any IBT logic - it's essentially all shadow stack state.
Which is not surprising, forward call edge integrity protection (IBT)
requires very little state, does it?
With IBT there's no nesting, no stack - the IBT state machine
basically requires the next instruction to be and ENDBR instruction,
and that's essentially it, right?
Thanks,
Ingo
Yes, that is it. The CET_WAIT_ENDBR bit is the status of IBT state
machine. There are a few bits in MSR_IA32_U_CET controlling how IBT
works, but those are not status.
Yu-cheng
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
quoted
In fact, I think all of this would improve is you remove the CET name
from all of this entirely. Put this series under CONFIG_X86_SHSTK (or
_SS) and use CONFIG_X86_IBT for the other one.
Similarly with the .c file.
All this CET business is just pure confusion.
What about this, we bring back CONFIG_X86_SHSTK and CONFIG_X86_IBT.
For the CET name itself, can we change it to CFE (Control Flow
Enforcement), or just CF?
In signal handling, ELF header parsing and arch_prctl(), shadow stack
and IBT pretty much share the same code. It is better not to split them
into two sets of files.
Thanks,
Yu-cheng
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 09:14:38
On Tue, Mar 16, 2021 at 08:10:33AM -0700, Yu-cheng Yu wrote:
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This results in ambiguity between shadow stack and
kernel read-only pages. To resolve this, removed Dirty from kernel read-
only pages.
Signed-off-by: Yu-cheng Yu <redacted>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Looks good to me.
Reviewed-by: Kirill A. Shutemov <redacted>
--
Kirill A. Shutemov
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 10:15:41
On Tue, Mar 16, 2021 at 08:10:38AM -0700, Yu-cheng Yu wrote:
quoted hunk
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can start a write but end up seeing
a read-only PTE by the time they get to the Dirty bit, creating a transient
shadow stack PTE. However, this will not occur on processors supporting
Shadow Stack, and a TLB flush is not necessary.
The second case is that when _PAGE_DIRTY is replaced with _PAGE_COW non-
atomically, a transient shadow stack PTE can be created as a result.
Thus, prevent that with cmpxchg.
Dave Hansen, Jann Horn, Andy Lutomirski, and Peter Zijlstra provided many
insights to the issue. Jann Horn provided the cmpxchg solution.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/pgtable.h | 36 ++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
I think this is wrong. You need to update old_pte on every loop iteration,
otherwise you can get in to endless loop.
The same issue for pmdp_set_wrprotect().
quoted hunk
+
+ return;
+ }
clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte);
}
@@ -1350,6 +1368,24 @@ static inline pud_t pudp_huge_get_and_clear(struct mm_struct *mm, static inline void pmdp_set_wrprotect(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) {+ /*+ * If Shadow Stack is enabled, pmd_wrprotect() moves _PAGE_DIRTY+ * to _PAGE_COW (see comments at pmd_wrprotect()).+ * When a thread reads a RW=1, Dirty=0 PMD and before changing it+ * to RW=0, Dirty=0, another thread could have written to the page+ * and the PMD is RW=1, Dirty=1 now. Use try_cmpxchg() to detect+ * PMD changes and update old_pmd, then try again.+ */+ if (cpu_feature_enabled(X86_FEATURE_SHSTK)) {+ pmd_t old_pmd, new_pmd;++ old_pmd = READ_ONCE(*pmdp);+ do {+ new_pmd = pmd_wrprotect(old_pmd);+ } while (!try_cmpxchg((pmdval_t *)pmdp, (pmdval_t *)&old_pmd, pmd_val(new_pmd)));++ return;+ } clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp); }
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 10:39:40
On Tue, Mar 16, 2021 at 08:10:40AM -0700, Yu-cheng Yu wrote:
quoted hunk
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
Shadow stacks accesses to shadow-stack mapping can see faults in normal,
valid operation just like regular accesses to regular mappings. Shadow
stacks need some of the same features like delayed allocation, swap and
copy-on-write.
Shadow stack accesses can also result in errors, such as when a shadow
stack overflows, or if a shadow stack access occurs to a non-shadow-stack
mapping.
In handling a shadow stack page fault, verify it occurs within a shadow
stack mapping. It is always an error otherwise. For valid shadow stack
accesses, set FAULT_FLAG_WRITE to effect copy-on-write. Because clearing
_PAGE_DIRTY (vs. _PAGE_RW) is used to trigger the fault, shadow stack read
fault and shadow stack write fault are not differentiated and both are
handled as a write access.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/trap_pf.h | 2 ++
arch/x86/mm/fault.c | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
I think it would be cleaner to allow arch code to override maybe_mkwrite()
and maybe_pmd_mkwrite() altogether. Wrap it into #ifndef maybe_mkwrite
here and provide VM_SHSTK-aware version from <asm/pgtable.h>.
--
Kirill A. Shutemov
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 10:56:27
On Tue, Mar 16, 2021 at 08:10:43AM -0700, Yu-cheng Yu wrote:
quoted hunk
INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the
first and the last elements in the range, effectively touches those memory
areas.
The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and
255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE.
Thus, putting a gap page on both ends of a shadow stack prevents INCSSP,
CALL, and RET from going beyond.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/page_64_types.h | 10 ++++++++++
include/linux/mm.h | 24 ++++++++++++++++++++----
2 files changed, 30 insertions(+), 4 deletions(-)
Looks too x86-centric for generic code.
Maybe we can have a helper that would return gap for the given VMA?
The generic version of the helper would only return stack_guard_gap for
VM_GROWSDOWN. Arch code would override it to handle VM_SHSTK case too.
Similar can be done in vm_end_gap().
quoted hunk
+
+ if (gap != 0) {
+ vm_start -= gap;
if (vm_start > vma->vm_start)
vm_start = 0;
}
@@ -2663,9 +2673,15 @@ static inline unsigned long vm_start_gap(struct vm_area_struct *vma) static inline unsigned long vm_end_gap(struct vm_area_struct *vma) { 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_SHSTK)+ gap = ARCH_SHADOW_STACK_GUARD_GAP;- if (vma->vm_flags & VM_GROWSUP) {- vm_end += stack_guard_gap;+ if (gap != 0) {+ vm_end += gap; if (vm_end < vma->vm_end) vm_end = -PAGE_SIZE; }
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 11:27:53
On Tue, Mar 16, 2021 at 08:10:54AM -0700, Yu-cheng Yu wrote:
quoted hunk
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters. Multiple parameters must be
passed in a memory buffer. There is a proposal to pass more parameters in
registers [1], but no active discussion on that.
A new syscall minimizes compatibility issues and offers an extensible frame
work to other architectures, but this will likely result in some overlap of
mmap()/mprotect().
The introduction of PROT_SHSTK to mmap()/mprotect() takes advantage of
existing APIs. The x86-specific PROT_SHSTK is translated to VM_SHSTK and
a shadow stack mapping is created without reinventing the wheel. There are
potential pitfalls though. The most obvious one would be using this as a
bypass to shadow stack protection. However, the attacker would have to get
to the syscall first.
[1] https://lore.kernel.org/lkml/20200828121624.108243-1-hjl.tools@gmail.com/
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
---
arch/x86/include/asm/mman.h | 57 +++++++++++++++++++++++++++++++-
arch/x86/include/uapi/asm/mman.h | 1 +
include/linux/mm.h | 1 +
mm/mmap.c | 8 ++++-
4 files changed, 65 insertions(+), 2 deletions(-)
+ return false;
+
+ if (prot & PROT_SHSTK) {
+ struct vm_area_struct *vma;
+
+ if (!current->thread.cet.shstk_size)
+ return false;
+
+ /*
+ * A shadow stack mapping is indirectly writable by only
+ * the CALL and WRUSS instructions, but not other write
+ * instructions). PROT_SHSTK and PROT_WRITE are mutually
+ * exclusive.
+ */
+ if (prot & PROT_WRITE)
+ return false;
+
+ vma = find_vma(current->mm, addr);
+ if (!vma)
+ return false;
NAK.
This is racy. arch_validate_prot() called outside of mmap_lock and the vma
may be freed or modified under us.
do_mprotect_pkey() already calls find_vma() with the right locking. Maybe
re-strucure do_mprotect_pkey() to call arch_validate_prot() after
find_vma() and pass down the vma?
quoted hunk
+
+ /*
+ * Shadow stack cannot be backed by a file or shared.
+ */
+ if (vma->vm_file || (vma->vm_flags & VM_SHARED))
+ return false;
+ }
+
+ return true;
+}
+
+#define arch_validate_prot arch_validate_prot
#endif
#endif /* _ASM_X86_MMAN_H */
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 11:28:58
On Tue, Mar 16, 2021 at 08:10:34AM -0700, Yu-cheng Yu wrote:
To prepare the introduction of _PAGE_COW, move pmd_write() and
pud_write() up in the file, so that they can be used by other
helpers below.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kirill A. Shutemov <redacted>
--
Kirill A. Shutemov
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 11:30:36
On Tue, Mar 16, 2021 at 08:10:35AM -0700, Yu-cheng Yu wrote:
There is essentially no room left in the x86 hardware PTEs on some OSes
(not 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.
The reason it's lightly used is that Dirty=1 is normally set by hardware
and cannot normally be set by hardware on a Write=0 PTE. Software must
normally be involved to create one of these PTEs, so software can simply
opt to not create them.
In places where Linux normally creates Write=0, Dirty=1, it can use the
software-defined _PAGE_COW in place of the hardware _PAGE_DIRTY. In other
words, whenever Linux needs to create Write=0, Dirty=1, it instead creates
Write=0, Cow=1, except for shadow stack, which is Write=0, Dirty=1. This
clearly separates shadow stack from other data, and results in the
following:
(a) A modified, copy-on-write (COW) page: (Write=0, Cow=1)
(b) A R/O page that has been COW'ed: (Write=0, Cow=1)
The user page is in a R/O VMA, and get_user_pages() 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 Cow=1.
(c) A shadow stack PTE: (Write=0, Dirty=1)
(d) A shared shadow stack PTE: (Write=0, Cow=1)
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.
(e) A page where the processor observed a Write=1 PTE, started a write, set
Dirty=1, but then observed a Write=0 PTE. That's possible today, but
will not happen on processors that support shadow stack.
Define _PAGE_COW and update pte_*() helpers and apply the same changes to
pmd and pud.
After this, there are six free bits left in the 64-bit PTE, and no more
free bits in the 32-bit PTE (except for PAE) and Shadow Stack is not
implemented for the 32-bit kernel.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kirill A. Shutemov <redacted>
--
Kirill A. Shutemov
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 11:31:42
On Tue, Mar 16, 2021 at 08:10:36AM -0700, Yu-cheng Yu wrote:
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY or _PAGE_COW. Change _PAGE_DIRTY to _PAGE_DIRTY_BITS.
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted>
Cc: David Airlie <redacted>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <redacted>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Zhenyu Wang <redacted>
Cc: Zhi Wang <redacted>
Reviewed-by: Kirill A. Shutemov <redacted>
--
Kirill A. Shutemov
From: Kirill A. Shutemov <hidden> Date: 2021-03-22 11:32:15
On Tue, Mar 16, 2021 at 08:10:37AM -0700, Yu-cheng Yu wrote:
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
pte_*() are updated.
Pte_modify() changes a PTE to 'newprot', but it doesn't use the pte_*().
Introduce fixup_dirty_pte(), which sets a dirty PTE, based on _PAGE_RW,
to either _PAGE_DIRTY or _PAGE_COW.
Apply the same changes to pmd_modify().
Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kirill A. Shutemov <redacted>
--
Kirill A. Shutemov
On Tue, Mar 16, 2021 at 08:10:33AM -0700, Yu-cheng Yu wrote:
quoted
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This results in ambiguity between shadow stack and
kernel read-only pages. To resolve this, removed Dirty from kernel read-
only pages.
Signed-off-by: Yu-cheng Yu <redacted>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Looks good to me.
Reviewed-by: Kirill A. Shutemov <redacted>
@@ -1100,6 +1100,17 @@ access_error(unsigned long error_code, struct vm_area_struct *vma)(error_code&X86_PF_INSTR),foreign))return1;+/*+*VerifyashadowstackaccessiswithinashadowstackVMA.+*Itisalwaysanerrorotherwise.Normaldataaccesstoa+*shadowstackareaischeckedinthecasefollowed.+*/+if(error_code&X86_PF_SHSTK){+if(!(vma->vm_flags&VM_SHSTK))+return1;+return0;
Any reason to return 0 here? I would rather keep the single return 0 in
the function, after all checks are done.
For shadow stack fault, X86_PF_SHSTK and X86_PF_WRITE both can be set.
So for shadow stack fault, return from here and don't go into the normal
write fault case.
Thanks,
Yu-cheng
quoted
+ }
+
if (error_code & X86_PF_WRITE) {
/* write, present and write, not present: */
if (unlikely(!(vma->vm_flags & VM_WRITE)))
@@ -1293,6 +1304,14 @@ void do_user_addr_fault(struct pt_regs *regs, perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);+ /*+ * Clearing _PAGE_DIRTY is used to detect shadow stack access.+ * This method cannot distinguish shadow stack read vs. write.+ * For valid shadow stack accesses, set FAULT_FLAG_WRITE to effect+ * copy-on-write.+ */+ if (error_code & X86_PF_SHSTK)+ flags |= FAULT_FLAG_WRITE; if (error_code & X86_PF_WRITE) flags |= FAULT_FLAG_WRITE; if (error_code & X86_PF_INSTR)
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-03-23 20:51:01
On Fri, Mar 19, 2021 at 02:43:04PM -0700, Yu, Yu-cheng wrote:
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
quoted
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
quoted
In fact, I think all of this would improve is you remove the CET name
from all of this entirely. Put this series under CONFIG_X86_SHSTK (or
_SS) and use CONFIG_X86_IBT for the other one.
Similarly with the .c file.
All this CET business is just pure confusion.
What about this, we bring back CONFIG_X86_SHSTK and CONFIG_X86_IBT.
For the CET name itself, can we change it to CFE (Control Flow Enforcement),
or just CF?
Carry Flag :-)
In signal handling, ELF header parsing and arch_prctl(), shadow stack and
IBT pretty much share the same code. It is better not to split them into
two sets of files.
Aside from redoing the UAPI we're stuck with that I suppose :/ And since
I think the CET name is all over the UAPI, you might as well keep it for
the kernel part of it as well :-(
But if there's sufficient !UAPI bits it might still make sense to also
have ibt.c and shstk.c
On Fri, Mar 19, 2021 at 02:43:04PM -0700, Yu, Yu-cheng wrote:
quoted
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
quoted
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level protection, and has three parts:
- Shadow stack [2],
- Indirect branch tracking [3], and
- Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
quoted
In fact, I think all of this would improve is you remove the CET name
from all of this entirely. Put this series under CONFIG_X86_SHSTK (or
_SS) and use CONFIG_X86_IBT for the other one.
Similarly with the .c file.
All this CET business is just pure confusion.
What about this, we bring back CONFIG_X86_SHSTK and CONFIG_X86_IBT.
For the CET name itself, can we change it to CFE (Control Flow Enforcement),
or just CF?
Carry Flag :-)
quoted
In signal handling, ELF header parsing and arch_prctl(), shadow stack and
IBT pretty much share the same code. It is better not to split them into
two sets of files.
Aside from redoing the UAPI we're stuck with that I suppose :/ And since
I think the CET name is all over the UAPI, you might as well keep it for
the kernel part of it as well :-(
But if there's sufficient !UAPI bits it might still make sense to also
have ibt.c and shstk.c
I will move code around and separate it into shadow stack and ibt.
Hopefully in the next iteration, things will be more organized.
Thanks,
Yu-cheng
@@ -3387,6 +3390,8 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages) mm->stack_vm += npages; else if (is_data_mapping(flags)) mm->data_vm += npages;+ else if (arch_shadow_stack_mapping(flags))+ mm->stack_vm += npages;
Ditto.
The thought was, here all testings are done with helpers, e.g.
is_data_mapping(), so creating a helper for shadow stack is more inline
with the existing code. Or, maybe we can call it
is_shadow_stack_mapping()? And, since we have a helper, use it in
accountable_mapping() as well. Or do you have other suggestions?
Thanks,
Yu-cheng
@@ -3387,6 +3390,8 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages) mm->stack_vm += npages; else if (is_data_mapping(flags)) mm->data_vm += npages;+ else if (arch_shadow_stack_mapping(flags))+ mm->stack_vm += npages;
Ditto.
The thought was, here all testings are done with helpers, e.g.
is_data_mapping(), so creating a helper for shadow stack is more inline with
the existing code. Or, maybe we can call it is_shadow_stack_mapping()?
And, since we have a helper, use it in accountable_mapping() as well. Or do
you have other suggestions?
is_shadow_stack_mapping() sounds reasonable.
My point is that we already have ifdef around #define VM_SHSTK. No need in
duplicating it for helper.
--
Kirill A. Shutemov