On Thu, 11 Nov 2021 14:32:18 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in src/utils. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they ar
On Fri, 12 Nov 2021 03:56:57 GMT, Phil Race wrote:
>> Jayathirth D V has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use Macro for version
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 850:
>
>> 848: COMMAND := $(METAL
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> 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
>> iss
On Thu, 11 Nov 2021 15:37:09 GMT, Emmanuel Bourg wrote:
>> The copyright headers are generated at build time, and the year inserted in
>> the template depends on the current date. This means the headers are not
>> reproducible if the project is built a year later. The year in the headers
>> co
On Thu, 11 Nov 2021 20:18:40 GMT, Magnus Ihse Bursie wrote:
> In the future, please refrain from force pushing to a PR. It makes history
> hard to follow for reviewers, and is generally strongly discouraged. OpenJDK
> uses the Skara tools which will automatically squash and rebase the commits
On Thu, 11 Nov 2021 15:37:09 GMT, Emmanuel Bourg wrote:
>> The copyright headers are generated at build time, and the year inserted in
>> the template depends on the current date. This means the headers are not
>> reproducible if the project is built a year later. The year in the headers
>> co
On Thu, 11 Nov 2021 19:48:04 GMT, Andrew Leonard 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 Zi
> 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
> determinist
On Thu, 11 Nov 2021 18:07:37 GMT, Andrew Haley wrote:
> > > Am I right is saying that for Macos, all generated code is remapped RO
> > > before execution?
> >
> >
> > Ah, no, it seems the code cache is not RWX all the time as far as Java
> > threads are concerned. The Macos/AArch64 code is st
On Thu, 11 Nov 2021 16:31:41 GMT, Andrew Dinn wrote:
> > Am I right is saying that for Macos, all generated code is remapped RO
> > before execution?
>
> Ah, no, it seems the code cache is not RWX all the time as far as Java
> threads are concerned. The Macos/AArch64 code is strategically call
On Thu, 11 Nov 2021 14:59:32 GMT, Andrew Dinn wrote:
>> I did mean the description, not the flag name.
>
> Yes, understood. I too was talking about the description even though I
> introduced my comment by talking about what the flag does.
`"Protect branches against ROP attacks".`
-
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line
536:
> 534: if (!preserve_g
On Thu, 11 Nov 2021 15:30:29 GMT, Alan Hayward wrote:
> Am I right is saying that for Macos, all generated code is remapped RO before
> execution?
Ah, no, it seems the code cache is not RWX all the time as far as Java threads
are concerned. The Macos/AArch64 code is strategically calling
pth
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> 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
>> iss
On Wed, 10 Nov 2021 14:39:09 GMT, Erik Joelsson wrote:
>> @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
> The copyright headers are generated at build time, and the year inserted in
> the template depends on the current date. This means the headers are not
> reproducible if the project is built a year later. The year in the headers
> could be derived from the SOURCE_DATE_EPOCH environment variable
On Thu, 11 Nov 2021 14:52:54 GMT, Andrew Dinn wrote:
> The runtime generated runtime stubs and Java method code into which this
> patch may insert the required PAC instructions are written into a code cache
> in a section which is mapped RW(X) all the time. It would be hard to map even
> a sub
On Thu, 11 Nov 2021 13:53:05 GMT, Magnus Ihse Bursie wrote:
> Also, if you did not create this patch yourself, please make sure to use
> `/contributor` to give proper credits. Or maybe you mean that Vitaly
> submitted the bug report, not the patch?
By Submitter i meant submitter of bug in JBS.
> 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/
On Thu, 11 Nov 2021 13:52:13 GMT, Magnus Ihse Bursie wrote:
> We should not hard-code version numbers like that.
>
> Fortunately for you, there already exists a variable $(MACOSX_VERSION_MIN)
> that you can use.
Thanks for the review i have updated code to use the Macro.
-
PR: ht
> 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
> determinist
On Wed, 10 Nov 2021 11:22:39 GMT, Andrew Leonard wrote:
>> 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
>> necessa
On Tue, 9 Nov 2021 14:00:18 GMT, Erik Joelsson wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276743: Make openjdk build Zip Archive generation "reproducible"
>>
>> Signed-off-by: Andrew Leonard
>
> make/
> 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
> determinist
On Sat, 28 Nov 2020 23:14:35 GMT, Emmanuel Bourg wrote:
> The copyright headers are generated at build time, and the year inserted in
> the template depends on the current date. This means the headers are not
> reproducible if the project is built a year later. The year in the headers
> could
> The copyright headers are generated at build time, and the year inserted in
> the template depends on the current date. This means the headers are not
> reproducible if the project is built a year later. The year in the headers
> could be derived from the SOURCE_DATE_EPOCH environment variable
On Thu, 11 Nov 2021 15:12:21 GMT, Emmanuel Bourg wrote:
>> The copyright headers are generated at build time, and the year inserted in
>> the template depends on the current date. This means the headers are not
>> reproducible if the project is built a year later. The year in the headers
>> co
On Thu, 11 Nov 2021 13:45:21 GMT, Magnus Ihse Bursie wrote:
>> Yes that's fine. I guess this involves setting the `COPYRIGHT_YEAR` variable
>> in `make/autoconf/jdk-options.m4` to a value derived from
>> `SOURCE_DATE_EPOCH` (with `SOURCE_DATE_EPOCH` having the priority over
>> `--with-copyrigh
On Thu, 11 Nov 2021 14:20:33 GMT, Florian Weimer wrote:
> Is the code still mapped read-write all the time?
That depends on what code you mean. The JVM code compiled from C++ sources is
mapped RO(X) in the text section like any compiled C/C++ code. Protection of
that code is covered by the cha
On Thu, 11 Nov 2021 14:30:05 GMT, Martin Doerr wrote:
>> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>>
>>> 81: LIRGenerator* gen = access.gen();
>>> 82:
>>> 83: if (ShenandoahCASBarrier) {
>>
>> I am not sure, but I almost think we should not even end
On Thu, 11 Nov 2021 14:53:54 GMT, Florian Weimer wrote:
>> I don't agree that this is incorrect, at least not for the stated reason.
>> The flag switches on a protection mechanism that guards against ROP attacks.
>> To my reading that does not imply it guards against all such attacks, merely
>
On Thu, 11 Nov 2021 14:43:59 GMT, Andrew Dinn wrote:
>> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 115:
>>
>>> 113: range(-1, 4096)
>>> \
>>> 114: product(bool, UseROPProtection, false,
>>> \
>>> 115
On Thu, 11 Nov 2021 14:20:20 GMT, Florian Weimer wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify branch protection configure check
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 115:
>
>> 113:
I ran bin/blessed-modifier-order.sh on source code in src/utils. This scripts
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
have manually checked the changes made by the script to make sure they are
sound.
There are no clear ownership of this code, but I believe
On Thu, 11 Nov 2021 11:32:49 GMT, Roman Kennke wrote:
>> Port the Shenandoah garbage collector
>> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
>> ppc64le.
>
> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>
>> 81: LIRGenerator*
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Nice work! Looks correct.
For others: Note that this change already contains feedback from my offline
revie
On Thu, 11 Nov 2021 08:48:07 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
On Thu, 11 Nov 2021 05:52:18 GMT, Jayathirth D V wrote:
> 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 l
On Sun, 24 Oct 2021 12:11:57 GMT, Emmanuel Bourg wrote:
>> The copyright headers are generated at build time, and the year inserted in
>> the template depends on the current date. This means the headers are not
>> reproducible if the project is built a year later. The year in the headers
>> co
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Build changes look good. Actual code changes needs to be reviewed by someone
more knowledgable about this a
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Hi Niklas,
thanks for this awesome work!
I can't really comment on the actual PPC code, so this needs to be
On Thu, 11 Nov 2021 08:48:07 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
On Thu, 11 Nov 2021 11:52:46 GMT, Andrew Haley wrote:
>> I'm thinking for references to the Arm Arm to use header titles instead of
>> section numbers, as the titles should be more stable.
>>
>> Also probably need some description around the code in the pauth_aarch64.hpp
>> too. But I want to
On Thu, 11 Nov 2021 11:44:09 GMT, Alan Hayward wrote:
>> Correction:
>> Using the most up to date ARM ARM G [ARM DDI 0487G.a (ID011921)]
>>
>> - The PAC functionality is described in ARM-ARM Section D5.1.5
>> - Overview of the PAC instructions is provided in section C3.1.10
>> - Detailed PAC in
On Thu, 11 Nov 2021 11:34:09 GMT, Andrew Dinn wrote:
>> As far as the AArch64 docs are concerned the relevant details are provided
>> in ARM-ARM D
>>
>> - The PAC functionality is described in ARM-ARM Section D5.1.5
>> - Overview of the PAC instructions is provided in section C3.1.9
>> - Detail
On Thu, 11 Nov 2021 11:19:03 GMT, Andrew Dinn wrote:
>> 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,
On Wed, 10 Nov 2021 13:22:37 GMT, Andrew Haley wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify branch protection configure check
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5185:
>
>> 5183
Port the Shenandoah garbage collector
(JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
ppc64le.
-
Commit messages:
- Port shenandoahgc to linux on ppc64le
Changes: https://git.openjdk.java.net/jdk/pull/6325/files
Webrev: https://webrevs.openjdk.java.net
> 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
50 matches
Mail list logo
