| Message ID | 20200327192107.18394-6-broonie@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: Initial BTI kernel support | expand |
On Fri, Mar 27, 2020 at 07:21:07PM +0000, Mark Brown wrote: > Now that all the code is in place provide a Kconfig option allowing users > to enable BTI for the kernel if their toolchain supports it, defaulting it > on since this has security benefits. This is a separate configuration > option since we currently don't support secondary CPUs that lack BTI if > the boot CPU supports it. > > Current testing appears to show an issue with GCC which causes it to > emit unsuitable landing pads for function entries in some cases, until > this issue is understood and either our usage fixed or a suitable > version of GCC is identified the feature is marked as incompatible with > GCC. No issues have been identified with clang. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/Kconfig | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 00cb4db4beab..25bb0931b2ba 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1607,6 +1607,24 @@ config ARM64_BTI > BTI, such binaries can still run, but you get no additional > enforcement of branch destinations. > > +config ARM64_BTI_KERNEL > + bool "Use Branch Target Identification for kernel" > + default y > + depends on ARM64_BTI > + depends on ARM64_PTR_AUTH > + depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI (this depend can be dropped with my crazy Makefile suggestion) > + depends on !CC_IS_GCC > + depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS) > + help > + Build the kernel with Branch Target Identification annotations > + and enable enforcement of this for kernel code. When this option > + is enabled and the system supports BTI all kernel code including > + modular code must have BTI enabled. > + > +config CC_HAS_BRANCH_PROT_PAC_RET_BTI > + # GCC 9 or later, clang 8 or later > + def_bool $(cc-option,-mbranch-protection=pac-ret+leaf+bti) Exciting! :) > + > config ARM64_E0PD > bool "Enable support for E0PD" > default y > -- > 2.20.1 >
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 00cb4db4beab..25bb0931b2ba 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1607,6 +1607,24 @@ config ARM64_BTI BTI, such binaries can still run, but you get no additional enforcement of branch destinations. +config ARM64_BTI_KERNEL + bool "Use Branch Target Identification for kernel" + default y + depends on ARM64_BTI + depends on ARM64_PTR_AUTH + depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI + depends on !CC_IS_GCC + depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS) + help + Build the kernel with Branch Target Identification annotations + and enable enforcement of this for kernel code. When this option + is enabled and the system supports BTI all kernel code including + modular code must have BTI enabled. + +config CC_HAS_BRANCH_PROT_PAC_RET_BTI + # GCC 9 or later, clang 8 or later + def_bool $(cc-option,-mbranch-protection=pac-ret+leaf+bti) + config ARM64_E0PD bool "Enable support for E0PD" default y
Now that all the code is in place provide a Kconfig option allowing users to enable BTI for the kernel if their toolchain supports it, defaulting it on since this has security benefits. This is a separate configuration option since we currently don't support secondary CPUs that lack BTI if the boot CPU supports it. Current testing appears to show an issue with GCC which causes it to emit unsuitable landing pads for function entries in some cases, until this issue is understood and either our usage fixed or a suitable version of GCC is identified the feature is marked as incompatible with GCC. No issues have been identified with clang. Signed-off-by: Mark Brown <broonie@kernel.org> --- arch/arm64/Kconfig | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)