| Message ID | 20220808141230.282354-1-rasmus.villemoes@prevas.dk |
|---|---|
| State | Accepted |
| Commit | 4b053019792d5c71f8b2e988c34c6352816c5aac |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | arm64: explicitly disable pointer authentication instructions | expand |
On Mon, 8 Aug 2022 at 08:12, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > The Yocto project builds their aarch64 cross-compiler with the > configure knob --enable-standard-branch-protection, which means that > their gcc behaves as if -mbranch-protection=standard is passed; the > default (lacking that configure knob) is -mbranch-protection=none. > > This means that when building U-Boot using the Yocto toolchain, most > functions end up containing paciasp/autiasp/bti instructions. However, > since U-Boot is not an ordinary userspace application, there's no OS > kernel which has set up the required authentication keys, so these > instructions do nothing at all (even on arm64 hardware that does have > the pointer authentication capability). They do however make the image > larger. > > It is theoretically possible for U-Boot to make use of the pointer > authentication protection - cf. the linux kernel's > CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's > hard to see just what threat model it would protect against in a > bootloader context. Regardless, we certainly have none of the required > infrastructure now, so explictly pass -mbranch-protection=none to > ensure those useless instructions do not get emitted. > > For a toolchain not configured with > --enable-standard-branch-protection, this changes nothing. For the > Yocto toolchain, this reduces the size of both SPL and U-Boot proper > by about 3% for my imx8mp target. > > If you don't have a Yocto toolchain, the effect can easily be > reproduced by applying this patch and changing =none to =standard. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > Not sure who to cc, there's no overall arm64 maintainer listed in > MAINTAINERS, but Tom is listed as generally handling arch/arm/. > > arch/arm/cpu/armv8/config.mk | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass <sjg@chromium.org>
On 8/8/2022 10:12 PM, Rasmus Villemoes wrote: > The Yocto project builds their aarch64 cross-compiler with the > configure knob --enable-standard-branch-protection, which means that > their gcc behaves as if -mbranch-protection=standard is passed; the > default (lacking that configure knob) is -mbranch-protection=none. > > This means that when building U-Boot using the Yocto toolchain, most > functions end up containing paciasp/autiasp/bti instructions. However, > since U-Boot is not an ordinary userspace application, there's no OS > kernel which has set up the required authentication keys, so these > instructions do nothing at all (even on arm64 hardware that does have > the pointer authentication capability). They do however make the image > larger. > > It is theoretically possible for U-Boot to make use of the pointer > authentication protection - cf. the linux kernel's > CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's > hard to see just what threat model it would protect against in a > bootloader context. Regardless, we certainly have none of the required > infrastructure now, so explictly pass -mbranch-protection=none to > ensure those useless instructions do not get emitted. > > For a toolchain not configured with > --enable-standard-branch-protection, this changes nothing. For the > Yocto toolchain, this reduces the size of both SPL and U-Boot proper > by about 3% for my imx8mp target. > > If you don't have a Yocto toolchain, the effect can easily be > reproduced by applying this patch and changing =none to =standard. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> If U-Boot runs on top of hypervisor, would it still be needed? Regards, Peng. > --- > Not sure who to cc, there's no overall arm64 maintainer listed in > MAINTAINERS, but Tom is listed as generally handling arch/arm/. > > arch/arm/cpu/armv8/config.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk > index 6f9093109f..ca06ed3d4f 100644 > --- a/arch/arm/cpu/armv8/config.mk > +++ b/arch/arm/cpu/armv8/config.mk > @@ -3,6 +3,7 @@ > # (C) Copyright 2002 > # Gary Jennejohn, DENX Software Engineering, <garyj@denx.de> > PLATFORM_RELFLAGS += -fno-common -ffixed-x18 > +PLATFORM_RELFLAGS += $(call cc-option,-mbranch-protection=none) > > PF_NO_UNALIGNED := $(call cc-option, -mstrict-align) > PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
On 10/08/2022 04.38, Peng Fan wrote: > > > On 8/8/2022 10:12 PM, Rasmus Villemoes wrote: >> The Yocto project builds their aarch64 cross-compiler with the >> configure knob --enable-standard-branch-protection, which means that >> their gcc behaves as if -mbranch-protection=standard is passed; the >> default (lacking that configure knob) is -mbranch-protection=none. >> >> This means that when building U-Boot using the Yocto toolchain, most >> functions end up containing paciasp/autiasp/bti instructions. However, >> since U-Boot is not an ordinary userspace application, there's no OS >> kernel which has set up the required authentication keys, so these >> instructions do nothing at all (even on arm64 hardware that does have >> the pointer authentication capability). They do however make the image >> larger. >> >> It is theoretically possible for U-Boot to make use of the pointer >> authentication protection - cf. the linux kernel's >> CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's >> hard to see just what threat model it would protect against in a >> bootloader context. Regardless, we certainly have none of the required >> infrastructure now, so explictly pass -mbranch-protection=none to >> ensure those useless instructions do not get emitted. >> >> For a toolchain not configured with >> --enable-standard-branch-protection, this changes nothing. For the >> Yocto toolchain, this reduces the size of both SPL and U-Boot proper >> by about 3% for my imx8mp target. >> >> If you don't have a Yocto toolchain, the effect can easily be >> reproduced by applying this patch and changing =none to =standard. >> >> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > > If U-Boot runs on top of hypervisor, would it still be needed? Needed? Certainly not _needed_, as binaries built with some distro compiler work just fine (e.g. Ubuntu's cross compiler doesn't have that flag set, which is how I found out about this - I wondered why the binaries I built myself were so much smaller than those built with bitbake). Actually it can never possibly be _needed_, as it's merely an optional hardening feature that doesn't affect the semantics of the code, but unless somebody (usually an OS kernel) has poked the right knobs to actually set up the keys etc. etc., those instructions are just nops. Which one can usually ignore for userspace binaries, but for U-Boot binaries, size matters. Yes, a hypervisor, or U-Boot itself, could be that "somebody" - see the reference to how the linux kernel can enable this for itself. And I very very much doubt the utility of this in a bootloader context. So until somebody points out some setup where U-Boot is run in an environment with those keys actually set up, or provides the necessary infrastructure for U-Boot itself to do it, this patch just makes bitbake-produced binaries 3% smaller. Rasmus
On Mon, Aug 08, 2022 at 04:12:30PM +0200, Rasmus Villemoes wrote: > The Yocto project builds their aarch64 cross-compiler with the > configure knob --enable-standard-branch-protection, which means that > their gcc behaves as if -mbranch-protection=standard is passed; the > default (lacking that configure knob) is -mbranch-protection=none. > > This means that when building U-Boot using the Yocto toolchain, most > functions end up containing paciasp/autiasp/bti instructions. However, > since U-Boot is not an ordinary userspace application, there's no OS > kernel which has set up the required authentication keys, so these > instructions do nothing at all (even on arm64 hardware that does have > the pointer authentication capability). They do however make the image > larger. > > It is theoretically possible for U-Boot to make use of the pointer > authentication protection - cf. the linux kernel's > CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's > hard to see just what threat model it would protect against in a > bootloader context. Regardless, we certainly have none of the required > infrastructure now, so explictly pass -mbranch-protection=none to > ensure those useless instructions do not get emitted. > > For a toolchain not configured with > --enable-standard-branch-protection, this changes nothing. For the > Yocto toolchain, this reduces the size of both SPL and U-Boot proper > by about 3% for my imx8mp target. > > If you don't have a Yocto toolchain, the effect can easily be > reproduced by applying this patch and changing =none to =standard. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk index 6f9093109f..ca06ed3d4f 100644 --- a/arch/arm/cpu/armv8/config.mk +++ b/arch/arm/cpu/armv8/config.mk @@ -3,6 +3,7 @@ # (C) Copyright 2002 # Gary Jennejohn, DENX Software Engineering, <garyj@denx.de> PLATFORM_RELFLAGS += -fno-common -ffixed-x18 +PLATFORM_RELFLAGS += $(call cc-option,-mbranch-protection=none) PF_NO_UNALIGNED := $(call cc-option, -mstrict-align) PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
The Yocto project builds their aarch64 cross-compiler with the configure knob --enable-standard-branch-protection, which means that their gcc behaves as if -mbranch-protection=standard is passed; the default (lacking that configure knob) is -mbranch-protection=none. This means that when building U-Boot using the Yocto toolchain, most functions end up containing paciasp/autiasp/bti instructions. However, since U-Boot is not an ordinary userspace application, there's no OS kernel which has set up the required authentication keys, so these instructions do nothing at all (even on arm64 hardware that does have the pointer authentication capability). They do however make the image larger. It is theoretically possible for U-Boot to make use of the pointer authentication protection - cf. the linux kernel's CONFIG_ARM64_PTR_AUTH_KERNEL - but it is far from trivial, and it's hard to see just what threat model it would protect against in a bootloader context. Regardless, we certainly have none of the required infrastructure now, so explictly pass -mbranch-protection=none to ensure those useless instructions do not get emitted. For a toolchain not configured with --enable-standard-branch-protection, this changes nothing. For the Yocto toolchain, this reduces the size of both SPL and U-Boot proper by about 3% for my imx8mp target. If you don't have a Yocto toolchain, the effect can easily be reproduced by applying this patch and changing =none to =standard. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> --- Not sure who to cc, there's no overall arm64 maintainer listed in MAINTAINERS, but Tom is listed as generally handling arch/arm/. arch/arm/cpu/armv8/config.mk | 1 + 1 file changed, 1 insertion(+)