[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    Re: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64 [v25]
From:       Alan Hayward <duke () openjdk ! java ! net>
Date:       2022-02-25 15:20:04
Message-ID: ArmGs6Cgh0Btoy5bQPD2tbMGsh54co0X66oWBYrHhWg=.1cc128d0-9a74-4de5-a1b1-28aea6c7a2ad () github ! com
[Download RAW message or body]

On Tue, 22 Feb 2022 14:35:19 GMT, Alan Hayward <duke@openjdk.java.net> wrote:

> > PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> > of its uses is to protect against ROP based attacks. This is done by
> > signing the Link Register whenever it is stored on the stack, and
> > authenticating the value when it is loaded back from the stack. If an
> > attacker were to try to change control flow by editing the stack then
> > the authentication check of the Link Register will fail, causing a
> > segfault when the function returns.
> > 
> > On a system with PAC enabled, it is expected that all applications will
> > be compiled with ROP protection. Fedora 33 and upwards already provide
> > this. By compiling for ARMv8.0, GCC and LLVM will only use the set of
> > PAC instructions that exist in the NOP space - on hardware without PAC,
> > these instructions act as NOPs, allowing backward compatibility for
> > negligible performance cost (2 NOPs per non-leaf function).
> > 
> > Hardware is currently limited to the Apple M1 MacBooks. All testing has
> > been done within a Fedora Docker image. A run of SpecJVM showed no
> > difference to that of noise - which was surprising.
> > 
> > The most important part of this patch is simply compiling using branch
> > protection provided by GCC/LLVM. This protects all C++ code from being
> > used in ROP attacks, removing all static ROP gadgets from use.
> > 
> > The remainder of the patch adds ROP protection to runtime generated
> > code, in both stubs and compiled Java code. Attacks here are much harder
> > as ROP gadgets must be found dynamically at runtime. If/when AOT
> > compilation is added to JDK, then all stubs and compiled Java will be
> > susceptible ROP gadgets being found by static analysis and therefore
> > potentially as vulnerable as C++ code.
> > 
> > There are a number of places where the VM changes control flow by
> > rewriting the stack or otherwise. I've done some analysis as to how
> > these could also be used for attacks (which I didn't want to post here).
> > These areas can be protected ensuring the pointers to various stubs and
> > entry points are stored in memory as signed pointers. These changes are
> > simple to make (they can be reduced to a type change in common code and
> > a few addition sign/auth calls in the backend), but there a lot of them
> > and the total code change is fairly large. I'm happy to provide a few
> > work in progress patches.
> > 
> > In order to match the security benefits of the Apple Arm64e ABI across
> > the whole of JDK, then all the changes mentioned above would be
> > required.
> 
> Alan Hayward has updated the pull request with a new target base due to a merge or \
> a rebase. The pull request now contains 34 commits: 
> - Merge master
> - Merge master
> - Merge master
> - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
> - Add comments to enter calls
> - Set PreserveFramePointer if use_rop_protection is set
> - Merge enter_subframe into enter
> - Review fixups
> - Documentation updates
> - Update copyrights to 2022
> - ... and 24 more: https://git.openjdk.java.net/jdk/compare/022d8070...c4e0ee31

Yes, we spotted this today too. https://bugs.openjdk.java.net/browse/JDK-8282392

My initial thought was that I needed to add a pauth header file with stub functions \
to linux_zero/. Which does feel a little awkward.

AARCH64_PORT_ONLY does sound like a better option.

Thankfully there is no need for full pac support in zero too.... :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6334


[prev in list] [next in list] [prev in thread] [next in thread]