| Message ID | 20200429211641.9279-2-broonie@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: BTI kernel and vDSO support | expand |
On Wed, Apr 29, 2020 at 10:16:32PM +0100, Mark Brown wrote: > When running with BTI enabled we need to ask the compiler to enable > generation of BTI landing pads beyond those generated as a result of > pointer authentication instructions being landing pads. Since the two > features are practically speaking unlikely to be used separately we > will make kernel mode BTI depend on pointer authentication in order > to simplify the Makefile. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/Makefile | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 85e4149cc5d5..90150b5b180e 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -71,7 +71,11 @@ branch-prot-flags-y += $(call cc-option,-mbranch-protection=none) > > ifeq ($(CONFIG_ARM64_PTR_AUTH),y) > branch-prot-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all > +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) > +branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti > +else > branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf > +endif Is it worth a comment to explain how this differs from -mbranch-protection=standard, and why we're not using that here? Cheers ---Dave
On Tue, May 05, 2020 at 05:50:45PM +0100, Dave Martin wrote: > On Wed, Apr 29, 2020 at 10:16:32PM +0100, Mark Brown wrote: > > +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) > > +branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti > > +else > > branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf > > +endif > Is it worth a comment to explain how this differs from > -mbranch-protection=standard, and why we're not using that here? There was some open discussion in a separate thread about the use of +leaf: https://lore.kernel.org/linux-arm-kernel/1588149371-20310-1-git-send-email-amit.kachhap@arm.com/ which currently settled on leaving it in but I do agree, it probably would be useful to document the choices we're making here. CCing Amit as some of the discussion was off-list so I don't know all the details there. As with the recent change to explicitly default to branch-protection=none there's probably a case for simply being explicit about whatever we're doing rather than relying on compiler defaults in case there are any bad interactions with code generated for an extension that isn't fully supported in the kernel in the future.
Hi, On 5/5/20 11:01 PM, Mark Brown wrote: > On Tue, May 05, 2020 at 05:50:45PM +0100, Dave Martin wrote: >> On Wed, Apr 29, 2020 at 10:16:32PM +0100, Mark Brown wrote: > >>> +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) >>> +branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti >>> +else >>> branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf >>> +endif > >> Is it worth a comment to explain how this differs from >> -mbranch-protection=standard, and why we're not using that here? > > There was some open discussion in a separate thread about the use of > +leaf: > > https://lore.kernel.org/linux-arm-kernel/1588149371-20310-1-git-send-email-amit.kachhap@arm.com/ > > which currently settled on leaving it in but I do agree, it probably > would be useful to document the choices we're making here. CCing Amit > as some of the discussion was off-list so I don't know all the details > there. It was decided to retain the strictest ptrauth compiler option as there is a narrow scope of ROP protection use-case in case of leaf function. Although I provided some static benefits in diluting this requirement but it was suggested to differ it till there is some run-time performance gain data for leaf functions. Yes documenting it here makes sense. Cheers, Amit Daniel > > As with the recent change to explicitly default to branch-protection=none > there's probably a case for simply being explicit about whatever we're > doing rather than relying on compiler defaults in case there are any bad > interactions with code generated for an extension that isn't fully > supported in the kernel in the future. >
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 85e4149cc5d5..90150b5b180e 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -71,7 +71,11 @@ branch-prot-flags-y += $(call cc-option,-mbranch-protection=none) ifeq ($(CONFIG_ARM64_PTR_AUTH),y) branch-prot-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all +ifeq ($(CONFIG_ARM64_BTI_KERNEL),y) +branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti +else branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf +endif # -march=armv8.3-a enables the non-nops instructions for PAC, to avoid the # compiler to generate them and consequently to break the single image contract # we pass it only to the assembler. This option is utilized only in case of non
When running with BTI enabled we need to ask the compiler to enable generation of BTI landing pads beyond those generated as a result of pointer authentication instructions being landing pads. Since the two features are practically speaking unlikely to be used separately we will make kernel mode BTI depend on pointer authentication in order to simplify the Makefile. Signed-off-by: Mark Brown <broonie@kernel.org> --- arch/arm64/Makefile | 4 ++++ 1 file changed, 4 insertions(+)