[PATCH] arm64: explicitly disable pointer authentication instructions

[Rasmus Villemoes]

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 at 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