RFR: 8266749: AArch64: Backtracing broken on PAC enabled systems [v3]
Alan Hayward
github.com+4146708+a74nh at openjdk.java.net
Tue May 25 15:01:58 UTC 2021
On Mon, 24 May 2021 19:56:10 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:
> Please let me know if I understand things correctly:
>
> Apple's **M1** is **arm64e** architecture, so therefore it is **PAC** architecture, however, currently that's only active in **iOS**.
>
> **macOS** does not currently support **PAC**, but we're adding the support to be ready whenever Apple decides to turn it on?
>
MacOS does support PAC, but it's an experimental feature that needs enabling at machine boot up.
For example, all the standard tools in /bin are built for arm64e, and when they are run, the PAC instructions are treated as NOPs.
Apple could turn on PAC as default at any time, and any app compiled for arm64e will suddenly be PAC protected. I suspect we'll have a little warning first. Given that I was adding the fix for Linux, it made sense to also proactively fix MacOS at the same time.
> On **PAC** systems the following code:
>
> `ptrauth_strip(&strcpy, ptrauth_key_asib) == &strcpy`
>
> would be false, and on **non PAC** OS , like for now **macOS** it will always be true (since ptrauth_strip is a NOP macro), is that correct?
Assuming that &strcpy is a signed pointer, then yes - it will be false on a PAC enabled OS.
If the pointer isn't signed or PAC is disabled, then it will be true.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4029
More information about the hotspot-dev
mailing list