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 <[email protected]>
---
arch/x86/Kconfig | 22 ++++++++++++++++++++++
arch/x86/Kconfig.assembler | 5 +++++
2 files changed, 27 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..2d080a2335df 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1951,6 +1951,28 @@ config X86_SGX
If unsure, say N.
+config ARCH_HAS_SHADOW_STACK
+ def_bool n
+
+config X86_CET
+ prompt "Intel Control-flow protection for user-mode"
+ def_bool n
+ depends on CPU_SUP_INTEL && X86_64
+ depends on AS_WRUSS
+ select ARCH_USES_HIGH_VMA_FLAGS
+ select ARCH_HAS_SHADOW_STACK
+ help
+ Control-flow protection is a hardware security hardening feature
+ that detects function-return address or jump target changes by
+ malicious code. Applications must be enabled to use it, and old
+ userspace does not get protection "for free".
+ Support for this feature is present on processors released in
+ 2020 or later. Enabling this feature increases kernel text size
+ by 3.7 KB.
+ See Documentation/x86/intel_cet.rst for more information.
+
+ If unsure, say N.
+
config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/Kconfig.assembler b/arch/x86/Kconfig.assembler
index 26b8c08e2fc4..00c79dd93651 100644
--- a/arch/x86/Kconfig.assembler
+++ b/arch/x86/Kconfig.assembler
@@ -19,3 +19,8 @@ config AS_TPAUSE
def_bool $(as-instr,tpause %ecx)
help
Supported by binutils >= 2.31.1 and LLVM integrated assembler >= V7
+
+config AS_WRUSS
+ def_bool $(as-instr,wrussq %rax$(comma)(%rbx))
+ help
+ Supported by binutils >= 2.31 and LLVM integrated assembler
--
2.21.0
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
> + help
> + Control-flow protection is a hardware security hardening feature
> + that detects function-return address or jump target changes by
> + malicious code.
It's not really one feature. I also think it's not worth talking about
shadow stacks or indirect branch tracking in *here*. Leave that for
Documentation/.
Just say:
Control-flow protection is a set of hardware features which
place additional restrictions on indirect branches. These help
mitigate ROP attacks.
... and add more in the IBT patches.
> Applications must be enabled to use it, and old
> + userspace does not get protection "for free".
> + Support for this feature is present on processors released in
> + 2020 or later. Enabling this feature increases kernel text size
> + by 3.7 KB.
Did any CPUs ever get released that have this? If so, name them. If
not, time to change this to 2021, I think.
> On Jan 29, 2021, at 11:42 AM, Dave Hansen <[email protected]> wrote:
>
> On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
>> + help
>> + Control-flow protection is a hardware security hardening feature
>> + that detects function-return address or jump target changes by
>> + malicious code.
>
> It's not really one feature. I also think it's not worth talking about
> shadow stacks or indirect branch tracking in *here*. Leave that for
> Documentation/.
>
> Just say:
>
> Control-flow protection is a set of hardware features which
> place additional restrictions on indirect branches. These help
> mitigate ROP attacks.
>
> ... and add more in the IBT patches.
>
>> Applications must be enabled to use it, and old
>> + userspace does not get protection "for free".
>> + Support for this feature is present on processors released in
>> + 2020 or later. Enabling this feature increases kernel text size
>> + by 3.7 KB.
>
> Did any CPUs ever get released that have this? If so, name them. If
> not, time to change this to 2021, I think.
Zen 3 :)
On 1/29/2021 11:42 AM, Dave Hansen wrote:
> On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
>> + help
>> + Control-flow protection is a hardware security hardening feature
>> + that detects function-return address or jump target changes by
>> + malicious code.
>
> It's not really one feature. I also think it's not worth talking about
> shadow stacks or indirect branch tracking in *here*. Leave that for
> Documentation/.
>
> Just say:
>
> Control-flow protection is a set of hardware features which
> place additional restrictions on indirect branches. These help
> mitigate ROP attacks.
>
> ... and add more in the IBT patches.
>
>> Applications must be enabled to use it, and old
>> + userspace does not get protection "for free".
>> + Support for this feature is present on processors released in
>> + 2020 or later. Enabling this feature increases kernel text size
>> + by 3.7 KB.
>
> Did any CPUs ever get released that have this? If so, name them. If
> not, time to change this to 2021, I think.
>
Ok. I will update this.
Yu-cheng
On 1/29/21 11:58 AM, Andy Lutomirski wrote:
>> Did any CPUs ever get released that have this? If so, name them. If
>> not, time to change this to 2021, I think.
> Zen 3 :)
In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
On Fri, Jan 29, 2021 at 12:33:43PM -0800, Dave Hansen wrote:
> In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
Probably not. I haven't heard of the AMD implementation being somehow
different from Intel's.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 1/29/2021 12:46 PM, Borislav Petkov wrote:
> On Fri, Jan 29, 2021 at 12:33:43PM -0800, Dave Hansen wrote:
>> In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
>
> Probably not. I haven't heard of the AMD implementation being somehow
> different from Intel's.
>
Ok, I will remove it.