RFR: 8276905: Function frag_col has a deployment target which is incompatible with this OS
When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set any deployment target when when we use xcrun to create .air file and this issue looks similar to https://developer.apple.com/forums/thread/105719. Also https://developer.apple.com/forums/thread/105719 states that even if they set app deployment target they need to explicitly set deployment in "xcrun metal". Made same change to use -mmacosx-version-min=10.12.00 in our make file. Whether we should keep 10.12.00 or 10.13/14 is open to discussion for metal pipeline. SwingSet2, J2DDemo & JCK/jtreg runs in CI are green. Also Vitaly(Submitter) has confirmed that patch resolves the issue. - Commit messages: - 8276905: Function frag_col has a deployment target which is incompatible with this OS Changes: https://git.openjdk.java.net/jdk/pull/6346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6346=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276905 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6346/head:pull/6346 PR: https://git.openjdk.java.net/jdk/pull/6346
Re: CFV: New Build Group Member: Aleksey Shipilev
Vote: yes Tim On 11/10/21 06:06, Magnus Ihse Bursie wrote: I hereby nominate Aleksey Shipilev (shade) to Membership in the Build Group.
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 14:34:18 GMT, Magnus Ihse Bursie 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.
>
> make/autoconf/flags-cflags.m4 line 899:
>
>> 897: elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
>> xclang; then
>> 898: # Check that the compiler actually supports branch protection.
>> 899: FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT:
>> [${BRANCH_PROTECTION_FLAG}],
>
> This branch misses a AC_MSG_RESULT, which prints the newline. The resulting
> output will look messy.
Looking at this block of code again, I've got far too many outputted lines
compared to other features. Removing some means I can simplify the code too, so
I'll do that.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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. I am also reviewing this. - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: CFV: New Build Group Member: Aleksey Shipilev
Vote: yes Magnus Ihse Bursie schrieb am Mi., 10. Nov. 2021, 15:07: > I hereby nominate Aleksey Shipilev (shade) to Membership in the Build > Group. > > Aleksey is a long standing member of the OpenJDK Members Group and the > Hotspot > Group. He is a prolific contributor, and has committed more than 600 > changes to > the JDK over the years. Lately, Aleksey has made a number of improvement > to the > build system, which is indicated by the more than 140 commits made to > files in > the "make" directory since 2018. > > Votes are due by 24 November 2021, 16:00 CET. > > Only current Members of the Build Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [3]. > > /Magnus > > [1] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Aleksey+Shipilev%22=commits > [2]http://openjdk.java.net/census#build > [3]http://openjdk.java.net/groups/#member-vote > >
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 13:34:38 GMT, Andrew Haley 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. > > src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp line 25: > >> 23: */ >> 24: >> 25: #ifndef OS_CPU_BSD_AARCH64_PAUTH_BSD_AARCH64_INLINE_HPP > > Are these two files different enough to separate them for BSD and Linux? My motivation was to avoid having any ifdefs - but we need one anyway for the apple ifdef. If I merged the two we would end up with just the contents of the BSD version of the file. There is also the windows version of the file, which for now has empty functions. If PAC in windows is added, that'll either use the same code or maybe Windows will provide an API (like the Apple one). Merging everything would mean windows gains the UseROPProtection check. - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8276864: Update boot JDKs to 17.0.1 in GHA
On Tue, 9 Nov 2021 14:45:56 GMT, Aleksey Shipilev wrote: > Current GHA runs at 17 GA, which misses fixes from 17.0.1. > > Additional testing: > - [x] GHA builds are fine > - [x] GHA tests are fine Ok, good, thanks. GHA are clean. I am integrating. - PR: https://git.openjdk.java.net/jdk/pull/6314
Integrated: 8276864: Update boot JDKs to 17.0.1 in GHA
On Tue, 9 Nov 2021 14:45:56 GMT, Aleksey Shipilev wrote: > Current GHA runs at 17 GA, which misses fixes from 17.0.1. > > Additional testing: > - [x] GHA builds are fine > - [x] GHA tests are fine This pull request has now been integrated. Changeset: f561d3c1 Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f561d3c1942ce901fa77c907839032f76feb6998 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod 8276864: Update boot JDKs to 17.0.1 in GHA Reviewed-by: erikj, ihse - PR: https://git.openjdk.java.net/jdk/pull/6314
Re: RFR: 8276743: Make openjdk build Zip Archive generation "reproducible"
On Wed, 10 Nov 2021 14:29:22 GMT, Magnus Ihse Bursie wrote: > I think that the post-processing of the zip file can be dependent on this > variable and that it serves no purpose to introduce a separate variable > ENABLE_REPRODUCIBLE_ZIP that is set to the same value as > ENABLE_REPRODUCIBLE_BUILD. Do you agree? Sure, that works for me. - PR: https://git.openjdk.java.net/jdk/pull/6311
Integrated: 8276672: Cannot build hsdis on WSL
On Fri, 5 Nov 2021 03:03:55 GMT, Yasumasa Suenaga wrote: > JDK-8275128 introduced new Makefile for hsdis to integrate it to normal build > system, however it does not work on WSL 1 Ubuntu 20.04 and MinGW from Ubuntu. > > Hsdis.gmk has two problems: > > 1. MinGW version is fixed to "9.2.0" > 2. Assumes sysroot for MinGW is located at /usr/$MINGW_BASE/sys-root > > I tested this change on WSL only, so it is appreciate to review on Cygwin. This pull request has now been integrated. Changeset: 38ec3a16 Author:Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/38ec3a16d722d740d0b2128c6f6c2d1eab7a7c08 Stats: 34 lines in 1 file changed: 29 ins; 1 del; 4 mod 8276672: Cannot build hsdis on WSL Co-authored-by: Magnus Ihse Bursie Co-authored-by: Yasumasa Suenaga Reviewed-by: ihse, erikj - PR: https://git.openjdk.java.net/jdk/pull/6269
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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.
Changes requested by ihse (Reviewer).
make/autoconf/flags-cflags.m4 line 899:
> 897: elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
> xclang; then
> 898: # Check that the compiler actually supports branch protection.
> 899: FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [${BRANCH_PROTECTION_FLAG}],
This branch misses a AC_MSG_RESULT, which prints the newline. The resulting
output will look messy.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8276743: Make openjdk build Zip Archive generation "reproducible"
On Tue, 9 Nov 2021 17:28:39 GMT, Erik Joelsson wrote: >> This PR adds a new openjdk build tool GenerateZip, which generates a final >> "zip" file from an input folder, and creates it in a deterministic way, >> ensuring ordering and timestamps are set as specified. >> >> Using this tool in ZipArchive.gmk will ensure src.zip is then created >> deterministically. >> >> Signed-off-by: Andrew Leonard > > I agree that ideally reproducibility should be on by default, but if there is > a cost, then you can be sure OpenJDK developers will be looking for a way to > remove it for faster turnaround times. I would propose a specific configure > parameter for this specific case, reproducible zip files, that is default on > for release builds and off for debug builds (debug builds aren't reproducible > by nature) and let the existing meta flag also control the value of this new > flag. @erikj79 The flag --enable-reproducible-builds sets ENABLE_REPRODUCIBLE_BUILD in spec.gmk. This is set by our JIB profiles. I propose that we also turn it on for GHA builds. I think that the post-processing of the zip file can be dependent on this variable and that it serves no purpose to introduce a separate variable ENABLE_REPRODUCIBLE_ZIP that is set to the same value as ENABLE_REPRODUCIBLE_BUILD. Do you agree? - PR: https://git.openjdk.java.net/jdk/pull/6311
Re: RFR: 8276864: Update boot JDKs to 17.0.1 in GHA
On Tue, 9 Nov 2021 14:45:56 GMT, Aleksey Shipilev wrote: > Current GHA runs at 17 GA, which misses fixes from 17.0.1. > > Additional testing: > - [x] GHA builds are fine > - [x] GHA tests are fine Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6314
Re: CFV: New Build Group Member: Aleksey Shipilev
Vote: yes /Erik On 2021-11-10 06:06, Magnus Ihse Bursie wrote: I hereby nominate Aleksey Shipilev (shade) to Membership in the Build Group. Aleksey is a long standing member of the OpenJDK Members Group and the Hotspot Group. He is a prolific contributor, and has committed more than 600 changes to the JDK over the years. Lately, Aleksey has made a number of improvement to the build system, which is indicated by the more than 140 commits made to files in the "make" directory since 2018. Votes are due by 24 November 2021, 16:00 CET. Only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [3]. /Magnus [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Aleksey+Shipilev%22=commits [2]http://openjdk.java.net/census#build [3]http://openjdk.java.net/groups/#member-vote
Re: CFV: New Build Group Member: Aleksey Shipilev
Vote: yes /Magnus On 2021-11-10 15:06, Magnus Ihse Bursie wrote: I hereby nominate Aleksey Shipilev (shade) to Membership in the Build Group. Aleksey is a long standing member of the OpenJDK Members Group and the Hotspot Group. He is a prolific contributor, and has committed more than 600 changes to the JDK over the years. Lately, Aleksey has made a number of improvement to the build system, which is indicated by the more than 140 commits made to files in the "make" directory since 2018. Votes are due by 24 November 2021, 16:00 CET. Only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [3]. /Magnus [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Aleksey+Shipilev%22=commits [2]http://openjdk.java.net/census#build [3]http://openjdk.java.net/groups/#member-vote
CFV: New Build Group Member: Aleksey Shipilev
I hereby nominate Aleksey Shipilev (shade) to Membership in the Build Group. Aleksey is a long standing member of the OpenJDK Members Group and the Hotspot Group. He is a prolific contributor, and has committed more than 600 changes to the JDK over the years. Lately, Aleksey has made a number of improvement to the build system, which is indicated by the more than 140 commits made to files in the "make" directory since 2018. Votes are due by 24 November 2021, 16:00 CET. Only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [3]. /Magnus [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Aleksey+Shipilev%22=commits [2]http://openjdk.java.net/census#build [3]http://openjdk.java.net/groups/#member-vote
Re: RFR: 8276854: Windows GHA builds fail due to broken Cygwin
On Wed, 10 Nov 2021 10:39:04 GMT, Aleksey Shipilev wrote: > It is my mistake. Sorry for rushing and breaking the etiquette. I will ensure > that this does not happen again. That was also my mistake (probably even more than Anirvan's) since I sponsored this too early and I should have taken care for all the points mentioned above. Sorry folks! - PR: https://git.openjdk.java.net/jdk/pull/6319
Re: RFR: 8276854: Windows GHA builds fail due to broken Cygwin
https://openjdk.java.net/census#build On 2021-11-10 08:48, Aleksey Shipilev wrote: On Tue, 9 Nov 2021 20:47:29 GMT, Anirvan Sarkar wrote: Use version `3.2.0` of `cygwin` instead of latest version `3.3.2` on GitHub Actions. `make` SEGVs on the latest version. Version number format obtained from https://cygwin.com/packages/summary/cygwin.html The patch looks okay. But what just happened here process-wise? Please do *not* take the issue out of assignee's hands without asking first, and definitely do *NOT* push the fix until the original assignee at least performs some sort of handover. Especially don't do that in the span of less than 24 hours, where the assignee might just be asleep. I also suspect the build infra changes require more reviews, anyway. Don't rush it, folks! I would like to add to Aleksey's comment that the ideal is that you get a review from someone in the Build Group (https://openjdk.java.net/census#build). You definitely need to wait 24h if you have no Build Group member reviews., unless the PR is extremely urgent. /Magnus - PR: https://git.openjdk.java.net/jdk/pull/6319
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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. src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp line 25: > 23: */ > 24: > 25: #ifndef OS_CPU_BSD_AARCH64_PAUTH_BSD_AARCH64_INLINE_HPP Are these two files different enough to separate them for BSD and Linux? - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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. Build change looks good, but I can't comment on the code changes. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 13:11:21 GMT, Andrew Haley wrote: > Gosh. This is going to take some time to review, and will need at least two > reviewers. Sure. And thanks in advance. - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8276672: Cannot build hsdis on WSL [v3]
On Wed, 10 Nov 2021 01:41:03 GMT, Yasumasa Suenaga wrote: >> JDK-8275128 introduced new Makefile for hsdis to integrate it to normal >> build system, however it does not work on WSL 1 Ubuntu 20.04 and MinGW from >> Ubuntu. >> >> Hsdis.gmk has two problems: >> >> 1. MinGW version is fixed to "9.2.0" >> 2. Assumes sysroot for MinGW is located at /usr/$MINGW_BASE/sys-root >> >> I tested this change on WSL only, so it is appreciate to review on Cygwin. > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > Remove SYSROOT_FLAGS Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6269
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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.
src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5185:
> 5183: // ROP Protection
> 5184:
> 5185: void MacroAssembler::protect_return_address() {
We need proper, full, detailed comments about what these functions do, with
reference to primary AArch64 documentation.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8264130: PAC-RET protection for Linux/AArch64
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward 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. Gosh. This is going to take some time to review, and will need at least two reviewers. - PR: https://git.openjdk.java.net/jdk/pull/6334
RFR: 8264130: PAC-RET protection for Linux/AArch64
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. - Commit messages: - 8264130: PAC-RET protection for Linux/AArch64 - Add PAC assembly instructions - Add AArch64 ROP protection runtime flag - Build with branch protection Changes: https://git.openjdk.java.net/jdk/pull/6334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6334=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264130 Stats: 1273 lines in 25 files changed: 457 ins; 20 del; 796 mod Patch: https://git.openjdk.java.net/jdk/pull/6334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6334/head:pull/6334 PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8276672: Cannot build hsdis on WSL [v3]
On Wed, 10 Nov 2021 01:41:03 GMT, Yasumasa Suenaga wrote: >> JDK-8275128 introduced new Makefile for hsdis to integrate it to normal >> build system, however it does not work on WSL 1 Ubuntu 20.04 and MinGW from >> Ubuntu. >> >> Hsdis.gmk has two problems: >> >> 1. MinGW version is fixed to "9.2.0" >> 2. Assumes sysroot for MinGW is located at /usr/$MINGW_BASE/sys-root >> >> I tested this change on WSL only, so it is appreciate to review on Cygwin. > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > Remove SYSROOT_FLAGS Great! I missed the redundant `SYSROOT_FLAGS`, thanks for taking care of that. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6269
Re: RFR: 8276743: Make openjdk build Zip Archive generation "reproducible"
On Tue, 9 Nov 2021 17:31:16 GMT, Erik Joelsson wrote: >> You are already keeping all the filenames in memory for sorting, so reading >> up the ZipEntry:s isn't that much more data, just some extra metadata for >> each entry. The actual file contents is not part of the ZipEntry object. >> When actually copying the files, you can use the ZipFile class to access >> ZipEntry's in arbitrary order to read their streams as InputStream. > > Actually, you don't even need to save the ZipEntry:s in memory, you can just > extract filenames from them on the first pass, sort them, then lookup the > entries in ZipFile again on the second lap. :) I don't think that's necessary > though. @erikj79 thanks I didn't realize you can do that: "you can use the ZipFile class to access ZipEntry's in arbitrary order" - PR: https://git.openjdk.java.net/jdk/pull/6311
Re: RFR: 8276864: Update boot JDKs to 17.0.1 in GHA
On Tue, 9 Nov 2021 14:45:56 GMT, Aleksey Shipilev wrote: > Current GHA runs at 17 GA, which misses fixes from 17.0.1. > > Additional testing: > - [x] GHA builds are fine > - [x] GHA tests are fine Thanks, Erik. Anyone else wants/needs to review this? - PR: https://git.openjdk.java.net/jdk/pull/6314
Re: RFR: 8276854: Windows GHA builds fail due to broken Cygwin
On Wed, 10 Nov 2021 10:14:36 GMT, Anirvan Sarkar wrote: > It is my mistake. Sorry for rushing and breaking the etiquette. I will ensure > that this does not happen again. Good, thanks. No harm done in this particular case, as the patch is definitely sensible. I'll handle the backports... - PR: https://git.openjdk.java.net/jdk/pull/6319
Re: RFR: 8276854: Windows GHA builds fail due to broken Cygwin
On Tue, 9 Nov 2021 20:47:29 GMT, Anirvan Sarkar wrote: > Use version `3.2.0` of `cygwin` instead of latest version `3.3.2` on GitHub > Actions. > `make` SEGVs on the latest version. > > Version number format obtained from > https://cygwin.com/packages/summary/cygwin.html It is my mistake. Sorry for rushing and breaking the etiquette. I will ensure that this does not happen again. - PR: https://git.openjdk.java.net/jdk/pull/6319
Re: RFR: 8276854: Windows GHA builds fail due to broken Cygwin
On Tue, 9 Nov 2021 20:47:29 GMT, Anirvan Sarkar wrote: > Use version `3.2.0` of `cygwin` instead of latest version `3.3.2` on GitHub > Actions. > `make` SEGVs on the latest version. > > Version number format obtained from > https://cygwin.com/packages/summary/cygwin.html > The patch looks okay. > > But what just happened here process-wise? Please do _not_ take the issue out > of assignee's hands without asking first, and definitely do _NOT_ push the > fix until the original assignee at least performs some sort of handover. > Especially don't do that in the span of less than 24 hours, where the > assignee might just be asleep. Yes, that was odd. Please don't reassign JBS issues unless you either talk with the assignee or it has been clearly abandoned. - PR: https://git.openjdk.java.net/jdk/pull/6319
