Armv9 security features (PAC/BTI) support

[Over17]

Hi!

We're looking into enabling Armv9 security features (PAC-PAuth/BTI) all over the engine. I understand the feature is super safe, but having some data would immensely help us decide whether to opt-in or opt-out from the very start. I guess only a serious CPU-level bug could cause any issues.

Once when looking at assembly I noticed that libc++ already has it enabled. For how long is the support in place? Was it already adopted by the Android platform/OS? Were there any issues?

Thanks!

[enh-google]

my goodness, have you just wandered into the middle of a very long story... :-)

TL;DR is something like this:

• by default Android S devices on armv9 chips already shipped with PAC and BTI on for kernel, system, and apps.
• the NDK also defaults to "on" for its prebuilts but off for code built by the NDK (see DanAlbert's correction below).
• good news: we've seen zero compiler issues.
• bad news: Arm got some hand-written assembler in OpenSSL wrong, so there's a range of OpenSSL versions that's broken (for one particular algorithm). fix is openssl/openssl@5795acf, but if you don't care about OpenSSL or are up to date (or use BoringSSL, which never had this issue), you're fine.
• bad news: various "app drm" vendors do things that upset BTI, and BTI is a property of the callee. we're working with them to stop doing those things.

in AOSP/T you can see that the current state is:

• PAC enabled (because we think the PAC issues are under control) but
• BTI disabled (because the situation there is less clear, especially in China where app drm is very common).

there isn't (currently) any kind of partial solution for BTI either where we can say "on for the system, off for apps". we're working with Arm on trying to get to something finer-grained for BTI for U, possibly so we can make it always enabled for the system, but conditionally enabled for apps based on their target API level. (the tricky part there being, as you noted, that folks need to make sure they've tested on an armv9 device, not just "api $LEVEL works in the emulator ... ship it!".)

so, yeah, TL;DR of that TL;DR --- "the only issues we know of are with incorrect hand-written assembler and app drm". we've not yet seen any problems from the toolchain, which i think was your specific question? (if you're LTO-ing BTI and non-BTI code, you'll need the very latest toolchain binaries to allow that, but that should be on its way to an NDK near you soon, and you're sophisticated enough that you'll know whether or not that matters to you.)

we'd be very interested to hear what you decide, because you "big game engine teams" have actually been our canonical example of people we didn't think would be interested in PAC/BTI. iirc when we made it opt-out for the NDK we reasoned that "the big game engine teams won't care because they have their own build systems anyway and carefully monitor all their flags and the resulting binaries, and will just turn this off".

[DanAlbert]

It's very exciting to hear that you're looking into this :)

the NDK also defaults to "on", so if you build new code with a new NDK.

It's off by default for user code. libc++ (and hopefully all the other prebuilts, if not, that's a bug) builds with it on because we only have the one libc++ per ABI, so disabling it there would prevent anyone from using it.

ndk-build (as of r24) has a LOCAL_BRANCH_PROTECTION option that sets the -mbranch-protection flag for aarch64, so LOCAL_BRANCH_PROTECTION := standard will enable it for that ABI (and ignore it for others). For other build systems, you need to set -mbranch-protection for aarch64 only. Not currently documented.

[enh-google]

(oops. i've corrected my "the NDK defaults" line and referred readers down the page to your section for the full details...)

[Over17]

Thanks folks! I've landed PAC/BTI support into Unity 2022.2, opt-in, no separate switches to configure PAC or BTI separately. Looking forward to hearing some feedback from our DRM partner later. Future plans TBD, we'll likely do opt-out next year but leave the switch in case it brings issues to anyone.

Your feedback was super helpful, as always!

[DanAlbert]

That's great news! As I'm sure you've guessed we're very curious to hear how that goes :)