| Message ID | 20201110162211.9207-6-yu-cheng.yu@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Control-flow Enforcement: Shadow Stack | expand |
On Tue, Nov 10, 2020 at 08:21:50AM -0800, Yu-cheng Yu wrote: > +config X86_CET > + def_bool n > + > +config ARCH_HAS_SHADOW_STACK > + def_bool n > + > +config X86_SHADOW_STACK_USER Is X86_SHADOW_STACK_KERNEL coming too? Regardless, you can add it when it comes and you can use only X86_CET for now and drop this one and simplify this pile of Kconfig symbols. > + prompt "Intel Shadow Stacks for user-mode" > + def_bool n > + depends on CPU_SUP_INTEL && X86_64 > + depends on AS_HAS_SHADOW_STACK > + select ARCH_USES_HIGH_VMA_FLAGS > + select X86_CET > + select ARCH_HAS_SHADOW_STACK > + help > + Shadow Stacks provides protection against program stack > + corruption. It's a hardware feature. This only matters > + if you have the right hardware. It's a security hardening > + feature and apps must be enabled to use it. You get no > + protection "for free" on old userspace. The hardware can > + support user and kernel, but this option is for user space > + only. > + Support for this feature is only known to be present on > + processors released in 2020 or later. CET features are also > + known to increase kernel text size by 3.7 KB. This help text needs some rewriting. You can find an inspiration about more adequate style in that same Kconfig file. > + > + If unsure, say N. > + > config EFI > bool "EFI runtime service support" > depends on ACPI > diff --git a/scripts/as-x86_64-has-shadow-stack.sh b/scripts/as-x86_64-has-shadow-stack.sh > new file mode 100755 > index 000000000000..fac1d363a1b8 > --- /dev/null > +++ b/scripts/as-x86_64-has-shadow-stack.sh > @@ -0,0 +1,4 @@ > +#!/bin/sh > +# SPDX-License-Identifier: GPL-2.0 > + > +echo "wrussq %rax, (%rbx)" | $* -x assembler -c - 2> /dev/null otherwise you get {standard input}: Assembler messages: {standard input}:1: Error: no such instruction: `wrussq %rax,(%rbx) on non-enlightened toolchains during build. Thx.
On 11/27/2020 9:10 AM, Borislav Petkov wrote: > On Tue, Nov 10, 2020 at 08:21:50AM -0800, Yu-cheng Yu wrote: >> +config X86_CET >> + def_bool n >> + >> +config ARCH_HAS_SHADOW_STACK >> + def_bool n >> + >> +config X86_SHADOW_STACK_USER > > Is X86_SHADOW_STACK_KERNEL coming too? > > Regardless, you can add it when it comes and you can use only X86_CET > for now and drop this one and simplify this pile of Kconfig symbols. We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of kernel/user shadow stack/ibt. > >> + prompt "Intel Shadow Stacks for user-mode" >> + def_bool n >> + depends on CPU_SUP_INTEL && X86_64 >> + depends on AS_HAS_SHADOW_STACK >> + select ARCH_USES_HIGH_VMA_FLAGS >> + select X86_CET >> + select ARCH_HAS_SHADOW_STACK >> + help >> + Shadow Stacks provides protection against program stack >> + corruption. It's a hardware feature. This only matters >> + if you have the right hardware. It's a security hardening >> + feature and apps must be enabled to use it. You get no >> + protection "for free" on old userspace. The hardware can >> + support user and kernel, but this option is for user space >> + only. >> + Support for this feature is only known to be present on >> + processors released in 2020 or later. CET features are also >> + known to increase kernel text size by 3.7 KB. > > This help text needs some rewriting. You can find an inspiration about > more adequate style in that same Kconfig file. > I will work on it. >> + >> + If unsure, say N. >> + >> config EFI >> bool "EFI runtime service support" >> depends on ACPI >> diff --git a/scripts/as-x86_64-has-shadow-stack.sh b/scripts/as-x86_64-has-shadow-stack.sh >> new file mode 100755 >> index 000000000000..fac1d363a1b8 >> --- /dev/null >> +++ b/scripts/as-x86_64-has-shadow-stack.sh >> @@ -0,0 +1,4 @@ >> +#!/bin/sh >> +# SPDX-License-Identifier: GPL-2.0 >> + >> +echo "wrussq %rax, (%rbx)" | $* -x assembler -c - > > 2> /dev/null > > otherwise you get > > {standard input}: Assembler messages: > {standard input}:1: Error: no such instruction: `wrussq %rax,(%rbx) > > on non-enlightened toolchains during build. > Yes, I will fix this in the next revision. Yu-cheng > Thx. >
On Sat, Nov 28, 2020 at 08:23:59AM -0800, Yu, Yu-cheng wrote: > We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of > kernel/user shadow stack/ibt. It is not about what it means - it is what you're going to use/need. You have ifdeffery both with X86_CET and X86_SHADOW_STACK_USER. This one +#ifdef CONFIG_X86_SHADOW_STACK_USER +#define DISABLE_SHSTK 0 +#else +#define DISABLE_SHSTK (1 << (X86_FEATURE_SHSTK & 31)) +#endif for example, is clearly wrong and wants to be #ifdef CONFIG_X86_CET, for example. Unless I'm missing something totally obvious. In any case, you need to analyze what Kconfig defines the code will need and to what they belong and add only the minimal subset needed. Our Kconfig symbols space is already nuts so adding more needs to be absolutely justified. Thx.
In response to https://lore.kernel.org/lkml/20201110162211.9207-6-yu-cheng.yu@intel.com/. Hi Yu-cheng, This feature reminds me very much of ARCH_SUPPORTS_SHADOW_CALL_STACK/CC_HAVE_SHADOW_CALL_STACK implemented in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5287569a790d2546a06db07e391bf84b8bd6cf51. Do you think it would be worthwhile to share the same config name between x86 and aarch64? (Though, it seems on x86 there will be a distinction between kernel mode and user mode configs, if I understand correctly?)
On 11/30/2020 11:56 AM, Nick Desaulniers wrote: > In response to https://lore.kernel.org/lkml/20201110162211.9207-6-yu-cheng.yu@intel.com/. > > Hi Yu-cheng, > This feature reminds me very much of > ARCH_SUPPORTS_SHADOW_CALL_STACK/CC_HAVE_SHADOW_CALL_STACK implemented in > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5287569a790d2546a06db07e391bf84b8bd6cf51. > > Do you think it would be worthwhile to share the same config name between x86 > and aarch64? The CET series has ARCH_HAS_SHADOW_STACK. In response to Boris' earlier comment, I think this maybe eliminated. In case it is still needed, I think it is better to have different names (but I am open to changing it). > > (Though, it seems on x86 there will be a distinction between kernel mode and > user mode configs, if I understand correctly?) > Yes, on x86, kernel and user-mode can be enabled separately. Yu-cheng
On 11/30/2020 10:15 AM, Borislav Petkov wrote: > On Sat, Nov 28, 2020 at 08:23:59AM -0800, Yu, Yu-cheng wrote: >> We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of >> kernel/user shadow stack/ibt. > > It is not about what it means - it is what you're going to use/need. You have > ifdeffery both with X86_CET and X86_SHADOW_STACK_USER. > > This one > > +#ifdef CONFIG_X86_SHADOW_STACK_USER > +#define DISABLE_SHSTK 0 > +#else > +#define DISABLE_SHSTK (1 << (X86_FEATURE_SHSTK & 31)) > +#endif > > for example, is clearly wrong and wants to be #ifdef CONFIG_X86_CET, for > example. Unless I'm missing something totally obvious. Logically, enabling IBT without shadow stack does not make sense, but these features have different CPUIDs, and CONFIG_X86_SHADOW_STACK_USER and CONFIG_X86_BRANCH_TRACKING_USER can be selected separately. Do we want to have only one selection for both features? In other words, we turn on both or neither. Thanks, Yu-cheng > > In any case, you need to analyze what Kconfig defines the code will > need and to what they belong and add only the minimal subset needed. > Our Kconfig symbols space is already nuts so adding more needs to be > absolutely justified. > > Thx. >
On Mon, Nov 30, 2020 at 02:48:09PM -0800, Yu, Yu-cheng wrote: > Logically, enabling IBT without shadow stack does not make sense, but these > features have different CPUIDs, and CONFIG_X86_SHADOW_STACK_USER and > CONFIG_X86_BRANCH_TRACKING_USER can be selected separately. > > Do we want to have only one selection for both features? In other words, we > turn on both or neither. Question is, do they need to be handled separately at all? If not and IOW, I like dhansen's X86_FEATURE_CET synthetic feature suggestion. Thx.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f6946b81f74a..a51d2a3de166 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1930,6 +1930,39 @@ config X86_INTEL_TSX_MODE_AUTO side channel attacks- equals the tsx=auto command line parameter. endchoice +config AS_HAS_SHADOW_STACK + def_bool $(success,$(srctree)/scripts/as-x86_64-has-shadow-stack.sh $(CC)) + help + Test the assembler for shadow stack instructions. + +config X86_CET + def_bool n + +config ARCH_HAS_SHADOW_STACK + def_bool n + +config X86_SHADOW_STACK_USER + prompt "Intel Shadow Stacks for user-mode" + def_bool n + depends on CPU_SUP_INTEL && X86_64 + depends on AS_HAS_SHADOW_STACK + select ARCH_USES_HIGH_VMA_FLAGS + select X86_CET + select ARCH_HAS_SHADOW_STACK + help + Shadow Stacks provides protection against program stack + corruption. It's a hardware feature. This only matters + if you have the right hardware. It's a security hardening + feature and apps must be enabled to use it. You get no + protection "for free" on old userspace. The hardware can + support user and kernel, but this option is for user space + only. + Support for this feature is only known to be present on + processors released in 2020 or later. CET features are also + known to increase kernel text size by 3.7 KB. + + If unsure, say N. + config EFI bool "EFI runtime service support" depends on ACPI diff --git a/scripts/as-x86_64-has-shadow-stack.sh b/scripts/as-x86_64-has-shadow-stack.sh new file mode 100755 index 000000000000..fac1d363a1b8 --- /dev/null +++ b/scripts/as-x86_64-has-shadow-stack.sh @@ -0,0 +1,4 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0 + +echo "wrussq %rax, (%rbx)" | $* -x assembler -c -
Shadow Stack provides protection against function return address corruption. It is active when the processor supports it, the kernel has CONFIG_X86_SHADOW_STACK_USER, 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 <yu-cheng.yu@intel.com> --- arch/x86/Kconfig | 33 +++++++++++++++++++++++++++ scripts/as-x86_64-has-shadow-stack.sh | 4 ++++ 2 files changed, 37 insertions(+) create mode 100755 scripts/as-x86_64-has-shadow-stack.sh