RFC: JEP drafts PAC for Linux/AArch64 (JDK-8264130) and Arm64 for MacOS/AArch64 (JDK-8264131)

[Andrew Haley]

On 3/29/21 10:01 AM, Alan Hayward wrote:

> I’ve been investigating PAC for the AArch64 ports - figuring out
> what should be supported and trying it out in code. PAC is an
> AArch64 extension that provides instructions for signing and
> authenticating values and addresses; it can be used to bring
> protection against various types of attacks, for a small performance
> cost. If OpenJDK is running on a system with PAC protection enabled
> in the kernel, then it should use the feature.

I question this "should", and would like to see a "because." I
understand why this stuff is attractive, but as I understand it PAC is
mostly a band-aid for unsafe programming languages with nasty features
like stack-allocated buffer overflows. In a sense, what PAC is trying
to do is bring C and C++ closer to languages such as Java by
strengthening pointer checks, which is no bad thing. I am aware, of
course, that mistakes can be made in HotSpot itself, which is written
in C++, so there may be some point to it in the JVM.

I'd like to see how complex the implementation is likely to be,
especially given that we deliberately, as a matter of design, redirect
return address pointers in several places. (That's not a bug, it's a
feature.) PAC support potentially makes the AArch64 port significantly
more complex, and therefore potentially more buggy. I know that Arm
wants this feature to be used where possible, but it has to be
justified by the benefit of users.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671