Bug 245697 – [Linux] Support branch target identification on aarch64

• Status: NEW
• Component: JavaScriptCore

[Michael Catanzaro]

It seems JSC crashes immediately if run using a Linux kernel built with CONFIG_ARM64_BTI=y, when using hardware that actually supports BTI (e.g. Apple M2 Macbook Air running Linux). Backtrace from the downstream bug:

   Module libvulkan.so.1 with build-id
67d50cfbcd9385a604b088608e38177128818e19
   Stack trace of thread 2:
   #0  0x0000ffff5711b8b0 llint_program_prologue
(libjavascriptcoregtk-4.0.so.18 + 0x13b8b0)
   #1  0x0000ffff5711844c vmEntryToJavaScript
(libjavascriptcoregtk-4.0.so.18 + 0x13844c)
   #2  0x0000ffff57dcf7d8
_ZN3JSC11Interpreter14executeProgramERKNS_10SourceCodeEPNS_14JSGlobalObje$
   #3  0x0000ffff11600000 n/a (n/a + 0x0)

I found some documentation from ARM here:

https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/BTI--Branch-Target-Identification-

And here:

https://developer.arm.com/documentation/102433/0100/Jump-oriented-programming

[Michael Catanzaro]

Yusuke says the implementation will be Linux-specific, not something shared with Apple. Alas, I had been hoping it would be standard for everyone using aarch64....

[Oliver Hunt]

CC'ing Mark and Yusuke.

I'm curious why we believe BTI work will be linux specific vs. gating on something like ENABLE(BTI) (e.g. this is simply a matter of linux using BTI vs our reliance on PAC?)

[Michael Catanzaro]

Some more info on PAC and BTI: https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication

[Michael Catanzaro]

One of the upstream patches says "creation of a BTI-enabled binary requires _everything_ linked in to be BTI-enabled." If that's still true, then forcing cloop is the only option.

If that has changed, then some lightly-edited hints from Yusuke on Slack:

"""
Probably, all WebKitGTK and JIT code should be marked as Legacy code, which probably relies on linker control on Linux toolchain etc.

quite likely, linker has an option to emit ELF data structure saying this is "Legacy" code so do not apply BTI. https://reviews.llvm.org/D62609

GNU_PROPERTY_AARCH64_FEATURE_1_BTI and GNU_PROPERTY_AARCH64_FEATURE_1_PAC

And the loader will load these binaries with appropriate page table entry bits on OS, and that's it, I guess.

And also need to check mmap option to disable these configuration explicitly for JIT code. Probably Linux should have that kind of thing, and you should ensure that JIT code is mapped with that appropriate bits.
"""

More likely, we'd have to either disable it or really add the BTI instructions everywhere required. I don't know how hard that would be, but I assume it would not be easy.

[Michael Catanzaro]

Mark Lam has confirmed on Slack that this is not something Apple plans to implement, but he's around to offer tips for anyone who wants to try. Mark's suggestions from Slack:

"""
For starters, if you just want to get the asm llint (with no JIT) working, try adding "bti jc \n" to the definition of OFFLINE_ASM_GLOBAL_LABEL in LowLevelInterpreter.cpp.  As the name implies, you’re basically making every global label a viable jump/call target.  That should get you a long way.

Getting the JIT to work will take a lot more work, but is not insurmountable.
"""

[Radar WebKit Bug Importer]

<rdar://problem/100735511>