diff mbox series

[v18,02/25] x86/cet/shstk: Add Kconfig option for user-mode control-flow protection

Message ID 20210127212524.10188-3-yu-cheng.yu@intel.com (mailing list archive)
State New
Headers show
Series Control-flow Enforcement: Shadow Stack | expand

Commit Message

Yu, Yu-cheng Jan. 27, 2021, 9:25 p.m. UTC
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 <yu-cheng.yu@intel.com>
---
 arch/x86/Kconfig           | 22 ++++++++++++++++++++++
 arch/x86/Kconfig.assembler |  5 +++++
 2 files changed, 27 insertions(+)

Comments

Dave Hansen Jan. 29, 2021, 7:42 p.m. UTC | #1
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.
Andy Lutomirski Jan. 29, 2021, 7:58 p.m. UTC | #2
> On Jan 29, 2021, at 11:42 AM, Dave Hansen <dave.hansen@intel.com> 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 :)
Yu, Yu-cheng Jan. 29, 2021, 8 p.m. UTC | #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
Dave Hansen Jan. 29, 2021, 8:33 p.m. UTC | #4
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"?
Borislav Petkov Jan. 29, 2021, 8:46 p.m. UTC | #5
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.
Yu, Yu-cheng Jan. 29, 2021, 9:13 p.m. UTC | #6
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.
diff mbox series

Patch

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