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

[Alan Hayward]

> On 29 Mar 2021, at 16:03, Andrew Haley <aph at redhat.com> wrote:
>
> 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.

Agreed with these points. Part of me would like to say that at a minimum
we should compile the JVM with the branch protection GCC/LLVM flags
(with no other changes required). But, the jvm will still be generating lots of
code which is exploitable, which is all the attacker needs. The flow of attack
then would be exploiting a bug in the JVM to gain write access and then
using that to chain together gadgets in the generated code.

In the JEP I mentioned 100,000 gadgets in a simple helloworld run. I need
to do more investigation to figure out what percentage comes from generated
code, but even a small percentage is quite a lot.

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

In the general case, it’s just a matter of adding a small amount of code into
enter() and replacing calls to ret(lr) with a new function that does the right
thing.
The non-simple cases are a bit more subtle. Given that I’m still working through
issues, I’m not certain where the code will end up. I’ve already seen some of the
return address redirection, and I’ve had some situations where I need to sign
using the esp instead of the sp.
I really don’t want to end up in a situation where developers need to take extra
special care because of PAC every time they add new functionality into the
AArch64 backend. I’m hoping the right set of macro assembler functions should
hide everything. But, I’m very conscious of the danger of having code that’s
potentially fragile on hardware that isn’t (yet) widely available.
I’ll be happy to share some code once I’m a little further through the issues.

All the above is just assuming Linux. For MacOS everything is amplified because
of the additional protection. If Arm64e becomes the default on MacOS, then I
wonder if the JVM will be “required” to produce arm64e compliant code.

(Thanks for the reply)

Alan.

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.