Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
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
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
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
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
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
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
On 3/17/2021 2:18 AM, Ingo Molnar wrote: * 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. 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
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
On Wed, Mar 17, 2021 at 10:18:00AM +0100, Ingo Molnar wrote: > > * 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. > > > > 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.
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
* 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. > > 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
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
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.
Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack
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.
