| Message ID | 20210316151054.5405-1-yu-cheng.yu@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Control-flow Enforcement: Shadow Stack | expand |
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 3/16/2021 2:15 PM, Peter Zijlstra wrote: > 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. 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. >
* Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote: > On 3/16/2021 2:15 PM, Peter Zijlstra wrote: > > 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. > > 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
On Wed, Mar 17, 2021 at 10:18:00AM +0100, Ingo Molnar wrote: > > * Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote: > > > On 3/16/2021 2:15 PM, Peter Zijlstra wrote: > > > 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. > > > > 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 3/17/2021 2:18 AM, Ingo Molnar wrote: > > * Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote: > >> On 3/16/2021 2:15 PM, Peter Zijlstra wrote: >>> 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. >> >> 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 3/16/2021 2:15 PM, Peter Zijlstra wrote: > 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. > 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
On Fri, Mar 19, 2021 at 02:43:04PM -0700, Yu, Yu-cheng wrote: > On 3/16/2021 2:15 PM, Peter Zijlstra wrote: > > 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. > > > > 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 3/23/2021 1:49 PM, Peter Zijlstra wrote: > On Fri, Mar 19, 2021 at 02:43:04PM -0700, Yu, Yu-cheng wrote: >> On 3/16/2021 2:15 PM, Peter Zijlstra wrote: >>> 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. >>> >> >> 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 > 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
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]. I have run tests on these patches for quite some time, and they have been very stable. Linux distributions with CET are available now, and Intel processors with CET are already on the market. It would be nice if CET support can be accepted into the kernel. I will be working to address any issues should they come up. Changes in v23: - Rebase to Linus tree v5.12-rc3. [1] Intel 64 and IA-32 Architectures Software Developer's Manual: https://software.intel.com/en-us/download/intel-64-and-ia-32- architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4 [2] CET Shadow Stack patches v22: https://lore.kernel.org/r/20210310220046.15866-1-yu-cheng.yu@intel.com/ [3] Indirect Branch Tracking patches v22. https://lore.kernel.org/r/20210310220519.16811-1-yu-cheng.yu@intel.com/ [4] I am holding off the selftests changes and working to get Reviewed-by's. The earlier version of the selftests patches: https://lkml.kernel.org/r/20200521211720.20236-1-yu-cheng.yu@intel.com/ [5] The kernel ptrace patch is tested with an Intel-internal updated GDB. I am holding off the kernel ptrace patch to re-test it with my earlier patch for fixing regset holes. Yu-cheng Yu (28): Documentation/x86: Add CET description x86/cet/shstk: Add Kconfig option for user-mode control-flow protection x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET) x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states x86/cet: Add 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 drm/i915/gvt: Change _PAGE_DIRTY to _PAGE_DIRTY_BITS 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: Introduce VM_SHSTK for shadow stack memory x86/mm: Shadow Stack page fault error checking 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: Update can_follow_write_pte() for shadow stack mm/mprotect: Exclude shadow stack from preserve_write mm: Re-introduce vm_flags to do_mmap() x86/cet/shstk: User-mode shadow stack support x86/cet/shstk: Handle signals for shadow stack ELF: Introduce arch_setup_elf_property() x86/cet/shstk: Handle thread shadow stack x86/cet/shstk: Add arch_prctl functions for shadow stack mm: Move arch_calc_vm_prot_bits() to arch/x86/include/asm/mman.h mm: Introduce PROT_SHSTK for shadow stack .../admin-guide/kernel-parameters.txt | 6 + Documentation/filesystems/proc.rst | 1 + Documentation/x86/index.rst | 1 + Documentation/x86/intel_cet.rst | 136 +++++++ arch/arm64/include/asm/elf.h | 5 + arch/x86/Kconfig | 28 ++ arch/x86/Kconfig.assembler | 5 + arch/x86/ia32/ia32_signal.c | 17 + arch/x86/include/asm/cet.h | 44 +++ arch/x86/include/asm/cpufeatures.h | 4 +- arch/x86/include/asm/disabled-features.h | 17 +- arch/x86/include/asm/elf.h | 13 + arch/x86/include/asm/fpu/internal.h | 10 + arch/x86/include/asm/fpu/types.h | 23 +- arch/x86/include/asm/fpu/xstate.h | 6 +- arch/x86/include/asm/idtentry.h | 4 + arch/x86/include/asm/mman.h | 85 +++++ arch/x86/include/asm/mmu_context.h | 3 + arch/x86/include/asm/msr-index.h | 19 + arch/x86/include/asm/page_64_types.h | 10 + arch/x86/include/asm/pgtable.h | 290 +++++++++++++-- arch/x86/include/asm/pgtable_types.h | 48 ++- arch/x86/include/asm/processor.h | 5 + arch/x86/include/asm/special_insns.h | 32 ++ arch/x86/include/asm/trap_pf.h | 2 + arch/x86/include/uapi/asm/mman.h | 28 +- arch/x86/include/uapi/asm/prctl.h | 4 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/include/uapi/asm/sigcontext.h | 9 + arch/x86/kernel/Makefile | 2 + arch/x86/kernel/cet.c | 348 ++++++++++++++++++ arch/x86/kernel/cet_prctl.c | 60 +++ arch/x86/kernel/cpu/common.c | 14 + arch/x86/kernel/cpu/cpuid-deps.c | 2 + arch/x86/kernel/cpu/intel.c | 3 + arch/x86/kernel/fpu/signal.c | 100 +++++ arch/x86/kernel/fpu/xstate.c | 10 +- arch/x86/kernel/idt.c | 4 + arch/x86/kernel/process.c | 21 +- arch/x86/kernel/process_64.c | 32 ++ arch/x86/kernel/signal.c | 10 + arch/x86/kernel/signal_compat.c | 2 +- arch/x86/kernel/traps.c | 63 ++++ arch/x86/mm/fault.c | 19 + arch/x86/mm/mmap.c | 2 + arch/x86/mm/pat/set_memory.c | 2 +- arch/x86/mm/pgtable.c | 25 ++ drivers/gpu/drm/i915/gvt/gtt.c | 2 +- fs/aio.c | 2 +- fs/binfmt_elf.c | 4 + fs/proc/task_mmu.c | 3 + include/linux/elf.h | 6 + include/linux/mm.h | 38 +- include/linux/pgtable.h | 35 ++ include/uapi/asm-generic/siginfo.h | 3 +- include/uapi/linux/elf.h | 9 + ipc/shm.c | 2 +- mm/gup.c | 8 +- mm/huge_memory.c | 17 +- mm/memory.c | 5 +- mm/migrate.c | 3 +- mm/mmap.c | 23 +- mm/mprotect.c | 11 +- mm/nommu.c | 4 +- mm/util.c | 2 +- 65 files changed, 1645 insertions(+), 108 deletions(-) create mode 100644 Documentation/x86/intel_cet.rst create mode 100644 arch/x86/include/asm/cet.h create mode 100644 arch/x86/include/asm/mman.h create mode 100644 arch/x86/kernel/cet.c create mode 100644 arch/x86/kernel/cet_prctl.c