From xuelei at openjdk.java.net Sat Jan 2 18:52:08 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 2 Jan 2021 18:52:08 GMT Subject: RFR: 8258852: Arrays.asList() for single item could be replaced with List.of() [v2] In-Reply-To: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> Message-ID: > If there is only one item, the call to Arrays.asList() could be replaced with List.of() for less memory occupation. This update also includes some other code cleanup, like redundant variables in the related files. > > Code cleanup only, no new regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258852 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Replace Collections.singletonList() with List.of() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1872/files - new: https://git.openjdk.java.net/jdk/pull/1872/files/6fefd872..343cc014 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1872&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1872&range=00-01 Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1872.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1872/head:pull/1872 PR: https://git.openjdk.java.net/jdk/pull/1872 From xuelei at openjdk.java.net Sat Jan 2 18:52:08 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 2 Jan 2021 18:52:08 GMT Subject: RFR: 8258852: Arrays.asList() for single item could be replaced with List.of() In-Reply-To: <5QV6qJNyyXaKCU4Vsd3AGriw-0YCj1rdPkcDps7znHY=.0ed64da5-6dc2-4eea-a0b9-987fe5afd0ca@github.com> References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> <5QV6qJNyyXaKCU4Vsd3AGriw-0YCj1rdPkcDps7znHY=.0ed64da5-6dc2-4eea-a0b9-987fe5afd0ca@github.com> Message-ID: On Mon, 28 Dec 2020 21:25:57 GMT, ?????? ??????? wrote: >>> What about using List.of() instead? >> >> For now, the Collections.singletonList() is more compact, which uses one class variable. While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables. > >> > What about using List.of() instead? >> >> For now, the Collections.singletonList() is more compact, which uses one class variable. While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables. > > There's one more issue about it: `List.of()` throws NPE when argument is `null` while `Collections.singletonList()` returns a list with `null` inside. > As @stsypanov points out the null-hostile behavior of the collection returned from `List.of()` can pose a compatibility issue: you'd have to guard against null inputs, and if the lists leak through public API then observable behavior might change in ways that are prohibitive. For the code in question it seem the lists are only created and passed around temporarily, mainly iterating over them. And it appears surrounding could would already throw NPEs if the values wrapped were ever null. So using `List.of` should be fine here. > > As for the impl class for a single element `List.of()` having two fields then that should be footprint neutral since the second field will fit into an alignment gap. There should be no footprint advantage of using `Collections.singletonList`, which was verified by JOL[0] and by checking allocation pressure in microbenchmarks. IIRC this was the case on both on 64-bit and 32-bit VMs. > > I favor `List.of` over `Collections` variants for making code more readable first. They _also_ make it easier to refactor (adding/removing items) without risking worse performance, which can more easily happen when mixing `Collections.unmodifiable`, `.empty` and `singleton` (see: bi- and megamorphic call sites). > > The code changes in this PR probably might make some difference from removing the need for a varargs array. But if the goal is to reduce allocation pressure of the methods involved there seem to be bigger fish to fry - such as the use of `LinkedList` in `KeyShareExtension`, and the nested for loops in `SSLConfiguration.getEnabledExtensions`. Are there any targeted microbenchmarks for these operations or do these operations have some weight in any of the existing micros? > > [0] https://github.com/openjdk/jol I was convinced, and updated the change to use List.of(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1872 From shade at openjdk.java.net Mon Jan 4 09:55:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 09:55:56 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart wrote: > See: https://bugs.openjdk.java.net/browse/JDK-8259021 > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html Looks good, but can we not do the behavioral change in `ensureClassInitialized`? There are methods like this in JDK, which could probably be changed wholesale? src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 419: > 417: } catch (IllegalAccessException e) { > 418: throw new InternalError(e); > 419: } This is a potential behavioral change that has little to do with the issue at hand, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From jlaskey at openjdk.java.net Mon Jan 4 13:56:58 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 4 Jan 2021 13:56:58 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: Message-ID: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> On Wed, 18 Nov 2020 13:45:12 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Stayin' alive ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From plevart at openjdk.java.net Mon Jan 4 14:27:09 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Jan 2021 14:27:09 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2] In-Reply-To: References: Message-ID: > See: https://bugs.openjdk.java.net/browse/JDK-8259021 > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html Peter Levart has updated the pull request incrementally with one additional commit since the last revision: revert the unrelated change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1914/files - new: https://git.openjdk.java.net/jdk/pull/1914/files/d3b4c98f..dd1447a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1914&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1914&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1914/head:pull/1914 PR: https://git.openjdk.java.net/jdk/pull/1914 From redestad at openjdk.java.net Mon Jan 4 14:52:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 14:52:58 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2] In-Reply-To: References: Message-ID: <6GjMahjRqJn3D0nUUnhfxSN3uGggEv5OS_gb7ywaXEo=.38bb3b20-a182-4437-a68d-2d7c04a5f63d@github.com> On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From rriggs at openjdk.java.net Mon Jan 4 15:13:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 4 Jan 2021 15:13:55 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change The bug title and the PR title need to be the same. Editing either one is fine. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1914 From erikj at openjdk.java.net Mon Jan 4 15:32:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From rrich at openjdk.java.net Mon Jan 4 15:59:58 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Jan 2021 15:59:58 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2] In-Reply-To: References: Message-ID: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com> On Mon, 4 Jan 2021 15:11:27 GMT, Roger Riggs wrote: >> Peter Levart has updated the pull request incrementally with one additional commit since the last revision: >> >> revert the unrelated change > > The bug title and the PR title need to be the same. > Editing either one is fine. But wouldn't it be legal for a compiler (java to bytecode or bytecode to machinecode) to replace references of my_local_copy with references to static_field? Foo my_local_copy = static_field; if (my_copy == null) { initialize(); my_local_copy = static_field; } return my_local_copy; Only if static_field was volatile this would be illegal, wouldn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From plevart at openjdk.java.net Mon Jan 4 16:32:00 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Jan 2021 16:32:00 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com> References: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com> Message-ID: On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber wrote: >> The bug title and the PR title need to be the same. >> Editing either one is fine. > > But wouldn't it be legal for a compiler (java to bytecode or bytecode to > machinecode) to replace references of my_local_copy with references to > static_field? > > Foo my_local_copy = static_field; > if (my_copy == null) { > initialize(); > my_local_copy = static_field; > } > return my_local_copy; > > Only if static_field was volatile this would be illegal, wouldn't it? @reinrich I don't think Java compilers may do that. If this was allowed, such variables would not be called "local". ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From shade at openjdk.java.net Mon Jan 4 17:43:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 17:43:57 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: Message-ID: <8kMKZLqpHzKTAWeXeyvmj-Yu_lMXoCgDeazcXoc5rIU=.c0d87c92-7811-4327-8ff8-c74344b0c8ff@github.com> On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From xuelei at openjdk.java.net Mon Jan 4 18:11:07 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 4 Jan 2021 18:11:07 GMT Subject: RFR: 8259069: Fields could be final Message-ID: There are a few fields in the SunJSSE provider implementation could be final. Code clean up to easy the maintenance, no new test. Bug: https://bugs.openjdk.java.net/browse/JDK-8259069 ------------- Commit messages: - 8259069: Fields could be final Changes: https://git.openjdk.java.net/jdk/pull/1936/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1936&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259069 Stats: 33 lines in 13 files changed: 1 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/1936.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1936/head:pull/1936 PR: https://git.openjdk.java.net/jdk/pull/1936 From mchung at openjdk.java.net Mon Jan 4 17:47:57 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 4 Jan 2021 17:47:57 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From rrich at openjdk.java.net Mon Jan 4 18:20:58 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Jan 2021 18:20:58 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:45:25 GMT, Mandy Chung wrote: >> Peter Levart has updated the pull request incrementally with one additional commit since the last revision: >> >> revert the unrelated change > > Marked as reviewed by mchung (Reviewer). > > > _Mailing list message from [Hans Boehm](mailto:hboehm at google.com) on [core-libs-dev](mailto:core-libs-dev at openjdk.java.net):_ > > On Mon, Jan 4, 2021 at 8:34 AM Peter Levart > wrote: > > > On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber > > wrote: > > > > > The bug title and the PR title need to be the same. > > > > Editing either one is fine. > > > > > > > > > But wouldn't it be legal for a compiler (java to bytecode or bytecode to > > > machinecode) to replace references of my_local_copy with references to > > > static_field? > > > Foo my_local_copy = static_field; > > > if (my_copy == null) { > > > initialize(); > > > my_local_copy = static_field; > > > } > > > return my_local_copy; > > > Only if static_field was volatile this would be illegal, wouldn't it? > > > > > > @reinrich I don't think Java compilers may do that. If this was allowed, > > such variables would not be called "local". > > > > > Indeed. Such transformations are allowed in C and C++ (since data races > result in undefined behavior, and thus the > compiler is allowed to assume there are no concurrent writes), but not in > Java. Thanks for the explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From rrich at openjdk.java.net Mon Jan 4 18:24:57 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Jan 2021 18:24:57 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change Marked as reviewed by rrich (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From jlaskey at openjdk.java.net Mon Jan 4 19:52:18 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 4 Jan 2021 19:52:18 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v9] In-Reply-To: References: Message-ID: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com> > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey 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 branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators Added coverage testing - 8248862: Implement Enhanced Pseudo-Random Number Generators Cleanups from Chris H. - 8248862: Implement Enhanced Pseudo-Random Number Generators Propagate exception - 8248862: Implement Enhanced Pseudo-Random Number Generators Override AbstractSplittableGenerator - 8248862: Implement Enhanced Pseudo-Random Number Generators Fix extends - 8248862: Implement Enhanced Pseudo-Random Number Generators Use Map.of instead of Map.ofEntries - 8248862: Implement Enhanced Pseudo-Random Number Generators Changes to RandomGeneratorFactory requested by @PaulSandoz - Review changes @PaulSandoz and @rogermb - 8248862: Implement Enhanced Pseudo-Random Number Generators Update package-info.java - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=08 Stats: 13525 lines in 26 files changed: 11366 ins; 2040 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From hboehm at google.com Mon Jan 4 17:50:44 2021 From: hboehm at google.com (Hans Boehm) Date: Mon, 4 Jan 2021 09:50:44 -0800 Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: <7MBH2JiOtwASAlXwxLRoJRQfrVdqKI6hGiPCU-DCohw=.993d3b32-d590-4346-b213-2d5a5e01dd66@github.com> Message-ID: On Mon, Jan 4, 2021 at 8:34 AM Peter Levart wrote: > > On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber wrote: > > >> The bug title and the PR title need to be the same. > >> Editing either one is fine. > > > > But wouldn't it be legal for a compiler (java to bytecode or bytecode to > > machinecode) to replace references of my_local_copy with references to > > static_field? > > > > Foo my_local_copy = static_field; > > if (my_copy == null) { > > initialize(); > > my_local_copy = static_field; > > } > > return my_local_copy; > > > > Only if static_field was volatile this would be illegal, wouldn't it? > > @reinrich I don't think Java compilers may do that. If this was allowed, such variables would not be called "local". > Indeed. Such transformations are allowed in C and C++ (since data races result in undefined behavior, and thus the compiler is allowed to assume there are no concurrent writes), but not in Java. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.java.net Mon Jan 4 21:23:56 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 4 Jan 2021 21:23:56 GMT Subject: RFR: 8259069: Fields could be final In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:06:24 GMT, Xue-Lei Andrew Fan wrote: > There are a few fields in the SunJSSE provider implementation could be final. > > Code clean up to easy the maintenance, no new test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259069 Marked as reviewed by wetmore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1936 From prr at openjdk.java.net Mon Jan 4 21:24:14 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 4 Jan 2021 21:24:14 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From valeriep at openjdk.java.net Mon Jan 4 22:38:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 4 Jan 2021 22:38:07 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Thanks for finding this! There have been intermittent CKR_OPERATION_ACTIVE errors which is likely the result of this bug... Existing SunPKCS11 code is based on the PKCS#11 spec, e.g. a call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation, and thus avoid the canceling operation for such scenarios. Ideally, NSS should have properly terminated the operation as the spec described. Knowing the NSS behavior, this defensive-cancellation fix is good. There are additional SunPKCS11 impl classes which follow the same model as P11Cipher class and may have to be updated with this defensive-cancellation fix as well. How about P11AEADCipher.java, P11RSACipher.java, P11Signature.java, P11PSSSignature.java, P11Mac.java? Thanks, Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From xuelei at openjdk.java.net Tue Jan 5 00:14:55 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 00:14:55 GMT Subject: Integrated: 8259069: Fields could be final In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:06:24 GMT, Xue-Lei Andrew Fan wrote: > There are a few fields in the SunJSSE provider implementation could be final. > > Code clean up to easy the maintenance, no new test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259069 This pull request has now been integrated. Changeset: 2499ac3d Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/2499ac3d Stats: 33 lines in 13 files changed: 1 ins; 0 del; 32 mod 8259069: Fields could be final Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/1936 From xuelei at openjdk.java.net Tue Jan 5 07:12:06 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 07:12:06 GMT Subject: RFR: 8259223: Simplify boolean expression in the SunJSSE provider Message-ID: There are some boolean expressions that could be improved for better readability in the SunJSSE provider implementation. For example: - if (cert instanceof X509Certificate == false) { + if (!(cert instanceof X509Certificate)) { - return isDTLS ? true : (id >= TLS10.id); + return isDTLS || (id >= TLS10.id); Code cleanup, no new regression test. Bug: https://bugs.openjdk.java.net/browse/JDK-8259223 ------------- Commit messages: - 8259223: Simplify boolean expression in the SunJSSE provider Changes: https://git.openjdk.java.net/jdk/pull/1942/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1942&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259223 Stats: 35 lines in 11 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1942/head:pull/1942 PR: https://git.openjdk.java.net/jdk/pull/1942 From alanb at openjdk.java.net Tue Jan 5 08:21:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 5 Jan 2021 08:21:59 GMT Subject: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > revert the unrelated change Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From redestad at openjdk.java.net Tue Jan 5 10:18:07 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 5 Jan 2021 10:18:07 GMT Subject: RFR: 8259065: java.security.Provider should cache default constructors Message-ID: By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: Benchmark (digesterName) Mode Cnt Score Error Units GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op Patch: Benchmark (digesterName) Mode Cnt Score Error Units GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. ------------- Commit messages: - NSPE - Add provider-based micro, reduce digesters checked by default - Add GetMessageDigests micro - Missing static - 8259065: java.security.Provider should cache default constructors Changes: https://git.openjdk.java.net/jdk/pull/1933/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259065 Stats: 98 lines in 2 files changed: 94 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1933/head:pull/1933 PR: https://git.openjdk.java.net/jdk/pull/1933 From mullan at openjdk.java.net Tue Jan 5 14:12:57 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 5 Jan 2021 14:12:57 GMT Subject: RFR: 8259223: Simplify boolean expression in the SunJSSE provider In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 07:06:42 GMT, Xue-Lei Andrew Fan wrote: > There are some boolean expressions that could be improved for better readability in the SunJSSE provider implementation. For example: > > - if (cert instanceof X509Certificate == false) { > + if (!(cert instanceof X509Certificate)) { > > - return isDTLS ? true : (id >= TLS10.id); > + return isDTLS || (id >= TLS10.id); > > > Code cleanup, no new regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259223 Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 823: > 821: preferred = true; > 822: } > 823: if (preferred && (!findAll)) { Minor comment - remove the parenthesis around !findAll. src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 617: > 615: // for now until there are signs that this check > 616: // causes problems for real world EC certificates. > 617: if ((this == SERVER) && (!getBit(ku, 4))) { You could remove the inner parenthesis around `this == SERVER` and `!getBit(ku, 4)`, which would make it consistent with the style used on line 584. ------------- PR: https://git.openjdk.java.net/jdk/pull/1942 From xuelei at openjdk.java.net Tue Jan 5 17:02:18 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 17:02:18 GMT Subject: RFR: 8259223: Simplify boolean expression in the SunJSSE provider [v2] In-Reply-To: References: Message-ID: > There are some boolean expressions that could be improved for better readability in the SunJSSE provider implementation. For example: > > - if (cert instanceof X509Certificate == false) { > + if (!(cert instanceof X509Certificate)) { > > - return isDTLS ? true : (id >= TLS10.id); > + return isDTLS || (id >= TLS10.id); > > > Code cleanup, no new regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259223 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary parenthesis ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1942/files - new: https://git.openjdk.java.net/jdk/pull/1942/files/93700102..80ab2fb6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1942&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1942&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1942/head:pull/1942 PR: https://git.openjdk.java.net/jdk/pull/1942 From plevart at openjdk.java.net Tue Jan 5 17:44:57 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 5 Jan 2021 17:44:57 GMT Subject: Integrated: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart wrote: > See: https://bugs.openjdk.java.net/browse/JDK-8259021 > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html This pull request has now been integrated. Changeset: 85bac8c4 Author: Peter Levart URL: https://git.openjdk.java.net/jdk/commit/85bac8c4 Stats: 93 lines in 1 file changed: 48 ins; 0 del; 45 mod 8259021: SharedSecrets should avoid double racy reads from non-volatile fields Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1914 From mullan at openjdk.java.net Tue Jan 5 18:03:55 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 5 Jan 2021 18:03:55 GMT Subject: RFR: 8258852: Arrays.asList() for single item could be replaced with List.of() [v2] In-Reply-To: References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> Message-ID: On Sat, 2 Jan 2021 18:52:08 GMT, Xue-Lei Andrew Fan wrote: >> If there is only one item, the call to Arrays.asList() could be replaced with List.of() for less memory occupation. This update also includes some other code cleanup, like redundant variables in the related files. >> >> Code cleanup only, no new regression test. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8258852 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Replace Collections.singletonList() with List.of() Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 142: > 140: this.identificationProtocol = null; > 141: this.serverNames = Collections.emptyList(); > 142: this.sniMatchers = Collections.emptyList(); Here you use Collections.emptyList() instead of List.of(). Probably ok, but maybe you want to change that to List.of(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1872 From xuelei at openjdk.java.net Tue Jan 5 18:34:59 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 18:34:59 GMT Subject: Integrated: 8258852: Arrays.asList() for single item could be replaced with List.of() In-Reply-To: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> Message-ID: On Wed, 23 Dec 2020 00:56:25 GMT, Xue-Lei Andrew Fan wrote: > If there is only one item, the call to Arrays.asList() could be replaced with List.of() for less memory occupation. This update also includes some other code cleanup, like redundant variables in the related files. > > Code cleanup only, no new regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258852 This pull request has now been integrated. Changeset: 7ddc2b56 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/7ddc2b56 Stats: 17 lines in 3 files changed: 0 ins; 6 del; 11 mod 8258852: Arrays.asList() for single item could be replaced with List.of() Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1872 From xuelei at openjdk.java.net Tue Jan 5 18:34:58 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 18:34:58 GMT Subject: RFR: 8258852: Arrays.asList() for single item could be replaced with List.of() [v2] In-Reply-To: References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com> Message-ID: On Tue, 5 Jan 2021 18:01:12 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace Collections.singletonList() with List.of() > > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 142: > >> 140: this.identificationProtocol = null; >> 141: this.serverNames = Collections.emptyList(); >> 142: this.sniMatchers = Collections.emptyList(); > > Here you use Collections.emptyList() instead of List.of(). Probably ok, but maybe you want to change that to List.of(). There are some other places that use Collections.emptyList(), I will make the update all together in another bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/1872 From xuelei at openjdk.java.net Tue Jan 5 19:35:58 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 5 Jan 2021 19:35:58 GMT Subject: Integrated: 8259223: Simplify boolean expression in the SunJSSE provider In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 07:06:42 GMT, Xue-Lei Andrew Fan wrote: > There are some boolean expressions that could be improved for better readability in the SunJSSE provider implementation. For example: > > - if (cert instanceof X509Certificate == false) { > + if (!(cert instanceof X509Certificate)) { > > - return isDTLS ? true : (id >= TLS10.id); > + return isDTLS || (id >= TLS10.id); > > > Code cleanup, no new regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259223 This pull request has now been integrated. Changeset: 4d3d5991 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/4d3d5991 Stats: 35 lines in 11 files changed: 0 ins; 0 del; 35 mod 8259223: Simplify boolean expression in the SunJSSE provider Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1942 From valeriep at openjdk.java.net Tue Jan 5 19:35:58 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 5 Jan 2021 19:35:58 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 122: > 120: cipher.doFinal(new byte[1], 0, 0); > 121: } else { > 122: cipher.update(new byte[1]); Why only calling update(..) for Cipher encryption would lead to Exception? Seems strange... test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 194: > 192: private static void tryCipherInit() throws Exception { > 193: Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding", provider); > 194: cipher.init(Cipher.ENCRYPT_MODE, key); Add a comment here or to this method about the CKR_OPERATION_ACTIVE error (w/o this fix) as this is actually the key test point. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Tue Jan 5 19:43:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 5 Jan 2021 19:43:55 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50: > 48: } > 49: > 50: private static class SessionLeaker { The term "leak/leaker" is used extensively in the test, however, this is not really a leak conceptually, but rather sessions w/ active states/operations which are unusable and lead to unexpected PKCS#11 errors subsequently. Maybe replace it with other terms like "corrupt/corruptor" or other similar terms would be more suitable? ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From jlaskey at openjdk.java.net Tue Jan 5 19:52:14 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 5 Jan 2021 19:52:14 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v10] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators Added coverage testing - 8248862: Implement Enhanced Pseudo-Random Number Generators Cleanups from Chris H. - 8248862: Implement Enhanced Pseudo-Random Number Generators Propagate exception - 8248862: Implement Enhanced Pseudo-Random Number Generators Override AbstractSplittableGenerator - 8248862: Implement Enhanced Pseudo-Random Number Generators Fix extends - 8248862: Implement Enhanced Pseudo-Random Number Generators Use Map.of instead of Map.ofEntries - ... and 27 more: https://git.openjdk.java.net/jdk/compare/a6c08813...da9fec11 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=09 Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From darcy at openjdk.java.net Tue Jan 5 21:08:07 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Jan 2021 21:08:07 GMT Subject: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil Message-ID: Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. Please also review the corresponding CSRs: JDK-8258521 Remove terminally deprecated constructor in GSSUtil https://bugs.openjdk.java.net/browse/JDK-8258521 JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder https://bugs.openjdk.java.net/browse/JDK-8258522 Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. Thanks, ------------- Commit messages: - 8250564: Remove terminally deprecated constructor in GSSUti Changes: https://git.openjdk.java.net/jdk/pull/1948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250564 Stats: 7 lines in 3 files changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1948/head:pull/1948 PR: https://git.openjdk.java.net/jdk/pull/1948 From bpb at openjdk.java.net Tue Jan 5 21:15:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 5 Jan 2021 21:15:55 GMT Subject: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. > > Thanks, Looks good. CSRs also reviewed. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1948 From smarks at openjdk.java.net Tue Jan 5 22:57:53 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 5 Jan 2021 22:57:53 GMT Subject: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. > > Thanks, Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1948 From redestad at openjdk.java.net Wed Jan 6 01:02:14 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 6 Jan 2021 01:02:14 GMT Subject: RFR: 8259065: java.security.Provider should cache default constructors [v2] In-Reply-To: References: Message-ID: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Cache constructor in the Provider.Service instead of a ClassValue. Fix inefficient synchronization in ProviderConfig. Store EngineDescriptor in Service instead of looking it up every time. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1933/files - new: https://git.openjdk.java.net/jdk/pull/1933/files/ebcc27e8..64201186 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=00-01 Stats: 264 lines in 3 files changed: 110 ins; 93 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/1933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1933/head:pull/1933 PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Wed Jan 6 01:07:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 6 Jan 2021 01:07:53 GMT Subject: RFR: 8259065: java.security.Provider should cache default constructors In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 16:40:50 GMT, Claes Redestad wrote: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. I refactored and optimized the lookup code further, getting rid of a number of bottlenecks: - Cache Constructors in Provider.Service instead of via a ClassValue. - Also cache the impl Class, wrap Class and Constructor in WeakReference if not loaded by the null classloader (many builtins will be) - Cache EngineDescription in Service, avoiding a lookup on the hot path - We were hitting a synchronized method in ProviderConfig.getProvider(). The provider field is volatile already, so I used the double-check idiom here to avoid synchronization on the hot path - ServiceKey.hashCode using Objects.hash was cause for allocation, simplified and optimized it. Benchmark (digesterName) Mode Cnt Score Error Units GetMessageDigest.getInstance MD5 avgt 30 143.803 ? 5.431 ns/op GetMessageDigest.getInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Wed Jan 6 01:27:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 6 Jan 2021 01:27:09 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v3] In-Reply-To: References: Message-ID: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add cloneInstance baseline micro ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1933/files - new: https://git.openjdk.java.net/jdk/pull/1933/files/64201186..9bf450ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=01-02 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1933/head:pull/1933 PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Wed Jan 6 01:27:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 6 Jan 2021 01:27:09 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 01:05:35 GMT, Claes Redestad wrote: >> By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. >> >> On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op >> Patch: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op >> >> See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. > > I refactored and optimized the lookup code further, getting rid of a number of bottlenecks: > > - Cache Constructors in Provider.Service instead of via a ClassValue. > - Also cache the impl Class, wrap Class and Constructor in WeakReference if not loaded by the null classloader (many builtins will be) > - Cache EngineDescription in Service, avoiding a lookup on the hot path > - We were hitting a synchronized method in ProviderConfig.getProvider(). The provider field is volatile already, so I used the double-check idiom here to avoid synchronization on the hot path > - ServiceKey.hashCode using Objects.hash was cause for allocation, simplified and optimized it. > > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance MD5 avgt 30 143.803 ? 5.431 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op Since much of the cost is now the creation of the MessageDigest itself, I added a microbenchmark to stat this overhead: Benchmark (digesterName) Mode Cnt Score Error Units GetMessageDigest.cloneInstance MD5 avgt 30 124.922 ? 5.412 ns/op GetMessageDigest.cloneInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op That means there's no added allocation overhead of calling `MessageDigest.getInstance(digesterName)` compared to cloning an existing instance - which means we get almost all of the benefits without resorting to tricks as caching and cloning an instance at call sites such as the one in `UUID::nameUUIDFromBytes`. The remaining 20ns/op difference should be negligible. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From github.com+54594+schlosna at openjdk.java.net Wed Jan 6 02:33:53 2021 From: github.com+54594+schlosna at openjdk.java.net (David Schlosnagle) Date: Wed, 6 Jan 2021 02:33:53 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 01:20:40 GMT, Claes Redestad wrote: >> I refactored and optimized the lookup code further, getting rid of a number of bottlenecks: >> >> - Cache Constructors in Provider.Service instead of via a ClassValue. >> - Also cache the impl Class, wrap Class and Constructor in WeakReference if not loaded by the null classloader (many builtins will be) >> - Cache EngineDescription in Service, avoiding a lookup on the hot path >> - We were hitting a synchronized method in ProviderConfig.getProvider(). The provider field is volatile already, so I used the double-check idiom here to avoid synchronization on the hot path >> - ServiceKey.hashCode using Objects.hash was cause for allocation, simplified and optimized it. >> >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance MD5 avgt 30 143.803 ? 5.431 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op > > Since much of the cost is now the creation of the MessageDigest itself, I added a microbenchmark to stat this overhead: > > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.cloneInstance MD5 avgt 30 124.922 ? 5.412 ns/op > GetMessageDigest.cloneInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op > > That means there's no added allocation overhead of calling `MessageDigest.getInstance(digesterName)` compared to cloning an existing instance - which means we get almost all of the benefits without resorting to tricks as caching and cloning an instance at call sites such as the one in `UUID::nameUUIDFromBytes`. The remaining 20ns/op difference should be negligible. Nice speedup for all `MessageDigest.getInstance` and `Provider.getService` invocations and improves on removing the scalability bottlenecks of `Provider.getService` beyond [JDK-7092821](https://bugs.openjdk.java.net/browse/JDK-7092821) (and related [JDK-8080273](https://bugs.openjdk.java.net/browse/JDK-8080273) & [JDK-8172827](https://bugs.openjdk.java.net/browse/JDK-8172827)). This will also allow removing some longstanding `MessageDigest#clone` workarounds such as in Guava https://github.com/google/guava/issues/1197 . ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From xuelei at openjdk.java.net Wed Jan 6 05:23:02 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Jan 2021 05:23:02 GMT Subject: RFR: 8259291: Cleanup unnecessary local variables Message-ID: <657BpjWWmyjPMiRMoi5p3q48NoLVHasndd5XaX8MADQ=.dead178d-b9d8-4306-b7dd-11b0923b9c1a@github.com> In the SunJSSE provider implementation, there are a few local variables that is not necessary. For example: byte[] finished = prfKey.getEncoded(); return finished; could be simplified as: return prfKey.getEncoded(); Code clean up, no new regression test. ------------- Commit messages: - 8259291: Cleanup unnecessary local variables Changes: https://git.openjdk.java.net/jdk/pull/1955/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1955&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259291 Stats: 20 lines in 6 files changed: 0 ins; 8 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1955/head:pull/1955 PR: https://git.openjdk.java.net/jdk/pull/1955 From alanb at openjdk.java.net Wed Jan 6 07:58:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Jan 2021 07:58:56 GMT Subject: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil In-Reply-To: References: Message-ID: <1vnKPIkVgBUHLQXt2mq0Ljqvv4W-oqQHsTVS4A2wym4=.9d4b64a5-4975-4a11-af8d-e1a8094b6296@github.com> On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. > > Thanks, Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1948 From jlaskey at openjdk.java.net Wed Jan 6 14:28:35 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 14:28:35 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v11] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into 8248862 - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators Added coverage testing - 8248862: Implement Enhanced Pseudo-Random Number Generators Cleanups from Chris H. - 8248862: Implement Enhanced Pseudo-Random Number Generators Propagate exception - 8248862: Implement Enhanced Pseudo-Random Number Generators Override AbstractSplittableGenerator - 8248862: Implement Enhanced Pseudo-Random Number Generators Fix extends - ... and 28 more: https://git.openjdk.java.net/jdk/compare/7e01bc96...cb78fa11 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=10 Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+2996845+bokken at openjdk.java.net Wed Jan 6 15:01:11 2021 From: github.com+2996845+bokken at openjdk.java.net (Brett Okken) Date: Wed, 6 Jan 2021 15:01:11 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v9] In-Reply-To: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com> References: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com> Message-ID: On Mon, 4 Jan 2021 19:52:18 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey 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 branch 'master' into 8248862 > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Added coverage testing > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Cleanups from Chris H. > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Propagate exception > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Override AbstractSplittableGenerator > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Fix extends > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Use Map.of instead of Map.ofEntries > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Changes to RandomGeneratorFactory requested by @PaulSandoz > - Review changes > > @PaulSandoz and @rogermb > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Update package-info.java > - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844 src/java.base/share/classes/java/util/random/RandomGenerator.java line 439: > 437: * Fills a user-supplied byte array with generated byte values > 438: * (pseudo)randomly chosen uniformly from the range of values between -128 > 439: * (inclusive) and 255 (inclusive). Should this be between -128 (inclusive) and **127** (inclusive) ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Wed Jan 6 15:36:21 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 15:36:21 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v12] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct range used by nextBytes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/cb78fa11..f76fa7a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Wed Jan 6 15:36:29 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 15:36:29 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v9] In-Reply-To: References: <1x-JXb6q5tPjvf2SZItze0r1etXGKnIPZ3wtORNMKro=.485a0405-bf2f-45d4-92a1-732f6f743b80@github.com> Message-ID: On Tue, 5 Jan 2021 02:43:08 GMT, Brett Okken wrote: >> Jim Laskey 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 branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Added coverage testing >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Cleanups from Chris H. >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Propagate exception >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Override AbstractSplittableGenerator >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Fix extends >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Use Map.of instead of Map.ofEntries >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Changes to RandomGeneratorFactory requested by @PaulSandoz >> - Review changes >> >> @PaulSandoz and @rogermb >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Update package-info.java >> - ... and 24 more: https://git.openjdk.java.net/jdk/compare/f80c63b3...e75cc844 > > src/java.base/share/classes/java/util/random/RandomGenerator.java line 439: > >> 437: * Fills a user-supplied byte array with generated byte values >> 438: * (pseudo)randomly chosen uniformly from the range of values between -128 >> 439: * (inclusive) and 255 (inclusive). > > Should this be > between -128 (inclusive) and **127** (inclusive) Thanks. Will update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Wed Jan 6 15:36:30 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 15:36:30 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: References: Message-ID: <5RmKd5_sJoQ14BoS1NPzzhpjIHgIc0V3mjMlp1VG2Ek=.9cb2989d-b0a5-4696-b847-197e1d4afc5b@github.com> On Wed, 6 Jan 2021 15:31:32 GMT, Jim Laskey wrote: >> I kind of like the idea - not sure how expressive a BigInteger string is though. I might be able to express as BigInteger.ONE.shiftLeft(i).subtract(j).shiftLeft(k). Will ponder. > > Done Also added getDefault and getDefaultFactory to RandomGenerato. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Wed Jan 6 15:36:30 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 15:36:30 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 15:41:16 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 46: >> >>> 44: import java.util.stream.Stream; >>> 45: import jdk.internal.util.random.RandomSupport.RandomGeneratorProperty; >>> 46: >> >> Instead of calling a method properties to create a Map, it's usually far easier to use an annotation, >> annotation values supports less runtime type so BigInteger is not supported but using a String instead should be OK. > > I kind of like the idea - not sure how expressive a BigInteger string is though. I might be able to express as BigInteger.ONE.shiftLeft(i).subtract(j).shiftLeft(k). Will ponder. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+2996845+bokken at openjdk.java.net Wed Jan 6 15:40:02 2021 From: github.com+2996845+bokken at openjdk.java.net (Brett Okken) Date: Wed, 6 Jan 2021 15:40:02 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 14:07:04 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Changes to RandomGeneratorFactory requested by @PaulSandoz > > src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 335: > >> 333: ctorBytes = tmpCtorBytes; >> 334: ctorLong = tmpCtorLong; >> 335: ctor = tmpCtor; > > This one is a volatile write, so the idea is that ctorBytes and ctorLong does not need to be volatile too, which i think is not true if there is a code somewhere that uses ctorBytes or ctorLong without reading ctor. > This code is too smart for me, i'm pretty sure it is wrong too on non TSO cpu. The 2 uses call ensureConstructors, which calls this method, which reads ctor. The memory model guarantees this to be safe, even on non tso hardware. https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#pitfall-avoiding ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From mbalao at openjdk.java.net Wed Jan 6 15:40:10 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 6 Jan 2021 15:40:10 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Message-ID: As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. No regressions found in jdk/sun/security/pkcs11 tests category. -- [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 ------------- Commit messages: - 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Changes: https://git.openjdk.java.net/jdk/pull/1961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1961&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259319 Stats: 115 lines in 4 files changed: 105 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1961/head:pull/1961 PR: https://git.openjdk.java.net/jdk/pull/1961 From mullan at openjdk.java.net Wed Jan 6 15:52:02 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 6 Jan 2021 15:52:02 GMT Subject: RFR: 8259291: Cleanup unnecessary local variables In-Reply-To: <657BpjWWmyjPMiRMoi5p3q48NoLVHasndd5XaX8MADQ=.dead178d-b9d8-4306-b7dd-11b0923b9c1a@github.com> References: <657BpjWWmyjPMiRMoi5p3q48NoLVHasndd5XaX8MADQ=.dead178d-b9d8-4306-b7dd-11b0923b9c1a@github.com> Message-ID: On Wed, 6 Jan 2021 05:17:35 GMT, Xue-Lei Andrew Fan wrote: > In the SunJSSE provider implementation, there are a few local variables that is not necessary. For example: > > byte[] finished = prfKey.getEncoded(); > return finished; > > could be simplified as: > > return prfKey.getEncoded(); > > Code clean up, no new regression test. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1955 From rhalade at openjdk.java.net Wed Jan 6 16:00:02 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 6 Jan 2021 16:00:02 GMT Subject: RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 dayseibcccttchjcjfkgtgbcgitkibtitbvvtbfgejetjlcn Message-ID: ?in 90 days ------------- Commit messages: - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Changes: https://git.openjdk.java.net/jdk/pull/1963/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1963&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259312 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1963/head:pull/1963 PR: https://git.openjdk.java.net/jdk/pull/1963 From github.com+2996845+bokken at openjdk.java.net Wed Jan 6 16:11:59 2021 From: github.com+2996845+bokken at openjdk.java.net (Brett Okken) Date: Wed, 6 Jan 2021 16:11:59 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v12] In-Reply-To: References: Message-ID: <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com> On Wed, 6 Jan 2021 15:36:21 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Correct range used by nextBytes src/java.base/share/classes/java/util/random/RandomGenerator.java line 147: > 145: * > 146: * @implNote Since algorithms will improve over time, there is no > 147: * guarantee that this method will return the same algorithm each time. is there a guarantee that within a running jvm each invocation will return the same algorithm? ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From mullan at openjdk.java.net Wed Jan 6 16:25:01 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 6 Jan 2021 16:25:01 GMT Subject: RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:55:28 GMT, Rajan Halade wrote: > ?in 90 days Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1963 From rhalade at openjdk.java.net Wed Jan 6 16:25:03 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 6 Jan 2021 16:25:03 GMT Subject: Integrated: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: References: Message-ID: <-5S0XeceffBNPFSbjFDKHugTGq1spnmVCKZgrC5akWg=.a9f02f18-504f-4334-ba3d-31abf7cbf571@github.com> On Wed, 6 Jan 2021 15:55:28 GMT, Rajan Halade wrote: > ?in 90 days This pull request has now been integrated. Changeset: 3be6e069 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/3be6e069 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1963 From jlaskey at openjdk.java.net Wed Jan 6 16:28:58 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 6 Jan 2021 16:28:58 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v12] In-Reply-To: <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com> References: <6iRrJ5Qqo2vCFuoIwtJo-rw1ktpixHmFtc95cRE88Kc=.58e3cb3f-ea4b-49da-804b-a4a5fe0b1a6a@github.com> Message-ID: On Wed, 6 Jan 2021 16:09:25 GMT, Brett Okken wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct range used by nextBytes > > src/java.base/share/classes/java/util/random/RandomGenerator.java line 147: > >> 145: * >> 146: * @implNote Since algorithms will improve over time, there is no >> 147: * guarantee that this method will return the same algorithm each time. > > is there a guarantee that within a running jvm each invocation will return the same algorithm? In practice terms yes. The point is that the user should not assume they will be getting the same algorithm each time. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From mullan at openjdk.java.net Wed Jan 6 16:59:56 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 6 Jan 2021 16:59:56 GMT Subject: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil In-Reply-To: References: Message-ID: <6EjOn1lnDVOklwXn3x3nqaRT-A6scYg__6tn9FWHZUA=.ed1a3a88-76a6-417d-9ec4-0505afd1be3a@github.com> On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. > > Thanks, The GSSUtil bug needs an appropriate noreg keyword, but otherwise looks fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1948 From xuelei at openjdk.java.net Wed Jan 6 17:01:01 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Jan 2021 17:01:01 GMT Subject: Integrated: 8259291: Cleanup unnecessary local variables In-Reply-To: <657BpjWWmyjPMiRMoi5p3q48NoLVHasndd5XaX8MADQ=.dead178d-b9d8-4306-b7dd-11b0923b9c1a@github.com> References: <657BpjWWmyjPMiRMoi5p3q48NoLVHasndd5XaX8MADQ=.dead178d-b9d8-4306-b7dd-11b0923b9c1a@github.com> Message-ID: On Wed, 6 Jan 2021 05:17:35 GMT, Xue-Lei Andrew Fan wrote: > In the SunJSSE provider implementation, there are a few local variables that is not necessary. For example: > > byte[] finished = prfKey.getEncoded(); > return finished; > > could be simplified as: > > return prfKey.getEncoded(); > > Code clean up, no new regression test. This pull request has now been integrated. Changeset: df721f0c Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/df721f0c Stats: 20 lines in 6 files changed: 0 ins; 8 del; 12 mod 8259291: Cleanup unnecessary local variables Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1955 From darcy at openjdk.java.net Wed Jan 6 18:09:02 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Jan 2021 18:09:02 GMT Subject: Integrated: 8250564: Remove terminally deprecated constructor in GSSUtil In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test B6463990.java, is a coding anti-pattern that generates a lint warning; that warning in enabled in the JDK build. > > Thanks, This pull request has now been integrated. Changeset: 80544e4d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/80544e4d Stats: 7 lines in 3 files changed: 0 ins; 3 del; 4 mod 8250564: Remove terminally deprecated constructor in GSSUtil 8250565: Remove terminally deprecated constructor in java.net.URLDecoder Reviewed-by: bpb, smarks, alanb, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1948 From valeriep at openjdk.java.net Wed Jan 6 20:08:56 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 6 Jan 2021 20:08:56 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:29:58 GMT, David Schlosnagle wrote: >> Since much of the cost is now the creation of the MessageDigest itself, I added a microbenchmark to stat this overhead: >> >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.cloneInstance MD5 avgt 30 124.922 ? 5.412 ns/op >> GetMessageDigest.cloneInstance:?gc.alloc.rate.norm MD5 avgt 30 280.015 ? 0.001 B/op >> >> That means there's no added allocation overhead of calling `MessageDigest.getInstance(digesterName)` compared to cloning an existing instance - which means we get almost all of the benefits without resorting to tricks as caching and cloning an instance at call sites such as the one in `UUID::nameUUIDFromBytes`. The remaining 20ns/op difference should be negligible. > > Nice speedup for all `MessageDigest.getInstance` and `Provider.getService` invocations and improves on removing the scalability bottlenecks of `Provider.getService` beyond [JDK-7092821](https://bugs.openjdk.java.net/browse/JDK-7092821) (and related [JDK-8080273](https://bugs.openjdk.java.net/browse/JDK-8080273) & [JDK-8172827](https://bugs.openjdk.java.net/browse/JDK-8172827)). This will also allow removing some longstanding `MessageDigest#clone` workarounds such as in Guava https://github.com/google/guava/issues/1197 . Thanks for looking into this. I will take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From cverghese at openjdk.java.net Wed Jan 6 23:33:10 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 6 Jan 2021 23:33:10 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Message-ID: This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 ------------- Commit messages: - 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Changes: https://git.openjdk.java.net/jdk/pull/1968/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237578 Stats: 347 lines in 5 files changed: 338 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Wed Jan 6 23:58:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Jan 2021 23:58:57 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 23:28:34 GMT, Clive Verghese wrote: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Thank you for take care of this issue. Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1968 From valeriep at openjdk.java.net Thu Jan 7 00:54:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 00:54:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v3] In-Reply-To: References: Message-ID: <5dH13tNZVPEf8kEDSXCWcOwqrwIF9MWHM7PTNcyETvU=.e3b8690b-7ea8-4187-bf13-8bc52272a2a4@github.com> On Wed, 6 Jan 2021 01:27:09 GMT, Claes Redestad wrote: >> By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. >> >> On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op >> Patch: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op >> >> See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add cloneInstance baseline micro src/java.base/share/classes/java/security/MessageDigest.java line 185: > 183: MessageDigest md; > 184: > 185: GetInstance.Instance instance = GetInstance.getInstance("MessageDigest", There is another Security.getImpl call inside getInstance(String algorithm, String provider) method. For consistency sake, we should update it also? src/java.base/share/classes/java/security/Provider.java line 1072: > 1070: } > 1071: public int hashCode() { > 1072: return type.hashCode() ^ algorithm.hashCode(); Is this change really necessary? It's faster to compute with ^, but does the generated hash values are as distinct as using Objects.hash()? src/java.base/share/classes/java/security/Provider.java line 1930: > 1928: Class clazz = null; > 1929: if (cache instanceof WeakReference ref){ > 1930: clazz = (ref == null) ? null : (Class)ref.get(); ref should not be null if the instanceof check is true? src/java.base/share/classes/java/security/Provider.java line 1963: > 1961: Constructor con = null; > 1962: if (cache instanceof WeakReference ref){ > 1963: con = (ref == null) ? null : (Constructor)ref.get(); ref should not be null if the instanceof check is true? src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 170: > 168: } > 169: // DCL > 170: synchronized (ProviderConfig.class) { synchronized (this) instead since 'provider' is an instance field? ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Thu Jan 7 03:59:13 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 03:59:13 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v4] In-Reply-To: References: Message-ID: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Address review comments from @valeriep ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1933/files - new: https://git.openjdk.java.net/jdk/pull/1933/files/9bf450ee..11b004c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=02-03 Stats: 16 lines in 3 files changed: 3 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1933/head:pull/1933 PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Thu Jan 7 04:08:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 04:08:56 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v4] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:59:13 GMT, Claes Redestad wrote: >> By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. >> >> On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op >> Patch: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op >> >> See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from @valeriep Thanks for reviewing, Valerie. I've addressed all your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Thu Jan 7 04:09:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 04:09:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v3] In-Reply-To: <5dH13tNZVPEf8kEDSXCWcOwqrwIF9MWHM7PTNcyETvU=.e3b8690b-7ea8-4187-bf13-8bc52272a2a4@github.com> References: <5dH13tNZVPEf8kEDSXCWcOwqrwIF9MWHM7PTNcyETvU=.e3b8690b-7ea8-4187-bf13-8bc52272a2a4@github.com> Message-ID: On Wed, 6 Jan 2021 20:52:19 GMT, Valerie Peng wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add cloneInstance baseline micro > > src/java.base/share/classes/java/security/MessageDigest.java line 185: > >> 183: MessageDigest md; >> 184: >> 185: GetInstance.Instance instance = GetInstance.getInstance("MessageDigest", > > There is another Security.getImpl call inside getInstance(String algorithm, String provider) method. For consistency sake, we should update it also? Sure, why not. The Security.getImpl has a branch checking null provider which is pointless here since we guard against a null provider before that call, so we can reuse the same pattern here. > src/java.base/share/classes/java/security/Provider.java line 1072: > >> 1070: } >> 1071: public int hashCode() { >> 1072: return type.hashCode() ^ algorithm.hashCode(); > > Is this change really necessary? It's faster to compute with ^, but does the generated hash values are as distinct as using Objects.hash()? To avoid any suspicion we'd generate a worse hash here I've reverted this to inline what would be generated going through Objects.hash: `31*31 + type.hashCode()*31 + algorithm.hashCode()` > src/java.base/share/classes/java/security/Provider.java line 1963: > >> 1961: Constructor con = null; >> 1962: if (cache instanceof WeakReference ref){ >> 1963: con = (ref == null) ? null : (Constructor)ref.get(); > > ref should not be null if the instanceof check is true? good catches - these 2 null checks can be removed > src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 170: > >> 168: } >> 169: // DCL >> 170: synchronized (ProviderConfig.class) { > > synchronized (this) instead since 'provider' is an instance field? yes! ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From plevart at openjdk.java.net Thu Jan 7 16:42:56 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 7 Jan 2021 16:42:56 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis wrote: >>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? >> >> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options. > >> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? > > Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative. > > Currently, I will keep this PR open but I expect this to be superseded by the latter. Hi Claes, Would flattening the state of MD5 bring any further improvements? https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083 ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From redestad at openjdk.java.net Thu Jan 7 17:12:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 17:12:00 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart wrote: >>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? >> >> Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative. >> >> Currently, I will keep this PR open but I expect this to be superseded by the latter. > > Hi Claes, > Would flattening the state of MD5 bring any further improvements? > https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083 > Hi Claes, > Would flattening the state of MD5 bring any further improvements? > [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From rhalade at openjdk.java.net Thu Jan 7 18:33:07 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 7 Jan 2021 18:33:07 GMT Subject: RFR: 8039278: console.sh failed Automatically with exit code 1 Message-ID: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> 8039278: console.sh failed Automatically with exit code 1 ------------- Commit messages: - 8039278: update TEST.groups to remove console.sh - 8039278: console.sh failed Automatically with exit code 1 Changes: https://git.openjdk.java.net/jdk/pull/1981/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1981&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8039278 Stats: 130 lines in 2 files changed: 0 ins; 129 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1981.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1981/head:pull/1981 PR: https://git.openjdk.java.net/jdk/pull/1981 From xuelei at openjdk.java.net Thu Jan 7 18:35:07 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Jan 2021 18:35:07 GMT Subject: RFR: 8259385: Cleanup unused assignment Message-ID: In the SunJSSE provider implementation, there are a few cases that the assigned value is never used. For example: int i = 0; i = Byte.toUnsignedInt(buf.get()); could be simplified as ` int i = Byte.toUnsignedInt(buf.get());` Code cleanup, no new regression test. ------------- Commit messages: - 8259385: Cleanup unused assignment Changes: https://git.openjdk.java.net/jdk/pull/1984/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1984&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259385 Stats: 87 lines in 18 files changed: 16 ins; 25 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/1984.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1984/head:pull/1984 PR: https://git.openjdk.java.net/jdk/pull/1984 From weijun at openjdk.java.net Thu Jan 7 18:50:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 7 Jan 2021 18:50:56 GMT Subject: RFR: 8039278: console.sh failed Automatically with exit code 1 In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> Message-ID: On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade wrote: > 8039278: console.sh failed Automatically with exit code 1 Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1981 From xuelei at openjdk.java.net Thu Jan 7 18:50:56 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Jan 2021 18:50:56 GMT Subject: RFR: 8039278: console.sh failed Automatically with exit code 1 In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> Message-ID: On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade wrote: > 8039278: console.sh failed Automatically with exit code 1 Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1981 From rhalade at openjdk.java.net Thu Jan 7 18:50:57 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 7 Jan 2021 18:50:57 GMT Subject: Integrated: 8039278: console.sh failed Automatically with exit code 1 In-Reply-To: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> References: <8YBfbRvm-51IsoLpP1TAJuaZyBC0P4Ja_qOCyvMep48=.004d5b1c-85a8-4af1-b6c6-bd7dd8b62a2c@github.com> Message-ID: On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade wrote: > 8039278: console.sh failed Automatically with exit code 1 This pull request has now been integrated. Changeset: 4ce83f2a Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/4ce83f2a Stats: 130 lines in 2 files changed: 0 ins; 129 del; 1 mod 8039278: console.sh failed Automatically with exit code 1 Reviewed-by: xuelei, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/1981 From mbalao at openjdk.java.net Thu Jan 7 18:59:00 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 18:59:00 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 21:35:48 GMT, Valerie Peng wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Thanks for finding this! There have been intermittent CKR_OPERATION_ACTIVE errors which is likely the result of this bug... > > Existing SunPKCS11 code is based on the PKCS#11 spec, e.g. a call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation, and thus avoid the canceling operation for such scenarios. Ideally, NSS should have properly terminated the operation as the spec described. Knowing the NSS behavior, this defensive-cancellation fix is good. > > There are additional SunPKCS11 impl classes which follow the same model as P11Cipher class and may have to be updated with this defensive-cancellation fix as well. How about P11AEADCipher.java, P11RSACipher.java, P11Signature.java, P11PSSSignature.java, P11Mac.java? > > Thanks, > Valerie Thanks for having a look at this. You're right: there might be problems beyond P11Cipher and this is a good opportunity to have a look at them. I'll start with an analysis of P11Signature. P11Signature makes the following PKCS#11 calls: C_SignInit, C_VerifyInit, C_SignFinal, C_Sign, C_VerifyFinal, C_Verify, C_SignUpdate and C_VerifyUpdate. The type of bug described in JDK-8258833 can potentially happen in all of them except for C_SignInit and C_VerifyInit, where the operation does not need to be terminated upon a failure. In the NSS Software Token (checked on NSS 3.50), an NSC_SignUpdate call goes to sftk_MACUpdate with the 'type' parameter equal to 'SFTK_SIGN' [1]. Assumming there is a 'context' for the type that can be retrieved (otherwise CKR_OPERATION_ACTIVE cannot occur [2]), there are only two paths in which sftk_MACUpdate can return an error (in other words, crv != CKR_OK): [3] and [4]. For these two paths, execution goes to sftk_TerminateOp [5] [6]; which finally cleans up the context [7]. This is consistent with sftk_MACUpdate documentation here [8]. Thus, I don't expect the same kind of error that we may have for NSC_EncryptUpdate. Note how in NSC_EncryptUpdate there are no calls to sftk_TerminateOp [9]. Forcing a 'cancel' operation from OpenJDK when calling C_SignUpdate [10] [11] would incurr in an unnecessary cost; but this cost is paid on an already-slow path. The same reasoning applies to NSC_VerifyUpdate, as it uses same sftk_MACUpdate function with the 'type' parameter equal to 'SFTK_SIGN' [12]. When it comes to C_SignFinal and C_VerifyFinal; the operation (assumming a valid context was obtained) is almost always terminated [13] [14]. There is an exception to the previous statement: In C_SignFinal, a CKR_BUFFER_TOO_SMALL does not terminate the session (while returning an error) [15]. This is PKCS#11 standard compliant, and must be handled in the OpenJDK side. The approach in P11Cipher to analogous cases is to throw an exception and cancel the operation at the P11Cipher-level (returning a session with an active operation to the Session Manager previous to JDK-8258833 fix) [16] [17]. The current P11Signature implementation does not do this [18], and incurrs in the bug of returning the session to the SessionManager with an active operation. We need to fix this in every place where C_SignFinal is used. In C_Sign, functions such as NSC_SignUpdate and NSC_SignFinal (which handle active operations in most cases if an error occurs) are used for multi-part operations. If it's not a multi-part operation and the error is different than CKR_BUFFER_TOO_SMALL, the operation is terminated [19]. This is similar to what happens in NSC_SignFinal, and we need to handle it in the OpenJDK side every time C_Sign is called (i.e.: [20] [21]). C_Verify either uses NSC_VerifyUpdate/NSC_VerifyFinal or always terminates the operation [22]; so it shouldn't be a problem. In summary, I believe we need changes in the OpenJDK side to properly handle CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11 functions are called from P11Signature. Even if other error types or functions such as C_VerifyFinal, C_Verify, NSC_SignUpdate and NSC_VerifyUpdate should not need an explicit cancel; we might want to do it anyways to be more defensive and do not depend on a specific NSS implementation. -- [1] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3041 [2] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L423 [3] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3010 [4] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3015 [5] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3027 [6] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L393 [7] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L401 [8] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L2973 [9] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1303 [10] - https://github.com/openjdk/jdk/blob/78be334c3817a1b5840922a9bf1339a40dcc5185/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L526 [11] - https://github.com/openjdk/jdk/blob/78be334c3817a1b5840922a9bf1339a40dcc5185/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L573 [12] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3558 [13] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3597 [14] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3095 [15] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3088 [16] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L803 [17] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L898 [18] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L657 [19] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3145 [20] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L636 [21] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java#L642 [22] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L3541 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From rhalade at openjdk.java.net Thu Jan 7 19:25:09 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 7 Jan 2021 19:25:09 GMT Subject: [jdk16] Integrated: 8039278: console.sh failed Automatically with exit code 1 Message-ID: Reviewed-by: xuelei, weijun ------------- Commit messages: - 8039278: console.sh failed Automatically with exit code 1 Changes: https://git.openjdk.java.net/jdk16/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=93&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8039278 Stats: 130 lines in 2 files changed: 0 ins; 129 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk16/pull/93 From rhalade at openjdk.java.net Thu Jan 7 19:25:10 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 7 Jan 2021 19:25:10 GMT Subject: [jdk16] Integrated: 8039278: console.sh failed Automatically with exit code 1 In-Reply-To: References: Message-ID: <_nkFc6UffCK49iU8BQw94oazB3MB_8G9YFHrW_SHst8=.adade213-983e-4447-a3b4-2cf2e5ededc7@github.com> On Thu, 7 Jan 2021 19:19:32 GMT, Rajan Halade wrote: > Reviewed-by: xuelei, weijun This pull request has now been integrated. Changeset: 1973fbee Author: Rajan Halade URL: https://git.openjdk.java.net/jdk16/commit/1973fbee Stats: 130 lines in 2 files changed: 0 ins; 129 del; 1 mod 8039278: console.sh failed Automatically with exit code 1 Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a ------------- PR: https://git.openjdk.java.net/jdk16/pull/93 From valeriep at openjdk.java.net Thu Jan 7 19:31:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 19:31:55 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 Obscure bug, thanks for report and the fix. I will take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From mbalao at openjdk.java.net Thu Jan 7 19:53:59 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 19:53:59 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Tue, 5 Jan 2021 19:30:13 GMT, Valerie Peng wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 122: > >> 120: cipher.doFinal(new byte[1], 0, 0); >> 121: } else { >> 122: cipher.update(new byte[1]); > > Why only calling update(..) for Cipher encryption would lead to Exception? Seems strange... Because a C_EncryptUpdate call that returns with an error here [1] implies that a session (with an active operation) is returned to the Session Manager here [2] [3]. For decryption, where we have proper padding on the Java side while doing an update, the test exercises the doFinal path. Decryption/Encryption is anecdotal here: what the test wants is coverage on both update and doFinal paths. -- [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L584 [2] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L631 [3] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L423 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Thu Jan 7 19:54:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 19:54:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v4] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:59:13 GMT, Claes Redestad wrote: >> By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. >> >> On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op >> Patch: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op >> >> See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from @valeriep src/java.base/share/classes/java/security/Provider.java line 1072: > 1070: } > 1071: public int hashCode() { > 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode(); Well, perhaps we just revert to Objects.hash(...) (better readability and potential future enhancement in case one is available)? Or, if we want to adopt the same calculation based on current Objects.hash(..) impl, the 31*31 part doesn't not seem to be too useful and can be removed for this particular case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From mbalao at openjdk.java.net Thu Jan 7 20:14:11 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 20:14:11 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2] In-Reply-To: References: Message-ID: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Comment describing the CancelMultipart test assertion. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/542b2340..91363c16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=00-01 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Thu Jan 7 20:14:11 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 20:14:11 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2] In-Reply-To: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Tue, 5 Jan 2021 19:32:42 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment describing the CancelMultipart test assertion. > > test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 194: > >> 192: private static void tryCipherInit() throws Exception { >> 193: Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding", provider); >> 194: cipher.init(Cipher.ENCRYPT_MODE, key); > > Add a comment here or to this method about the CKR_OPERATION_ACTIVE error (w/o this fix) as this is actually the key test point. Right, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Thu Jan 7 20:31:58 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 20:31:58 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2] In-Reply-To: References: Message-ID: <6NprEAHTPHhiyeYIWny_oHXwkEGRqsM5sxoM3_R-caQ=.4ba4ca3e-b1fb-4327-adea-b83e79e7e1a7@github.com> On Tue, 5 Jan 2021 19:41:27 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment describing the CancelMultipart test assertion. > > test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50: > >> 48: } >> 49: >> 50: private static class SessionLeaker { > > The term "leak/leaker" is used extensively in the test, however, this is not really a leak conceptually, but rather sessions w/ active states/operations which are unusable and lead to unexpected PKCS#11 errors subsequently. Maybe replace it with other terms like "corrupt/corruptor" or other similar terms would be more suitable? I chose the term 'leak' in the sense of a resource not properly cleaned up. In this case, the 'leak' would not cause a memory/sockets/file-descriptors but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is that something (a Session) unexpectedly (with an active operation) passes from one side (a P11Cipher instance) to another (the Session Manager). I don't believe 'corruptor' describes the concept better than 'leaker'. The Session is not corrupt, it can be used for for a specific purpose (the same operation that previously failed). Any other suggestion? Hmm... I cannot think of something better. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Thu Jan 7 20:53:59 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 7 Jan 2021 20:53:59 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> On Thu, 7 Jan 2021 18:56:03 GMT, Martin Balao wrote: > In summary, I believe we need changes in the OpenJDK side to properly handle CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11 functions are called from P11Signature. Even if other error types or functions such as C_VerifyFinal, C_Verify, NSC_SignUpdate and NSC_VerifyUpdate should not need an explicit cancel; we might want to do it anyways to be more defensive and do not depend on a specific NSS implementation. > I'm not entirely sure that we can trigger the CKR_BUFFER_TOO_SMALL potential bug from OpenJDK because the output buffer is allocated in the OpenJDK native code [1] for C_Sign and the length is equal to 4K [2]. In the case of C_SignFinal, the CKR_BUFFER_TOO_SMALL error is handled in native code [3]. My understanding is that we still want to be defensive here, and do not depend on a specific NSS version that may leak active operations on some types of errors. The difference is that this change in P11Signature won't have a regression test. @valeriepeng are you okay with this reasoning? -- [1] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L142 [2] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h#L166 [3] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L252 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Thu Jan 7 21:03:57 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 21:03:57 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2] In-Reply-To: <6NprEAHTPHhiyeYIWny_oHXwkEGRqsM5sxoM3_R-caQ=.4ba4ca3e-b1fb-4327-adea-b83e79e7e1a7@github.com> References: <6NprEAHTPHhiyeYIWny_oHXwkEGRqsM5sxoM3_R-caQ=.4ba4ca3e-b1fb-4327-adea-b83e79e7e1a7@github.com> Message-ID: <7oODZ8ZPvNRb7EJ_KmluKE90ZSurcZLnrLjtKJI_4BM=.b6958e2d-0967-4a6f-b2e9-b68921e67450@github.com> On Thu, 7 Jan 2021 20:29:35 GMT, Martin Balao wrote: >> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50: >> >>> 48: } >>> 49: >>> 50: private static class SessionLeaker { >> >> The term "leak/leaker" is used extensively in the test, however, this is not really a leak conceptually, but rather sessions w/ active states/operations which are unusable and lead to unexpected PKCS#11 errors subsequently. Maybe replace it with other terms like "corrupt/corruptor" or other similar terms would be more suitable? > > I chose the term 'leak' in the sense of a resource not properly cleaned up. In this case, the 'leak' would not cause a memory/sockets/file-descriptors but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is that something (a Session) unexpectedly (with an active operation) passes from one side (a P11Cipher instance) to another (the Session Manager). I don't believe 'corruptor' describes the concept better than 'leaker'. The Session is not corrupt, it can be used for for a specific purpose (the same operation that previously failed). Any other suggestion? Hmm... I cannot think of something better. So, after this PKCS11 session failed with an error, you can continue using it, say give it another byte[] and it would continue to work as if the earlier failed call never happened? I have not really tried it and thought that this session is unusable due to the combination of an existing error (say some exception happened during the encrypt update call) and active operation state. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From cverghese at openjdk.java.net Thu Jan 7 21:07:56 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 7 Jan 2021 21:07:56 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 23:56:35 GMT, Xue-Lei Andrew Fan wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Thank you for take care of this issue. Looks good to me. While looking into the TrustTrustedCert.java test, we found out this change may cause the test to fails intermittently. This is because it's is not expecting a SocketException in Line 134. The root cause for this intermittent failure seems to be that when the server processes the the ClientHello message, it iterates through a list of producers to create the response message. These response messages are written to the socket by each producer, and the client can start processing these messages before all of them are sent. If one of the earlier messages causes the client to reject the TLS handshake (in this example, a bad certificate), the client will send a TLS fatal alert and close the socket. In most scenarios, by the time the TLS fatal alert is received by the server, all the pending TLS handshake messages would?ve been written into the socket, but if the client response is fast enough, this TLS alert can reach the server before it has finished sending all the messages. The server will not wait to check if it has received a fatal alert from the client and it will attempt to send the next message anyway. Because in this scenario the socket has already been closed by the client, a SocketException (Broken Pipe) will be generated, instead of the more appropriate SSLHandshakeException. Before this patch, those SocketExceptions were at least being wrapped as SSLException, but now, the SocketException will go all the way up. Most of the time, this might not be a problem, but there are scenarios that come to mind where this could become relevant. The simpler one to explain is MTLS, where a very similar scenario can happen but this time in the client side if the server sends the fatal while the client is still writing (for example, rejecting the client certificate before this has sent the Client Key Exchange). Again, instead of an SSLHanshakeException, we have SSLException before this patch and SocketException after. In this case, seeing a SocketException the client may decide to retry the connection (while for an SSLException or SSLHandshakeException, most likely it wouldn't). How bad this is, and how bad the potential for an extra retry is compared to the current situation when retries are not happening for transient errors, we'll leave for the discussion. Additionally, although the step between Certificate and Server/Client Key Exchange is the most likely to trigger this, every time multiple producers are being called there is a chance for this issue to arise. The good news is the issue requires round-trip communication between server and client to be faster than processing all the producers in a batch. The aforementioned test triggers this behavior quite often as both sides of the TLS connection are on the same machine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From redestad at openjdk.java.net Thu Jan 7 21:23:19 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 21:23:19 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v5] In-Reply-To: References: Message-ID: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Remove constant factor in hashCode - Merge branch 'master' into provider_concache - Address review comments from @valeriep - Add cloneInstance baseline micro - Cache constructor in the Provider.Service instead of a ClassValue. Fix inefficient synchronization in ProviderConfig. Store EngineDescriptor in Service instead of looking it up every time. - NSPE - Add provider-based micro, reduce digesters checked by default - Add GetMessageDigests micro - Missing static - 8259065: java.security.Provider should cache default constructors ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1933/files - new: https://git.openjdk.java.net/jdk/pull/1933/files/11b004c8..5a4dbe43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1933&range=03-04 Stats: 1087 lines in 190 files changed: 584 ins; 201 del; 302 mod Patch: https://git.openjdk.java.net/jdk/pull/1933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1933/head:pull/1933 PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Thu Jan 7 21:23:21 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 7 Jan 2021 21:23:21 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v4] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:50:44 GMT, Valerie Peng wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from @valeriep > > src/java.base/share/classes/java/security/Provider.java line 1072: > >> 1070: } >> 1071: public int hashCode() { >> 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode(); > > Well, perhaps we just revert to Objects.hash(...) (better readability and potential future enhancement in case one is available)? Or, if we want to adopt the same calculation based on current Objects.hash(..) impl, the 31*31 part doesn't not seem to be too useful and can be removed for this particular case. Robustly optimizing the JIT so that `Objects.hash` can avoid creating the `Object[]` might be further off than we'd like to think. I think the one-liner proposed here is a good tradeoff between performance and maintainability/readability in a _global_ sense: this one-liner avoids non-trivial overhead and allocation that might otherwise still be a strong enough motivator to cache calls to `MessageDigest.getInstance` at call-sites such as in `UUID::nameUUIDFromBytes`. Removing the 31*31 factor shouldn't hurt how well-distributed hashes get, just shuffle things around. I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From mullan at openjdk.java.net Thu Jan 7 21:26:55 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 7 Jan 2021 21:26:55 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 90: > 88: p = Security.getProvider(providerName); > 89: if (p == null) { > 90: p = AccessController.doPrivileged( Could you use the limited version of doPrivileged and only assert the permissions that are strictly necessary to instantiate a provider? ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From github.com+573017+michael-o at openjdk.java.net Thu Jan 7 21:43:56 2021 From: github.com+573017+michael-o at openjdk.java.net (Michael Osipov) Date: Thu, 7 Jan 2021 21:43:56 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 23:56:35 GMT, Xue-Lei Andrew Fan wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Thank you for take care of this issue. Looks good to me. Apache HttpComponents PMC here, thanks for the follow up! ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Thu Jan 7 23:36:54 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Jan 2021 23:36:54 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 21:04:48 GMT, Clive Verghese wrote: > While looking into the TrustTrustedCert.java test, we found out this change may cause the test to fails intermittently. This is because it's is not expecting a SocketException in Line 134. The root cause for this intermittent failure seems to be that when the server processes the the ClientHello message, it iterates through a list of producers to create the response message. These response messages are written to the socket by each producer, and the client can start processing these messages before all of them are sent. > > If one of the earlier messages causes the client to reject the TLS handshake (in this example, a bad certificate), the client will send a TLS fatal alert and close the socket. In most scenarios, by the time the TLS fatal alert is received by the server, all the pending TLS handshake messages would?ve been written into the socket, but if the client response is fast enough, this TLS alert can reach the server before it has finished sending all the messages. The server will not wait to check if it has received a fatal alert from the client and it will attempt to send the next message anyway. > > Because in this scenario the socket has already been closed by the client, a SocketException (Broken Pipe) will be generated, instead of the more appropriate SSLHandshakeException. Before this patch, those SocketExceptions were at least being wrapped as SSLException, but now, the SocketException will go all the way up. Most of the time, this might not be a problem, but there are scenarios that come to mind where this could become relevant. The simpler one to explain is MTLS, where a very similar scenario can happen but this time in the client side if the server sends the fatal while the client is still writing (for example, rejecting the client certificate before this has sent the Client Key Exchange). Again, instead of an SSLHanshakeException, we have SSLException before this patch and SocketException after. In this case, seeing a SocketException the client may decide to retry the connection (while for an SSLException or SSLHandshakeException, most likely it wouldn't). How bad thi s is, and how bad the potential for an extra retry is compared to the current situation when retries are not happening for transient errors, we'll leave for the discussion. > > Additionally, although the step between Certificate and Server/Client Key Exchange is the most likely to trigger this, every time multiple producers are being called there is a chance for this issue to arise. The good news is the issue requires round-trip communication between server and client to be faster than processing all the producers in a batch. The aforementioned test triggers this behavior quite often as both sides of the TLS connection are on the same machine. Maybe, sending the fatal alter before throw the socket exception could be a safer update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Thu Jan 7 23:44:00 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Jan 2021 23:44:00 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 23:28:34 GMT, Clive Verghese wrote: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Changes requested by xuelei (Reviewer). src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1678: > 1676: // Don't close the Socket in case of timeouts, interrupts or SocketException. > 1677: if (cause instanceof InterruptedIOException || > 1678: cause instanceof SocketException) { Maybe we still need to shutdown the connection with a fatal alter for socket exception, otherwise there might be socket leaks. Instead, the socket exception could be thrown after the fatal alert. src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 452: > 450: } catch (SocketException se) { > 451: // don't change exception in case of SocketException > 452: throw se; Maybe, the fatal alter could be sent before thrown the socket exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From valeriep at openjdk.java.net Thu Jan 7 23:56:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 23:56:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v5] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 21:23:19 GMT, Claes Redestad wrote: >> By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. >> >> On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op >> Patch: >> Benchmark (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op >> GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op >> GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op >> GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op >> GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op >> >> See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Remove constant factor in hashCode > - Merge branch 'master' into provider_concache > - Address review comments from @valeriep > - Add cloneInstance baseline micro > - Cache constructor in the Provider.Service instead of a ClassValue. Fix inefficient synchronization in ProviderConfig. Store EngineDescriptor in Service instead of looking it up every time. > - NSPE > - Add provider-based micro, reduce digesters checked by default > - Add GetMessageDigests micro > - Missing static > - 8259065: java.security.Provider should cache default constructors Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From valeriep at openjdk.java.net Thu Jan 7 23:56:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Jan 2021 23:56:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v4] In-Reply-To: References: Message-ID: <22D1Bv4-Wx37fIjDa4UrmFwOaB9Hj12l6DFQghy3EMc=.a23413c3-71d5-4eb8-98e2-47960bf3806f@github.com> On Thu, 7 Jan 2021 21:18:22 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/security/Provider.java line 1072: >> >>> 1070: } >>> 1071: public int hashCode() { >>> 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode(); >> >> Well, perhaps we just revert to Objects.hash(...) (better readability and potential future enhancement in case one is available)? Or, if we want to adopt the same calculation based on current Objects.hash(..) impl, the 31*31 part doesn't not seem to be too useful and can be removed for this particular case. > > Robustly optimizing the JIT so that `Objects.hash` can avoid creating the `Object[]` might be further off than we'd like to think. > > I think the one-liner proposed here is a good tradeoff between performance and maintainability/readability in a _global_ sense: this one-liner avoids non-trivial overhead and allocation that might otherwise still be a strong enough motivator to cache calls to `MessageDigest.getInstance` at call-sites such as in `UUID::nameUUIDFromBytes`. > > Removing the 31*31 factor shouldn't hurt how well-distributed hashes get, just shuffle things around. I'll remove it. Ok, all looks good now. Thanks~ ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Fri Jan 8 09:25:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 09:25:00 GMT Subject: RFR: 8259065: Optimize MessageDigest.getInstance [v5] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 23:53:34 GMT, Valerie Peng wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Remove constant factor in hashCode >> - Merge branch 'master' into provider_concache >> - Address review comments from @valeriep >> - Add cloneInstance baseline micro >> - Cache constructor in the Provider.Service instead of a ClassValue. Fix inefficient synchronization in ProviderConfig. Store EngineDescriptor in Service instead of looking it up every time. >> - NSPE >> - Add provider-based micro, reduce digesters checked by default >> - Add GetMessageDigests micro >> - Missing static >> - 8259065: java.security.Provider should cache default constructors > > Marked as reviewed by valeriep (Reviewer). Thanks for reviewing, Valerie! ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From redestad at openjdk.java.net Fri Jan 8 09:25:03 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 09:25:03 GMT Subject: Integrated: 8259065: Optimize MessageDigest.getInstance In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 16:40:50 GMT, Claes Redestad wrote: > By caching default constructors used in `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the overhead of allocating instances in a variety of places, e.g., `MessageDigest::getInstance`, without compromising thread-safety or security. > > On the provided microbenchmark `MessageDigest.getInstance(digesterName)` improves substantially for any `digesterName` - around -90ns/op and -120B/op: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 293.929 ? 11.294 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 424.028 ? 0.003 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 322.928 ? 16.503 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 688.039 ? 0.003 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 338.140 ? 13.902 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 640.037 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 312.066 ? 12.805 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 424.029 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 345.777 ? 16.669 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 688.040 ? 0.003 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 371.134 ? 18.485 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 640.039 ? 0.004 B/op > Patch: > Benchmark (digesterName) Mode Cnt Score Error Units > GetMessageDigest.getInstance md5 avgt 30 210.629 ? 6.598 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm md5 avgt 30 304.021 ? 0.002 B/op > GetMessageDigest.getInstance SHA-1 avgt 30 229.161 ? 8.158 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-1 avgt 30 568.030 ? 0.002 B/op > GetMessageDigest.getInstance SHA-256 avgt 30 260.013 ? 15.032 ns/op > GetMessageDigest.getInstance:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider md5 avgt 30 231.928 ? 10.455 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm md5 avgt 30 304.020 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-1 avgt 30 247.178 ? 11.209 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-1 avgt 30 568.029 ? 0.002 B/op > GetMessageDigest.getInstanceWithProvider SHA-256 avgt 30 265.625 ? 10.465 ns/op > GetMessageDigest.getInstanceWithProvider:?gc.alloc.rate.norm SHA-256 avgt 30 520.030 ? 0.003 B/op > > See: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#reflection-overheads for context. This pull request has now been integrated. Changeset: fc1d2a1e Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/fc1d2a1e Stats: 331 lines in 4 files changed: 195 ins; 73 del; 63 mod 8259065: Optimize MessageDigest.getInstance Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/1933 From mbalao at openjdk.java.net Fri Jan 8 14:08:57 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 14:08:57 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2] In-Reply-To: <7oODZ8ZPvNRb7EJ_KmluKE90ZSurcZLnrLjtKJI_4BM=.b6958e2d-0967-4a6f-b2e9-b68921e67450@github.com> References: <6NprEAHTPHhiyeYIWny_oHXwkEGRqsM5sxoM3_R-caQ=.4ba4ca3e-b1fb-4327-adea-b83e79e7e1a7@github.com> <7oODZ8ZPvNRb7EJ_KmluKE90ZSurcZLnrLjtKJI_4BM=.b6958e2d-0967-4a6f-b2e9-b68921e67450@github.com> Message-ID: On Thu, 7 Jan 2021 21:00:58 GMT, Valerie Peng wrote: >> I chose the term 'leak' in the sense of a resource not properly cleaned up. In this case, the 'leak' would not cause a memory/sockets/file-descriptors but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is that something (a Session) unexpectedly (with an active operation) passes from one side (a P11Cipher instance) to another (the Session Manager). I don't believe 'corruptor' describes the concept better than 'leaker'. The Session is not corrupt, it can be used for for a specific purpose (the same operation that previously failed). Any other suggestion? Hmm... I cannot think of something better. > > So, after this PKCS11 session failed with an error, you can continue using it, say give it another byte[] and it would continue to work as if the earlier failed call never happened? I have not really tried it and thought that this session is unusable due to the combination of an existing error (say some exception happened during the encrypt update call) and active operation state. Yes, that's right: you can use the session to continue the same operation. In fact, there is a pattern -also used in some Windows API functions- that you send an output buffer of length 0, you get a CKR_BUFFER_TOO_SMALL error and the buffer size that would have been required; and you make a second call with the right buffer size. This pattern is used from the OpenJDK native library that communicates with the PKCS#11 lib. Some types of errors (those that do not free the context) are not fatal. The problem is that we end up returning a session to the Session Manager and we try to use the session to initialize a different operation, while the previous is still active. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From rriggs at openjdk.java.net Fri Jan 8 15:52:04 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 15:52:04 GMT Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security Message-ID: Followup to the addition of java.util.HexFormat. Uses of adhoc hexadecimal conversions are replaced with HexFormat. Redundant utility methods are modified or removed. In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. ------------- Commit messages: - 8258796: [test] Apply HexFormat to tests for java.security Changes: https://git.openjdk.java.net/jdk/pull/2006/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2006&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258796 Stats: 738 lines in 43 files changed: 81 ins; 466 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/2006.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2006/head:pull/2006 PR: https://git.openjdk.java.net/jdk/pull/2006 From rriggs at openjdk.java.net Fri Jan 8 16:09:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 16:09:55 GMT Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. Removing the hotspot-runtime label to avoid spamming that alias. Add it back if it is warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2006 From rriggs at openjdk.java.net Fri Jan 8 16:26:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 16:26:09 GMT Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security [v2] In-Reply-To: References: Message-ID: <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com> > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Update copyrights to 2021 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2006/files - new: https://git.openjdk.java.net/jdk/pull/2006/files/c437a74b..b6908530 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2006&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2006&range=00-01 Stats: 43 lines in 43 files changed: 0 ins; 0 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/2006.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2006/head:pull/2006 PR: https://git.openjdk.java.net/jdk/pull/2006 From xuelei at openjdk.java.net Fri Jan 8 17:04:55 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 8 Jan 2021 17:04:55 GMT Subject: RFR: 8258796: [test] Apply HexFormat to tests for java.security [v2] In-Reply-To: <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com> References: <2OMJyKBDALaXTS-eoUt9sasUZ_RZ62oIDAswaAhQZSE=.0f445bed-6960-4cb7-a5c9-88c182f454c7@github.com> Message-ID: On Fri, 8 Jan 2021 16:26:09 GMT, Roger Riggs wrote: >> Followup to the addition of java.util.HexFormat. >> Uses of adhoc hexadecimal conversions are replaced with HexFormat. >> Redundant utility methods are modified or removed. >> In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Update copyrights to 2021 Looks good to me. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2006 From weijun at openjdk.java.net Fri Jan 8 19:21:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 8 Jan 2021 19:21:13 GMT Subject: [jdk16] RFR: 8258915: More temporary buffer cleanup Message-ID: More temporary byte array, char array, keyspec cleanup around keys and passwords. No new regression test. ------------- Commit messages: - 8258915: More temporary buffer cleanup Changes: https://git.openjdk.java.net/jdk16/pull/98/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=98&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258915 Stats: 1544 lines in 51 files changed: 704 ins; 428 del; 412 mod Patch: https://git.openjdk.java.net/jdk16/pull/98.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/98/head:pull/98 PR: https://git.openjdk.java.net/jdk16/pull/98 From mbalao at openjdk.java.net Fri Jan 8 19:31:58 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 19:31:58 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Thu, 7 Jan 2021 20:51:02 GMT, Martin Balao wrote: > > @valeriepeng are you okay with this reasoning? > I changed my mind around this decision and I'm inclined not to make any code changes to P11Signature. Only a documentation note that reflects this analysis should be needed. First of all, what I described here [1], about the NSS Software Token behavior, matches the PKCS#11 v2.20 standard [2]: 1) "A call to C_SignFinal always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call"; and, 2) "A call to C_Sign always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL". In addition, as described here [3], CKR_BUFFER_TOO_SMALL is not expected to reach P11Signature Java code because it's handled by the libj2pkcs11 OpenJDK native library. Thus, cancelling a potentially active operation is not required by the standard nor needed. If we find a non-compliant implementation of the PKCS#11 standard in the future, we might want to revisit this decision. Even if the performance cost of cancelling an operation 'just in case' should be affordable, we might unnecessarily get into errors such as CKR_OPERATION_NOT_INITIALIZED. The P11Cipher case is different because the size of the output buffer (the one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary to the PKCS#11 v2.20 standard -which states "A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation."-, the NSS Software Token may not terminate the operation on other error types [8] [9]. This is why we need to always cancel from P11Cipher. -- [1] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756312031 [2] - https://www.cryptsoft.com/pkcs11doc/v220/group__SEC__11__11__SIGNING__AND__MACING__FUNCTIONS.html [3] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756376546 [4] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L280 [5] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L228 [6] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L463 [7] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L514 [8] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1356 [9] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1380 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 8 19:38:59 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 8 Jan 2021 19:38:59 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com> On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java line 96: > 94: } > 95: > 96: } nit: add a newline here, to get rid of the red icon... ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From valeriep at openjdk.java.net Fri Jan 8 19:42:04 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 8 Jan 2021 19:42:04 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 102: > 100: } > 101: } > 102: }); Sean's suggestion is to add additional arguments here, e.g. null, new RuntimePermission("accessClassInPackage." + ). ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From mbalao at openjdk.java.net Fri Jan 8 20:01:12 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 20:01:12 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3] In-Reply-To: References: Message-ID: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with two additional commits since the last revision: - Documentation note explaining why Cancel Operation is not required in P11Signature - Cancel Operation should not fail if the operation is not initialized in the token. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/91363c16..5bf00de0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=01-02 Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 8 20:11:57 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 8 Jan 2021 20:11:57 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3] In-Reply-To: References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Thu, 7 Jan 2021 19:50:53 GMT, Martin Balao wrote: >> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 122: >> >>> 120: cipher.doFinal(new byte[1], 0, 0); >>> 121: } else { >>> 122: cipher.update(new byte[1]); >> >> Why only calling update(..) for Cipher encryption would lead to Exception? Seems strange... > > Because a C_EncryptUpdate call that returns with an error here [1] implies that a session (with an active operation) is returned to the Session Manager here [2] [3]. For decryption, where we have proper padding on the Java side while doing an update, the test exercises the doFinal path. Decryption/Encryption is anecdotal here: what the test wants is coverage on both update and doFinal paths. > > -- > [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L584 > [2] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L631 > [3] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L423 I understand that the intention/design is to trigger the error condition on various code paths causing the active session to be returned to pool and verify if this issue is fixed or not. What I don't get is that why AES/ECB/NoPadding cipher encrypting a byte[1] w/ an update (where more input could still be given) would trigger an error. The stack trace for the encryption update call (which is the first test, the session should be freshly allocated and not a reused one with active state) is below: java.security.ProviderException: update() failed at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:632) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:529) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:517) at java.base/javax.crypto.Cipher.update(Cipher.java:1832) at CancelMultipart$LeakByteArray.doOperation(CancelMultipart.java:125) at CancelMultipart$SessionLeaker.leakAndTry(CancelMultipart.java:63) at CancelMultipart.executeTest(CancelMultipart.java:158) at CancelMultipart.main(CancelMultipart.java:140) at PKCS11Test.premain(PKCS11Test.java:171) at PKCS11Test.testNSS(PKCS11Test.java:568) at PKCS11Test.main(PKCS11Test.java:207) at CancelMultipart.main(CancelMultipart.java:131) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:584) ... 17 more ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From cverghese at openjdk.java.net Fri Jan 8 20:18:15 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 8 Jan 2021 20:18:15 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v2] In-Reply-To: References: Message-ID: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Shutdown sockets to prevent leak ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1968/files - new: https://git.openjdk.java.net/jdk/pull/1968/files/b161b410..c1d2969f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=00-01 Stats: 27 lines in 2 files changed: 15 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Fri Jan 8 21:22:57 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 8 Jan 2021 21:22:57 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 23:39:34 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Shutdown sockets to prevent leak > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1678: > >> 1676: // Don't close the Socket in case of timeouts, interrupts or SocketException. >> 1677: if (cause instanceof InterruptedIOException || >> 1678: cause instanceof SocketException) { > > Maybe we still need to shutdown the connection with a fatal alter for socket exception, otherwise there might be socket leaks. Instead, the socket exception could be thrown after the fatal alert. Updated to shutdown the socket in case of a SocketException. > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 452: > >> 450: } catch (SocketException se) { >> 451: // don't change exception in case of SocketException >> 452: throw se; > > Maybe, the fatal alter could be sent before thrown the socket exception. The client is sending the fatal, However, the server, since it's producing the message, It's not reading from the socket to see that the client sent the `bad_certificate` SERVER CLIENT * <------------ CLIENT_HELLO CLIENT_HELLO_CONSUMER SERVER_HELLO_PRODUCER -------------> SERVER_HELLO_CONSUMER CERTIFICATE_PRODUCER -------------> CERTIFICATE_CONSUMER CERTIFICATE_STATUS -------------> Still in CERTIFICATE_CONSUMER START SERVER_KEY_EXCHANGE * <------------- CERTIFICATE_CONSUMER sends bad_certificate alert * <------------- CLIENT_CLOSES_SOCKET SERVER_KEY_EXCHANGE attempts to write to socket --------|||| (broken_pipe exception) Server throws a SocketException(broken_pipe) exception instead of SSLException(bad_certificate) or SSLHandshakeException(bad_certificate) When in the producer, the server does not read from the socket, and hence does not process the bad_certificate alert from the client The SERVER_KEY_EXCHANGE produce then attempts to write to the socket, which encounters the broken pipe. We could, in the SSLSocketImpl::handleException, attempt to check if there is a message available in the socket. If so, read the message and throw the appropriate exception. I could open a follow up JBS issue to address this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From mbalao at openjdk.java.net Fri Jan 8 21:30:14 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 21:30:14 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2] In-Reply-To: References: Message-ID: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 Martin Balao has updated the pull request incrementally with two additional commits since the last revision: - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only. - New line character inserted at the end of IllegalPackageAccess.java test file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1961/files - new: https://git.openjdk.java.net/jdk/pull/1961/files/2fcfa69a..5e1e0a97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1961&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1961&range=00-01 Stats: 23 lines in 2 files changed: 10 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1961/head:pull/1961 PR: https://git.openjdk.java.net/jdk/pull/1961 From mbalao at openjdk.java.net Fri Jan 8 21:30:14 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 21:30:14 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:29:29 GMT, Valerie Peng wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Obscure bug, thanks for report and the fix. I will take a look. New proposal limiting the privileges in P11Util::getProvider method and adding a new line character at the end of the IllegalPackageAccess test file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From mbalao at openjdk.java.net Fri Jan 8 21:30:15 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 21:30:15 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2] In-Reply-To: References: Message-ID: <5L1bIDYvFJJ8NBhxvBj7umjZ2o7oVgE6Ure2UBOIOkI=.738f45ea-898c-419d-bb56-f16925c7c302@github.com> On Thu, 7 Jan 2021 21:23:55 GMT, Sean Mullan wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only. >> - New line character inserted at the end of IllegalPackageAccess.java test file > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 90: > >> 88: p = Security.getProvider(providerName); >> 89: if (p == null) { >> 90: p = AccessController.doPrivileged( > > Could you use the limited version of doPrivileged and only assert the permissions that are strictly necessary to instantiate a provider? Yes, makes sense. Thanks for your feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From mbalao at openjdk.java.net Fri Jan 8 21:30:16 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 8 Jan 2021 21:30:16 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2] In-Reply-To: <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com> References: <2W16hPK_xZwzfPMWUg7S4aadNREfN5uAgX147J3-wbM=.c61cb3c9-66fa-45ab-8ea7-1b32b95302a8@github.com> Message-ID: On Fri, 8 Jan 2021 19:35:47 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only. >> - New line character inserted at the end of IllegalPackageAccess.java test file > > test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java line 96: > >> 94: } >> 95: >> 96: } > > nit: add a newline here, to get rid of the red icon... Yes, sure. Thanks for your feedback. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 102: > >> 100: } >> 101: } >> 102: }); > > Sean's suggestion is to add additional arguments here, e.g. null, new RuntimePermission("accessClassInPackage." + ). Yes, replied to Sean above. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From rriggs at openjdk.java.net Fri Jan 8 21:35:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 21:35:53 GMT Subject: Integrated: 8258796: [test] Apply HexFormat to tests for java.security In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. This pull request has now been integrated. Changeset: 628c546b Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/628c546b Stats: 758 lines in 43 files changed: 81 ins; 466 del; 211 mod 8258796: [test] Apply HexFormat to tests for java.security Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2006 From valeriep at openjdk.java.net Fri Jan 8 22:31:05 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 8 Jan 2021 22:31:05 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3] In-Reply-To: References: <6NprEAHTPHhiyeYIWny_oHXwkEGRqsM5sxoM3_R-caQ=.4ba4ca3e-b1fb-4327-adea-b83e79e7e1a7@github.com> <7oODZ8ZPvNRb7EJ_KmluKE90ZSurcZLnrLjtKJI_4BM=.b6958e2d-0967-4a6f-b2e9-b68921e67450@github.com> Message-ID: <56d7YbJPTkJDjbpfkfmzYhmWI0rFEsqsf7vRZbDa_5w=.6e37dd21-cde6-4b0e-9635-2fcf22358fad@github.com> On Fri, 8 Jan 2021 14:06:18 GMT, Martin Balao wrote: >> So, after this PKCS11 session failed with an error, you can continue using it, say give it another byte[] and it would continue to work as if the earlier failed call never happened? I have not really tried it and thought that this session is unusable due to the combination of an existing error (say some exception happened during the encrypt update call) and active operation state. > > Yes, that's right: you can use the session to continue the same operation. In fact, there is a pattern -also used in some Windows API functions- that you send an output buffer of length 0, you get a CKR_BUFFER_TOO_SMALL error and the buffer size that would have been required; and you make a second call with the right buffer size. This pattern is used from the OpenJDK native library that communicates with the PKCS#11 lib. Some types of errors (those that do not free the context) are not fatal. The problem is that we end up returning a session to the Session Manager and we try to use the session to initialize a different operation, while the previous is still active. The double-call-query usage pattern is well documented in the PKCS#11 spec. So, there is no ambiguity there. As for what PKCS11 errors are fatal and the resulting session state seems to be a gray area. Anyway, I agree that defensive cancelling this to work with all PKCS11 library is good so to ensure subsequent operations using the reused session work. I can't think of other better terms. Fine with me to just use "leak" w/ your analogy explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From redestad at openjdk.java.net Fri Jan 8 22:41:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 22:41:05 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests Message-ID: - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. Baseline: (digesterName) (length) Cnt Score Error Units MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms GC: MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op Target: Benchmark (digesterName) (length) Cnt Score Error Units MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms GC MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. ------------- Commit messages: - Remove unused Unsafe import - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) - Merge branch 'master' into improve_md5 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 - Remove unused reverseBytes imports - Copyrights - Fix copy-paste error - Various fixes (IDE stopped IDEing..) - Add imports - mismatched parens - ... and 8 more: https://git.openjdk.java.net/jdk/compare/090bd3af...e1c943c5 Changes: https://git.openjdk.java.net/jdk/pull/1855/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259498 Stats: 649 lines in 8 files changed: 83 ins; 344 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/1855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855 PR: https://git.openjdk.java.net/jdk/pull/1855 From github.com+14116124+dellcliff at openjdk.java.net Fri Jan 8 22:41:05 2021 From: github.com+14116124+dellcliff at openjdk.java.net (DellCliff) Date: Fri, 8 Jan 2021 22:41:05 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic? ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From github.com+14116124+dellcliff at openjdk.java.net Fri Jan 8 22:41:06 2021 From: github.com+14116124+dellcliff at openjdk.java.net (DellCliff) Date: Fri, 8 Jan 2021 22:41:06 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> On Tue, 5 Jan 2021 21:51:51 GMT, DellCliff wrote: >> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms >> MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms >> MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms >> MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms >> MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms >> MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op >> >> Target: >> Benchmark (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms >> MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms >> MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms >> MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms >> MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms >> MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms >> >> GC >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op >> >> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. >> >> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. >> >> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. > > Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic? Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 8 22:41:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 22:41:06 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> Message-ID: On Wed, 6 Jan 2021 00:41:29 GMT, Claes Redestad wrote: >> Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`? > > Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring. > > Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`. I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 8 22:41:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 22:41:06 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> References: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> Message-ID: On Tue, 5 Jan 2021 23:08:43 GMT, DellCliff wrote: >> Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic? > > Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`? Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring. Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 8 22:41:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 22:41:06 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> Message-ID: On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad wrote: >> Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring. >> >> Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`. > > I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`. Removing the UUID clone cache and running the microbenchmark along with the changes in #1933: Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 2.182 ? 0.090 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate 20000 thrpt 12 439.020 ? 18.241 MB/sec UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 264.022 ? 0.003 B/op The goal now is if to simplify the digest code and compare alternatives. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 8 22:41:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 8 Jan 2021 22:41:06 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> Message-ID: On Thu, 7 Jan 2021 14:45:03 GMT, Claes Redestad wrote: >> I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`. > > Removing the UUID clone cache and running the microbenchmark along with the changes in #1933: > > Benchmark (size) Mode Cnt Score Error Units > UUIDBench.fromType3Bytes 20000 thrpt 12 2.182 ? 0.090 ops/us > UUIDBench.fromType3Bytes:?gc.alloc.rate 20000 thrpt 12 439.020 ? 18.241 MB/sec > UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 264.022 ? 0.003 B/op > > The goal now is if to simplify the digest code and compare alternatives. I've run various tests and concluded that the `VarHandle`ized code is matching or improving upon the `Unsafe`-riddled code in `ByteArrayAccess`. I then went ahead and consolidated to use similar code pattern in `ByteArrayAccess` for consistency, which amounts to a good cleanup. With MD5 intrinsics disabled, I get this baseline: Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 1.245 ? 0.077 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 488.042 ? 0.004 B/op With the current patch here (not including #1933): Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 1.431 ? 0.106 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 408.035 ? 0.006 B/op If I isolate the `ByteArrayAccess` changes I'm getting performance neutral or slightly better numbers compared to baseline for these tests: Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 1.317 ? 0.092 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 488.042 ? 0.004 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From cverghese at openjdk.java.net Sat Jan 9 04:27:20 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sat, 9 Jan 2021 04:27:20 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v3] In-Reply-To: References: Message-ID: <30u2_lwgECCDLx1OIhxsHMFy9bZF4iGwFPawAIt3iSs=.a8bd175a-3991-4bb3-b2d2-78e94ce4e741@github.com> > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - 8259516: Alerts sent by peer may not be received correctly during TLS handshake - 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1968/files - new: https://git.openjdk.java.net/jdk/pull/1968/files/c1d2969f..a1bc7114 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=01-02 Stats: 303 lines in 3 files changed: 302 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Sat Jan 9 04:56:14 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sat, 9 Jan 2021 04:56:14 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v4] In-Reply-To: References: Message-ID: <0Oz8ybeJy4sXxfxRBWQBm9eOYnDTx_EKJsP4ZzOef4k=.d352b9e0-ef75-45fc-9ed6-b8a15a540154@github.com> > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1968/files - new: https://git.openjdk.java.net/jdk/pull/1968/files/a1bc7114..bee6e07c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=02-03 Stats: 303 lines in 3 files changed: 0 ins; 302 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Sat Jan 9 04:56:14 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sat, 9 Jan 2021 04:56:14 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v4] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 21:20:15 GMT, Clive Verghese wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 452: >> >>> 450: } catch (SocketException se) { >>> 451: // don't change exception in case of SocketException >>> 452: throw se; >> >> Maybe, the fatal alter could be sent before thrown the socket exception. > > The client is sending the fatal, > > However, the server, since it's producing the message, It's not reading from the socket to see that the client sent the `bad_certificate` > > SERVER CLIENT > * <------------ CLIENT_HELLO > CLIENT_HELLO_CONSUMER > SERVER_HELLO_PRODUCER -------------> SERVER_HELLO_CONSUMER > CERTIFICATE_PRODUCER -------------> CERTIFICATE_CONSUMER > CERTIFICATE_STATUS -------------> Still in CERTIFICATE_CONSUMER > START SERVER_KEY_EXCHANGE_PRODUCER > * <------------- CERTIFICATE_CONSUMER sends bad_certificate alert > * <------------- CLIENT_CLOSES_SOCKET > SERVER_KEY_EXCHANGE_PRODUCER > attempts to write to socket --------|||| > (broken_pipe exception) > > Server throws a SocketException(broken_pipe) exception instead of SSLException(bad_certificate) or SSLHandshakeException(bad_certificate) > > When in the producer, the server does not read from the socket, and hence does not process the bad_certificate alert from the client > > The SERVER_KEY_EXCHANGE produce then attempts to write to the socket, which encounters the broken pipe. > > We could, in the SSLSocketImpl::handleException, attempt to check if there is a message available in the socket. If so, read the message and throw the appropriate exception. > > I could open a follow up JBS issue to address this. > > A draft for the fix is > https://github.com/cliveverghese/jdk/commit/93dba96940d12e930e84e86b6a7f7b4dc918a450 I have created a follow-up JBS issue for the issue, https://bugs.openjdk.java.net/browse/JDK-8259516 The fix for that is available https://github.com/cliveverghese/jdk/commit/a1bc71141b54f90d9d75bd80f6e8068315e78002 I will wait for this to be merged to create the pull request for JDK-8259516. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Sat Jan 9 05:29:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 9 Jan 2021 05:29:57 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v4] In-Reply-To: <0Oz8ybeJy4sXxfxRBWQBm9eOYnDTx_EKJsP4ZzOef4k=.d352b9e0-ef75-45fc-9ed6-b8a15a540154@github.com> References: <0Oz8ybeJy4sXxfxRBWQBm9eOYnDTx_EKJsP4ZzOef4k=.d352b9e0-ef75-45fc-9ed6-b8a15a540154@github.com> Message-ID: On Sat, 9 Jan 2021 04:56:14 GMT, Clive Verghese wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1703: > 1701: } > 1702: > 1703: throw conContext.fatal(alert, cause); It might be not necessary to change the TransportContext by adding a new teardownTransport() method. It would be good to keep the fatal() behavior as if a fatal alter will be sent. Maybe, the exception thrown by fatal() could be replaced with the socket exception, like: if (cause instanceof SocketException) { try { conContext.fatal(alert, cause); } catch (Exception) { // Just delivering the fatal alert, re-throw the socket exception instead. } finally { throw (SocketException)cause; } } else { throw conContext.fatal(alert, cause); } test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java line 59: > 57: static String keyStoreFile = "keystore"; > 58: static String trustStoreFile = "truststore"; > 59: static String passwd = "passphrase"; In JSSE testing, we are trying to avoid the dependency on the binary key store files for a while. Would you like to check out the new template, test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java? You could refer to test/jdk/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java, or search for "extends SSLSocketTemplate" about how to use the new template. ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Sat Jan 9 07:28:05 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 9 Jan 2021 07:28:05 GMT Subject: RFR: 8259517: Incorrect test path in test cases Message-ID: There are a few test paths mentioned in test cases, for example: ` // Test test/javax/net/ssl/NewAPIs/SSLEngine/LargePacket will check ` The test path is no longer good as test directories were re-orged in the past. Code cleanup, test update, no new regression test. ------------- Commit messages: - 8259517: Incorrect test path in test cases Changes: https://git.openjdk.java.net/jdk/pull/2011/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2011&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259517 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2011.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2011/head:pull/2011 PR: https://git.openjdk.java.net/jdk/pull/2011 From weijun at openjdk.java.net Sat Jan 9 14:41:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 9 Jan 2021 14:41:56 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: On Sat, 12 Dec 2020 02:46:45 GMT, Weijun Wang wrote: > @wangweij This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From weijun at openjdk.java.net Sun Jan 10 00:12:59 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 10 Jan 2021 00:12:59 GMT Subject: RFR: 8259517: Incorrect test path in test cases In-Reply-To: References: Message-ID: <7sh9mX4JFfBCaVBZwig909L9PMl4KKZ61SooTpsyP84=.393864de-6684-4735-9591-9aa17f98e05a@github.com> On Sat, 9 Jan 2021 07:22:50 GMT, Xue-Lei Andrew Fan wrote: > There are a few test paths mentioned in test cases, for example: > ` // Test test/javax/net/ssl/NewAPIs/SSLEngine/LargePacket will check > ` > The test path is no longer good as test directories were re-orged in the past. > > Code cleanup, test update, no new regression test. I would add ".java" to the test name. You can choose whatever you like. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2011 From xuelei at openjdk.java.net Sun Jan 10 00:42:11 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 00:42:11 GMT Subject: RFR: 8259517: Incorrect test path in test cases [v2] In-Reply-To: References: Message-ID: > There are a few test paths mentioned in test cases, for example: > ` // Test test/javax/net/ssl/NewAPIs/SSLEngine/LargePacket will check > ` > The test path is no longer good as test directories were re-orged in the past. > > Code cleanup, test update, no new regression test. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Add suffix .java to test file references ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2011/files - new: https://git.openjdk.java.net/jdk/pull/2011/files/c3ff7f50..ace6bde5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2011&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2011&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2011.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2011/head:pull/2011 PR: https://git.openjdk.java.net/jdk/pull/2011 From xuelei at openjdk.java.net Sun Jan 10 00:42:12 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 00:42:12 GMT Subject: RFR: 8259517: Incorrect test path in test cases [v2] In-Reply-To: <7sh9mX4JFfBCaVBZwig909L9PMl4KKZ61SooTpsyP84=.393864de-6684-4735-9591-9aa17f98e05a@github.com> References: <7sh9mX4JFfBCaVBZwig909L9PMl4KKZ61SooTpsyP84=.393864de-6684-4735-9591-9aa17f98e05a@github.com> Message-ID: On Sun, 10 Jan 2021 00:10:15 GMT, Weijun Wang wrote: > I would add ".java" to the test name. You can choose whatever you like. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/2011 From xuelei at openjdk.java.net Sun Jan 10 04:38:56 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 04:38:56 GMT Subject: Integrated: 8259517: Incorrect test path in test cases In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 07:22:50 GMT, Xue-Lei Andrew Fan wrote: > There are a few test paths mentioned in test cases, for example: > ` // Test test/javax/net/ssl/NewAPIs/SSLEngine/LargePacket will check > ` > The test path is no longer good as test directories were re-orged in the past. > > Code cleanup, test update, no new regression test. This pull request has now been integrated. Changeset: 81db63e8 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/81db63e8 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8259517: Incorrect test path in test cases Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/2011 From xuelei at openjdk.java.net Sun Jan 10 05:19:59 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 05:19:59 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v2] In-Reply-To: <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> Message-ID: On Fri, 13 Nov 2020 22:05:31 GMT, Weijun Wang wrote: >> This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. >> >> The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. >> >> Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. >> >> Several tests need to be updated because of internal method signature changes. >> >> The "Support RSA-PSS with parameters" commit introduces a new public API and would need a CSR. >> >> The last patch is one we just fixed several days ago. > > Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by xuelei (Reviewer). src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java line 196: > 194: @SuppressWarnings("deprecation") > 195: SignatureAlgorithmSpi result = implementingClass.newInstance(); > 196: return result; A IDE may have a warning for the result value as it is not really necessary, except for the suppress warnings. Maybe, the @SuppressWarings could be placed in the method level. Just for your reference, go ahead with your preference. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java line 112: > 110: @SuppressWarnings("deprecation") > 111: CanonicalizerSpi tmp = implementingClass.newInstance(); > 112: canonicalizerSpi = tmp; Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java line 198: > 196: @SuppressWarnings("deprecation") > 197: KeyResolverSpi tmp = (KeyResolverSpi) ClassLoaderUtils.loadClass(className, KeyResolver.class).newInstance(); > 198: keyResolverSpi = tmp; Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java line 204: > 202: @SuppressWarnings("deprecation") > 203: TransformSpi tmp = transformSpiClass.newInstance(); > 204: transformSpiHash.put(algorithmURI, tmp); Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java line 237: > 235: @SuppressWarnings("deprecation") > 236: TransformSpi tmp = implementingClass.newInstance(); > 237: transformSpiHash.put(algorithmURI, tmp); Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java line 73: > 71: @SuppressWarnings("deprecation") > 72: XMLParser tmp = (XMLParser) ClassLoaderUtils.loadClass(xmlParserClass, XMLUtils.class).newInstance(); > 73: return tmp; Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java line 72: > 70: @SuppressWarnings("deprecation") > 71: ResourceResolverSpi tmp = resourceResolverClass.newInstance(); > 72: register(tmp, false); Same comment as the one in SignatureAlgorithm.java. src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java line 93: > 91: @SuppressWarnings("deprecation") > 92: ResourceResolverSpi tmp = resourceResolverClass.newInstance(); > 93: register(tmp, true); Same comment as the one in SignatureAlgorithm.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From cverghese at openjdk.java.net Sun Jan 10 06:20:21 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sun, 10 Jan 2021 06:20:21 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v5] In-Reply-To: References: Message-ID: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Address Review comments on transport shutdow and using SSLSocketTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1968/files - new: https://git.openjdk.java.net/jdk/pull/1968/files/bee6e07c..6d2f6433 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=03-04 Stats: 241 lines in 3 files changed: 21 ins; 189 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From xuelei at openjdk.java.net Sun Jan 10 06:56:17 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 06:56:17 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6] In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 06:40:49 GMT, Clive Verghese wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Address Review comments on transport shutdow and using SSLSocketTemplate Looks good to me. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Sun Jan 10 06:56:17 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sun, 10 Jan 2021 06:56:17 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6] In-Reply-To: References: Message-ID: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Address Review comments on transport shutdow and using SSLSocketTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1968/files - new: https://git.openjdk.java.net/jdk/pull/1968/files/6d2f6433..98f15872 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1968&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1968/head:pull/1968 PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Sun Jan 10 06:56:19 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sun, 10 Jan 2021 06:56:19 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v4] In-Reply-To: References: <0Oz8ybeJy4sXxfxRBWQBm9eOYnDTx_EKJsP4ZzOef4k=.d352b9e0-ef75-45fc-9ed6-b8a15a540154@github.com> Message-ID: On Sat, 9 Jan 2021 05:25:40 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java line 59: > >> 57: static String keyStoreFile = "keystore"; >> 58: static String trustStoreFile = "truststore"; >> 59: static String passwd = "passphrase"; > > In JSSE testing, we are trying to avoid the dependency on the binary key store files for a while. Would you like to check out the new template, test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java? You could refer to test/jdk/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java, or search for "extends SSLSocketTemplate" about how to use the new template. I have updated the test to use SSLSocketTemplate. > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1703: > >> 1701: } >> 1702: >> 1703: throw conContext.fatal(alert, cause); > > It might be not necessary to change the TransportContext by adding a new teardownTransport() method. It would be good to keep the fatal() behavior as if a fatal alter will be sent. Maybe, the exception thrown by fatal() could be replaced with the socket exception, like: > > if (cause instanceof SocketException) { > try { > conContext.fatal(alert, cause); > } catch (Exception) { > // Just delivering the fatal alert, re-throw the socket exception instead. > } finally { > throw (SocketException)cause; > } > } else { > throw conContext.fatal(alert, cause); > } Thank you for the feedback, I have updated as recommended. I could not add a throw in the finally block as this generates a warning. Instead i have done this try { conContext.fatal(alert, cause); } catch (Exception e) { // Just delivering the fatal alert, re-throw the socket exception instead. } throw (SocketException)cause; ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From weijun at openjdk.java.net Sun Jan 10 15:24:59 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 10 Jan 2021 15:24:59 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v2] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> Message-ID: On Sun, 10 Jan 2021 04:55:38 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java line 196: > >> 194: @SuppressWarnings("deprecation") >> 195: SignatureAlgorithmSpi result = implementingClass.newInstance(); >> 196: return result; > > A IDE may have a warning for the result value as it is not really necessary, except for the suppress warnings. Maybe, the @SuppressWarings could be placed in the method level. Just for your reference, go ahead with your preference. I am using IntelliJ and there is not such a warning. I chose this style because that exactly where the suppressed warning happens and I don't want a reader to search for it. That said, I'm now thinking of updating the `newInstance()` call with `getDeclaredConstructor().newInstance()`, as suggested by the `@deprecated` section of `newInstance()`. I'll also update to 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From attila at openjdk.java.net Sun Jan 10 19:54:55 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 10 Jan 2021 19:54:55 GMT Subject: RFR: 8259385: Cleanup unused assignment In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:30:27 GMT, Xue-Lei Andrew Fan wrote: > In the SunJSSE provider implementation, there are a few cases that the assigned value is never used. For example: > int i = 0; > i = Byte.toUnsignedInt(buf.get()); > could be simplified as > ` int i = Byte.toUnsignedInt(buf.get());` > > Code cleanup, no new regression test. LGTM. Looks like a good ol' IntelliJ IDEA driven fixing (nothing wrong with that.) Maybe you could also fix those "temproary" typos while in there? FWIW, 2 of 3 occurrences of code containing them are almost entirely equivalent and could be refactored into a static method with a Supplier that produces the digest, but I guess it'd be worth filing a separate issue for that. ------------- Marked as reviewed by attila (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1984 From xuelei at openjdk.java.net Sun Jan 10 21:20:10 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 21:20:10 GMT Subject: RFR: 8259385: Cleanup unused assignment [v2] In-Reply-To: References: Message-ID: > In the SunJSSE provider implementation, there are a few cases that the assigned value is never used. For example: > int i = 0; > i = Byte.toUnsignedInt(buf.get()); > could be simplified as > ` int i = Byte.toUnsignedInt(buf.get());` > > Code cleanup, no new regression test. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Typo correction, temproary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1984/files - new: https://git.openjdk.java.net/jdk/pull/1984/files/9a31381b..3ba6e4d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1984&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1984&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1984.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1984/head:pull/1984 PR: https://git.openjdk.java.net/jdk/pull/1984 From xuelei at openjdk.java.net Sun Jan 10 21:20:11 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 10 Jan 2021 21:20:11 GMT Subject: RFR: 8259385: Cleanup unused assignment [v2] In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 19:52:24 GMT, Attila Szegedi wrote: > LGTM. Looks like a good ol' IntelliJ IDEA driven fixing (nothing wrong with that.) Right. > Maybe you could also fix those "temproary" typos while in there? Updated. Thanks! > FWIW, 2 of 3 occurrences of code containing them are almost entirely equivalent and could be refactored into a static method with a Supplier that produces the digest, but I guess it'd be worth filing a separate issue for that. I will make more evaluation if a new issue could be filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1984 From xuelei at openjdk.java.net Mon Jan 11 00:37:55 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 11 Jan 2021 00:37:55 GMT Subject: Integrated: 8259385: Cleanup unused assignment In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:30:27 GMT, Xue-Lei Andrew Fan wrote: > In the SunJSSE provider implementation, there are a few cases that the assigned value is never used. For example: > int i = 0; > i = Byte.toUnsignedInt(buf.get()); > could be simplified as > ` int i = Byte.toUnsignedInt(buf.get());` > > Code cleanup, no new regression test. This pull request has now been integrated. Changeset: b72de3c5 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/b72de3c5 Stats: 95 lines in 18 files changed: 16 ins; 25 del; 54 mod 8259385: Cleanup unused assignment Reviewed-by: attila ------------- PR: https://git.openjdk.java.net/jdk/pull/1984 From xuelei at openjdk.java.net Mon Jan 11 05:03:03 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 11 Jan 2021 05:03:03 GMT Subject: RFR: 8253635: Implement toString() for SSLEngineImpl Message-ID: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> The SSLSocketImpl and SSLEngineImpl implementation does not override the toString() method. The old code did. BTW, I also made a few code clean up in the SSLSocketImpl.java. Code clean up, trivial update, no new regression test. ------------- Commit messages: - missing a white space - 8253635: Implement toString() for SSLEngineImpl Changes: https://git.openjdk.java.net/jdk/pull/2019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2019&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253635 Stats: 42 lines in 2 files changed: 18 ins; 12 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2019/head:pull/2019 PR: https://git.openjdk.java.net/jdk/pull/2019 From ihse at openjdk.java.net Mon Jan 11 09:23:11 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 09:23:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From simonis at openjdk.java.net Mon Jan 11 12:04:57 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 12:04:57 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6] In-Reply-To: References: Message-ID: <2jr5h2--Tq73MHYRz7MPd-GUodfS5LXytnnHFciKPOw=.b7814fca-55b9-4959-9b00-cea7f887a80b@github.com> On Sun, 10 Jan 2021 06:56:17 GMT, Clive Verghese wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Looks good to me. ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1968 From cverghese at openjdk.java.net Mon Jan 11 12:05:00 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Mon, 11 Jan 2021 12:05:00 GMT Subject: Integrated: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed In-Reply-To: References: Message-ID: <_kcobm6yfQM2f3Fu_ffTK2w0626aCrBfLA7mNrlkzoY=.d5ac0e6e-a516-49c5-82f1-79424a3e01e5@github.com> On Wed, 6 Jan 2021 23:28:34 GMT, Clive Verghese wrote: > This PR aims to revert some more cases where SocketExceptions are improperly being wrapped as SSLException. Some work for this was done in [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving SocketException to decide if the connection should be retried. An example of this would be Apache HTTP client. This PR should ideally fix https://issues.apache.org/jira/browse/HTTPCLIENT-2032 This pull request has now been integrated. Changeset: 01b2804e Author: Clive Verghese Committer: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/01b2804e Stats: 182 lines in 5 files changed: 175 ins; 0 del; 7 mod 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Reviewed-by: xuelei, simonis ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From simonis at openjdk.java.net Mon Jan 11 16:23:13 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 16:23:13 GMT Subject: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6] In-Reply-To: <2jr5h2--Tq73MHYRz7MPd-GUodfS5LXytnnHFciKPOw=.b7814fca-55b9-4959-9b00-cea7f887a80b@github.com> References: <2jr5h2--Tq73MHYRz7MPd-GUodfS5LXytnnHFciKPOw=.b7814fca-55b9-4959-9b00-cea7f887a80b@github.com> Message-ID: On Mon, 11 Jan 2021 12:00:09 GMT, Volker Simonis wrote: >> Clive Verghese has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Looks good to me. This change caused some new test failures (e.g. in `java/net/httpclient/InvalidSSLContextTest.java` or `javax/net/ssl/SSLSession/TestEnabledProtocols.java`). I'm currently working on a PR which will fix these tests... ------------- PR: https://git.openjdk.java.net/jdk/pull/1968 From coffeys at openjdk.java.net Mon Jan 11 16:56:54 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 11 Jan 2021 16:56:54 GMT Subject: RFR: 8253635: Implement toString() for SSLEngineImpl In-Reply-To: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> References: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> Message-ID: <6MwEf7jEsDUNosfriKztXuY6zyH0sp0QEJSI5tA5ae8=.8ae8ff81-c859-454b-a5df-3180f7fcbc65@github.com> On Mon, 11 Jan 2021 04:57:19 GMT, Xue-Lei Andrew Fan wrote: > The SSLSocketImpl and SSLEngineImpl implementation does not override the toString() method. The old code did. BTW, I also made a few code clean up in the SSLSocketImpl.java. > > Code clean up, trivial update, no new regression test. Looks good ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2019 From simonis at openjdk.java.net Mon Jan 11 17:29:18 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 17:29:18 GMT Subject: RFR: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions Message-ID: JDK-8237578 exposes some SocketExceptions directly which were previously wrapped inside an SSLException. The change updated one test to take this new behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other tests. The fix for the other tests is similar like the fix for TrustTrustedCert.java in JDK-8237578: - } catch (SSLException ssle) { + } catch (SSLException | SocketException se) { if (!expectFail) { - throw ssle; + throw se; } // Otherwise, ignore. } ------------- Commit messages: - 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions Changes: https://git.openjdk.java.net/jdk/pull/2029/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2029&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259572 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2029.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2029/head:pull/2029 PR: https://git.openjdk.java.net/jdk/pull/2029 From weijun at openjdk.java.net Mon Jan 11 17:31:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 11 Jan 2021 17:31:00 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3] In-Reply-To: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: > This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. > > The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. > > Several tests need to be updated because of internal method signature changes. > > The "Support RSA-PSS with parameters" commit introduces a new public API and would need a CSR. > > The last patch is one we just fixed several days ago. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - No more newInstance calls - Support RSA-PSS with parameters - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() - Fix test failures - Supporting named RSASSA-PSS without parameters - Reapply 8008744: Rework part of fix for JDK-6741606 - Reapply 8151893: Add security property to configure XML Signature secure validation mode Reapply 8140353: Improve signature checking - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes - Reapply 8038913: Bolster XML support (Init.java part) - Various warnings, the version, and abnormal copyright lines - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3ab6657f...f7ee7648 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1206/files - new: https://git.openjdk.java.net/jdk/pull/1206/files/73c73381..f7ee7648 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=01-02 Stats: 124959 lines in 1924 files changed: 67184 ins; 45132 del; 12643 mod Patch: https://git.openjdk.java.net/jdk/pull/1206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1206/head:pull/1206 PR: https://git.openjdk.java.net/jdk/pull/1206 From weijun at openjdk.java.net Mon Jan 11 17:34:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 11 Jan 2021 17:34:00 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> Message-ID: On Sun, 10 Jan 2021 05:17:23 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: >> >> - No more newInstance calls >> - Support RSA-PSS with parameters >> - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() >> - Fix test failures >> - Supporting named RSASSA-PSS without parameters >> - Reapply 8008744: Rework part of fix for JDK-6741606 >> - Reapply 8151893: Add security property to configure XML Signature secure validation mode >> >> Reapply 8140353: Improve signature checking >> - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes >> - Reapply 8038913: Bolster XML support (Init.java part) >> - Various warnings, the version, and abnormal copyright lines >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/19bade02...f7ee7648 > > Marked as reviewed by xuelei (Reviewer). I've force pushed a new series of commits from scratch. The difference: 1. The `s/Portions copyright/Copyright/` change is inside auto import. 2. Some `s/Sun Microsystems/Oracle/` change in auto import 3. No more deprecated `newInstance()` calls, a new (the last one) commit is created for this ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From weijun at openjdk.java.net Mon Jan 11 18:01:05 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 11 Jan 2021 18:01:05 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> Message-ID: <2xmxyLwSG2TZBwsomKHoeH6HPoq3ksEoUcD6qKmFDOs=.85e21651-8c03-4367-9396-07b0a305dd2a@github.com> On Mon, 11 Jan 2021 17:31:38 GMT, Weijun Wang wrote: >> Marked as reviewed by xuelei (Reviewer). > > I've force pushed a new series of commits from scratch. The difference: > > 1. The `s/Portions copyright/Copyright/` change is inside auto import. > 2. Some `s/Sun Microsystems/Oracle/` change in auto import > 3. No more deprecated `newInstance()` calls, a new (the last one) commit is created for this A CSR at https://bugs.openjdk.java.net/browse/JDK-8259575 is created. I'll remember to update the `@since 16` in source to 17 some time. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From valeriep at openjdk.java.net Mon Jan 11 18:15:58 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 11 Jan 2021 18:15:58 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test file Changes look good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1961 From simonis at openjdk.java.net Mon Jan 11 19:00:06 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 19:00:06 GMT Subject: Withdrawn: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 17:24:23 GMT, Volker Simonis wrote: > JDK-8237578 exposes some SocketExceptions directly which were previously wrapped inside an SSLException. The change updated one test to take this new behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other tests. > > The fix for the other tests is similar like the fix for TrustTrustedCert.java in JDK-8237578: > - } catch (SSLException ssle) { > + } catch (SSLException | SocketException se) { > if (!expectFail) { > - throw ssle; > + throw se; > } // Otherwise, ignore. > } This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2029 From simonis at openjdk.java.net Mon Jan 11 19:30:22 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 19:30:22 GMT Subject: RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed Message-ID: [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn't cause any test failures. ------------- Commit messages: - 8259582: Backout JDK-8237578 until all affected tests have been fixed Changes: https://git.openjdk.java.net/jdk/pull/2035/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2035&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259582 Stats: 182 lines in 5 files changed: 0 ins; 175 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2035/head:pull/2035 PR: https://git.openjdk.java.net/jdk/pull/2035 From valeriep at openjdk.java.net Mon Jan 11 19:35:05 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 11 Jan 2021 19:35:05 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote: >>> In summary, I believe we need changes in the OpenJDK side to properly handle CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11 functions are called from P11Signature. Even if other error types or functions such as C_VerifyFinal, C_Verify, NSC_SignUpdate and NSC_VerifyUpdate should not need an explicit cancel; we might want to do it anyways to be more defensive and do not depend on a specific NSS implementation. >>> >> >> I'm not entirely sure that we can trigger the CKR_BUFFER_TOO_SMALL potential bug from OpenJDK because the output buffer is allocated in the OpenJDK native code [1] for C_Sign and the length is equal to 4K [2]. In the case of C_SignFinal, the CKR_BUFFER_TOO_SMALL error is handled in native code [3]. >> >> My understanding is that we still want to be defensive here, and do not depend on a specific NSS version that may leak active operations on some types of errors. The difference is that this change in P11Signature won't have a regression test. >> >> @valeriepeng are you okay with this reasoning? >> >> -- >> [1] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L142 >> [2] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h#L166 >> [3] - https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L252 > >> >> @valeriepeng are you okay with this reasoning? >> > > I changed my mind around this decision and I'm inclined not to make any code changes to P11Signature. Only a documentation note that reflects this analysis should be needed. > > First of all, what I described here [1], about the NSS Software Token behavior, matches the PKCS#11 v2.20 standard [2]: > > 1) "A call to C_SignFinal always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call"; and, > > 2) "A call to C_Sign always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL". > > In addition, as described here [3], CKR_BUFFER_TOO_SMALL is not expected to reach P11Signature Java code because it's handled by the libj2pkcs11 OpenJDK native library. Thus, cancelling a potentially active operation is not required by the standard nor needed. If we find a non-compliant implementation of the PKCS#11 standard in the future, we might want to revisit this decision. > > Even if the performance cost of cancelling an operation 'just in case' should be affordable, we might unnecessarily get into errors such as CKR_OPERATION_NOT_INITIALIZED. > > The P11Cipher case is different because the size of the output buffer (the one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary to the PKCS#11 v2.20 standard -which states "A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation."-, the NSS Software Token may not terminate the operation on other error types [8] [9]. This is why we need to always cancel from P11Cipher. > > -- > [1] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756312031 > [2] - https://www.cryptsoft.com/pkcs11doc/v220/group__SEC__11__11__SIGNING__AND__MACING__FUNCTIONS.html > [3] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756376546 > [4] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L280 > [5] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L228 > [6] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L463 > [7] - https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L514 > [8] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1356 > [9] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1380 Sure, the reason that I brought up about other classes besides P11Cipher is to confirm/check whether NSS impl conforms to the PKCS#11 spec for all these calls where the same cancellation pattern is used. If NSS impl follows the PKCS#11 spec, that's fine and it's safer to not change the existing code. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From xuelei at openjdk.java.net Mon Jan 11 19:37:00 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 11 Jan 2021 19:37:00 GMT Subject: RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn't cause any test failures. Looks good to me. Thank you very much! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2035 From valeriep at openjdk.java.net Mon Jan 11 19:54:59 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 11 Jan 2021 19:54:59 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote: > The P11Cipher case is different because the size of the output buffer (the one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary to the PKCS#11 v2.20 standard -which states "A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation."-, the NSS Software Token may not terminate the operation on other error types [8] [9]. This is why we need to always cancel from P11Cipher. For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mullan at openjdk.java.net Mon Jan 11 20:01:59 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 11 Jan 2021 20:01:59 GMT Subject: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test file Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From dcubed at openjdk.java.net Mon Jan 11 21:29:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Jan 2021 21:29:56 GMT Subject: RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn't cause any test failures. @simonis - are you planning to integrate this soon? ------------- PR: https://git.openjdk.java.net/jdk/pull/2035 From simonis at openjdk.java.net Mon Jan 11 21:40:09 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 11 Jan 2021 21:40:09 GMT Subject: Integrated: 8259582: Backout JDK-8237578 until all affected tests have been fixed In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn't cause any test failures. This pull request has now been integrated. Changeset: e9929e2b Author: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/e9929e2b Stats: 182 lines in 5 files changed: 0 ins; 175 del; 7 mod 8259582: Backout JDK-8237578 until all affected tests have been fixed Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2035 From hchao at openjdk.java.net Mon Jan 11 21:47:16 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 11 Jan 2021 21:47:16 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= Message-ID: This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8257766 ------------- Commit messages: - 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Changes: https://git.openjdk.java.net/jdk/pull/2039/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256895 Stats: 108 lines in 6 files changed: 89 ins; 1 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Tue Jan 12 03:39:22 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 12 Jan 2021 03:39:22 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= Message-ID: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. ------------- Commit messages: - 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain Changes: https://git.openjdk.java.net/jdk/pull/2042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259401 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042 From jnimeh at openjdk.java.net Tue Jan 12 16:29:04 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 12 Jan 2021 16:29:04 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 21:41:56 GMT, Hai-May Chao wrote: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 In general it looks pretty good. Just a couple small comments. src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java line 126: > 124: * is set for this extension > 125: * @param incomingNonce The nonce data to be set for the extension. This > 126: * must be a non-null array of at least one byte long and can be upto typo: "upto" -> "up to" src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java line 143: > 141: // RFC 8954, section 2.1: the length of the nonce MUST be at least 1 octet > 142: // and can be up to 32 octets. > 143: if (incomingNonce.length > 0 && incomingNonce.length <=32) { nit: space after the <= to be consistent with style elsewhere src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 118: > 116: tmpExtensions = new ArrayList(); > 117: tmpExtensions.add(nonceExt); > 118: setOcspExtensions(tmpExtensions); It seems like you could collapse 113 - 118 into something like: setOcspExtensions(List.of(new OCSPNonceExtension(DEFAULT_NONCE_BYTES))); At the very least, it looks like you could do away with 113, since you immediately change the value of the tmpExtensions reference on 116. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From xuelei at openjdk.java.net Tue Jan 12 17:19:17 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 12 Jan 2021 17:19:17 GMT Subject: RFR: 8253635: Implement toString() for SSLEngineImpl [v2] In-Reply-To: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> References: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> Message-ID: <-z2k_I5SqRP216ZfGPxnYHMPxdEza0TRwgiqK1eVUOs=.f9d8cb43-83f6-49f5-a7c9-2fa6d3ded120@github.com> > The SSLSocketImpl and SSLEngineImpl implementation does not override the toString() method. The old code did. BTW, I also made a few code clean up in the SSLSocketImpl.java. > > Code clean up, trivial update, no new regression test. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge master - missing a white space - 8253635: Implement toString() for SSLEngineImpl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2019/files - new: https://git.openjdk.java.net/jdk/pull/2019/files/78e12edf..6600ee32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2019&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2019&range=00-01 Stats: 8715 lines in 333 files changed: 5636 ins; 1731 del; 1348 mod Patch: https://git.openjdk.java.net/jdk/pull/2019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2019/head:pull/2019 PR: https://git.openjdk.java.net/jdk/pull/2019 From wetmore at openjdk.java.net Tue Jan 12 19:12:59 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 12 Jan 2021 19:12:59 GMT Subject: RFR: 8253635: Implement toString() for SSLEngineImpl [v2] In-Reply-To: <-z2k_I5SqRP216ZfGPxnYHMPxdEza0TRwgiqK1eVUOs=.f9d8cb43-83f6-49f5-a7c9-2fa6d3ded120@github.com> References: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> <-z2k_I5SqRP216ZfGPxnYHMPxdEza0TRwgiqK1eVUOs=.f9d8cb43-83f6-49f5-a7c9-2fa6d3ded120@github.com> Message-ID: On Tue, 12 Jan 2021 17:19:17 GMT, Xue-Lei Andrew Fan wrote: >> The SSLSocketImpl and SSLEngineImpl implementation does not override the toString() method. The old code did. BTW, I also made a few code clean up in the SSLSocketImpl.java. >> >> Code clean up, trivial update, no new regression test. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge master > - missing a white space > - 8253635: Implement toString() for SSLEngineImpl Marked as reviewed by wetmore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2019 From hchao at openjdk.java.net Tue Jan 12 19:18:18 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 12 Jan 2021 19:18:18 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: References: Message-ID: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: update to use List.of() and typo changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/5ade73d4..26254d59 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Tue Jan 12 19:18:20 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 12 Jan 2021 19:18:20 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:26:11 GMT, Jamil Nimeh wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use List.of() and typo changes > > In general it looks pretty good. Just a couple small comments. Thanks for the review, Jamil. I've updated with all of your comments. > src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java line 126: > >> 124: * is set for this extension >> 125: * @param incomingNonce The nonce data to be set for the extension. This >> 126: * must be a non-null array of at least one byte long and can be upto > > typo: "upto" -> "up to" fixed. > src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java line 143: > >> 141: // RFC 8954, section 2.1: the length of the nonce MUST be at least 1 octet >> 142: // and can be up to 32 octets. >> 143: if (incomingNonce.length > 0 && incomingNonce.length <=32) { > > nit: space after the <= to be consistent with style elsewhere fixed. > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 118: > >> 116: tmpExtensions = new ArrayList(); >> 117: tmpExtensions.add(nonceExt); >> 118: setOcspExtensions(tmpExtensions); > > It seems like you could collapse 113 - 118 into something like: > setOcspExtensions(List.of(new OCSPNonceExtension(DEFAULT_NONCE_BYTES))); > > At the very least, it looks like you could do away with 113, since you immediately change the value of the tmpExtensions reference on 116. collapsing done. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From rhalade at openjdk.java.net Tue Jan 12 20:14:01 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 12 Jan 2021 20:14:01 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> References: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> Message-ID: <0yDlNez6mzzvLOwZ9dUQRsnhSS5xbHec9_Nkl8ZfyDE=.895e6949-a38c-4b75-af50-3cc4bcb3f080@github.com> On Tue, 12 Jan 2021 19:18:18 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > update to use List.of() and typo changes test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java line 50: > 48: public static void main(String[] args) throws Exception { > 49: > 50: System.setProperty("jdk.security.certpath.ocspNonce", "true"); Trying to understand this change - why do we need this change and only in couple of tests? Did these test fail with your change? ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Tue Jan 12 20:48:56 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 12 Jan 2021 20:48:56 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: <0yDlNez6mzzvLOwZ9dUQRsnhSS5xbHec9_Nkl8ZfyDE=.895e6949-a38c-4b75-af50-3cc4bcb3f080@github.com> References: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> <0yDlNez6mzzvLOwZ9dUQRsnhSS5xbHec9_Nkl8ZfyDE=.895e6949-a38c-4b75-af50-3cc4bcb3f080@github.com> Message-ID: On Tue, 12 Jan 2021 20:10:34 GMT, Rajan Halade wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use List.of() and typo changes > > test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java line 50: > >> 48: public static void main(String[] args) throws Exception { >> 49: >> 50: System.setProperty("jdk.security.certpath.ocspNonce", "true"); > > Trying to understand this change - why do we need this change and only in couple of tests? Did these test fail with your change? No, these test did not fail with my changes. These two tests are being changed to set the system property jdk.security.certpath.ocspNonce=true in order to send the nonce as the responders in these tests will take the nonce and return it their responses, so we could test the benefit of having nonce extension set. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From mullan at openjdk.java.net Tue Jan 12 21:58:24 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 12 Jan 2021 21:58:24 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= In-Reply-To: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: On Tue, 12 Jan 2021 03:34:00 GMT, Hai-May Chao wrote: > The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. Changes requested by mullan (Reviewer). src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1404: > 1402: } > 1403: > 1404: private String checkWeakKey(PublicKey key) { Can this method be static? src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1421: > 1419: } > 1420: > 1421: private String checkWeakAlg(String alg) { Can this method be static? src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1483: > 1481: certStr.append("\n").append(tab) > 1482: .append("Signature algorithm: ") > 1483: .append(checkWeakAlg(sigalg)) If the cert is trusted, I don't think we should print a warning if the signature algorithm is weak. Otherwise this will generate false warnings for SHA-1 roots which are not an issue. You should check the key size though. And you can still print the signature algorithm. You may need to move line 1489-1490 before this to first determine if the cert is trusted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From mbalao at openjdk.java.net Tue Jan 12 21:59:06 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 12 Jan 2021 21:59:06 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Mon, 11 Jan 2021 19:52:16 GMT, Valerie Peng wrote: > For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From rhalade at openjdk.java.net Tue Jan 12 22:30:55 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 12 Jan 2021 22:30:55 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= In-Reply-To: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: On Tue, 12 Jan 2021 03:34:00 GMT, Hai-May Chao wrote: > The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java line 52: > 50: public static void main(String[] args) throws Exception { > 51: > 52: // root certificate using SHA1withRSA and 1024-bit key It will be helpful to have these comments logged as debug messages with System.out ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From mbalao at openjdk.java.net Tue Jan 12 23:22:59 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 12 Jan 2021 23:22:59 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3] In-Reply-To: References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Fri, 8 Jan 2021 20:08:57 GMT, Valerie Peng wrote: >> Because a C_EncryptUpdate call that returns with an error here [1] implies that a session (with an active operation) is returned to the Session Manager here [2] [3]. For decryption, where we have proper padding on the Java side while doing an update, the test exercises the doFinal path. Decryption/Encryption is anecdotal here: what the test wants is coverage on both update and doFinal paths. >> >> -- >> [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L584 >> [2] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L631 >> [3] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L423 > > I understand that the intention/design is to trigger the error condition on various code paths causing the active session to be returned to pool and verify if this issue is fixed or not. What I don't get is that why AES/ECB/NoPadding cipher encrypting a byte[1] w/ an update (where more input could still be given) would trigger an error. The stack trace for the encryption update call (which is the first test, the session should be freshly allocated and not a reused one with active state) is below: > > java.security.ProviderException: update() failed > at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:632) > at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:529) > at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:517) > at java.base/javax.crypto.Cipher.update(Cipher.java:1832) > at CancelMultipart$LeakByteArray.doOperation(CancelMultipart.java:125) > at CancelMultipart$SessionLeaker.leakAndTry(CancelMultipart.java:63) > at CancelMultipart.executeTest(CancelMultipart.java:158) > at CancelMultipart.main(CancelMultipart.java:140) > at PKCS11Test.premain(PKCS11Test.java:171) > at PKCS11Test.testNSS(PKCS11Test.java:568) > at PKCS11Test.main(PKCS11Test.java:207) > at CancelMultipart.main(CancelMultipart.java:131) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE > at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method) > at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:584) > ... 17 more The update fails because the native mechanism (CKM_AES_ECB) has no padding and OpenJDK does not buffer data in the Java side for encryption [1] (this is a bug that I'll address soon). As a result, there is a PKCS#11 call with an invalid length and we get the error that ends up returning the session to the Session Manager. I just realized that when we fix the previous padding-bug, this test path won't work anymore. CKR_BUFFER_TOO_SMALL errors on updates do not lead to a reset call in the OpenJDK side (contrary to doFinal), so they wouldn't be useful for the test. I'll investigate if there is a way to trigger the path. Otherwise we should keep the doFinal path only. I'd still force a reset if there is an error other than CKR_BUFFER_TOO_SMALL in the update. -- [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L583 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Tue Jan 12 23:47:57 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 12 Jan 2021 23:47:57 GMT Subject: Integrated: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access permissions so the SunPKCS11 provider can create instances of SunJCE classes when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 This pull request has now been integrated. Changeset: 4be21734 Author: Martin Balao URL: https://git.openjdk.java.net/jdk/commit/4be21734 Stats: 122 lines in 4 files changed: 115 ins; 0 del; 7 mod 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Reviewed-by: valeriep, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1961 From valeriep at openjdk.java.net Wed Jan 13 00:32:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Jan 2021 00:32:55 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 20:29:08 GMT, Valerie Peng wrote: > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. > > Thanks, > Valerie Ping~ Anyone has time to looks at this? I will sync with the master since it's been a while... The changes are straight forward, just add support for PKCS#1 encoded RSA keys. There is already existing code parsing the PKCS#1 encoding underneath the PKCS#8 layer. This is more like code-refactoring. Comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Wed Jan 13 00:48:22 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Jan 2021 00:48:22 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v2] In-Reply-To: References: Message-ID: <4JJBwPfHMREqaX2gOac5mJCc1zSDg_2xYRihZU7d1es=.e8499664-e8ff-4752-84e9-33fc85b5ac9e@github.com> > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. > > Thanks, > Valerie Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8023980 - 8023980: JCE doesn't provide any class to handle RSA private key in PKCS #1 Enhanced RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1787/files - new: https://git.openjdk.java.net/jdk/pull/1787/files/eed143e9..a4cddf47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=00-01 Stats: 55257 lines in 1773 files changed: 25715 ins; 14911 del; 14631 mod Patch: https://git.openjdk.java.net/jdk/pull/1787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1787/head:pull/1787 PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Wed Jan 13 00:54:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Jan 2021 00:54:16 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: Message-ID: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update copyright year from 2020 to 2021. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1787/files - new: https://git.openjdk.java.net/jdk/pull/1787/files/a4cddf47..b48afddd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=01-02 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1787/head:pull/1787 PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Wed Jan 13 00:55:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Jan 2021 00:55:55 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Tue, 12 Jan 2021 21:38:32 GMT, Martin Balao wrote: > > > > For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. > > Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. Wonderful, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Wed Jan 13 00:59:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Jan 2021 00:59:55 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: <-U8jAG-h-jY8A4fC0qLCt8VK3hKfblzH-MHp-k7cppA=.f604d5fe-a835-49a2-aec9-d9283275603e@github.com> Message-ID: <9GYqxzH-YJDTOakTpUv85VZmAmLKS_J7ZnNJhiIs9rk=.289e67b2-077b-469e-b0d7-533db1b36e62@github.com> On Thu, 7 Jan 2021 18:50:05 GMT, Claes Redestad wrote: >> Removing the UUID clone cache and running the microbenchmark along with the changes in #1933: >> >> Benchmark (size) Mode Cnt Score Error Units >> UUIDBench.fromType3Bytes 20000 thrpt 12 2.182 ? 0.090 ops/us >> UUIDBench.fromType3Bytes:?gc.alloc.rate 20000 thrpt 12 439.020 ? 18.241 MB/sec >> UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 264.022 ? 0.003 B/op >> >> The goal now is if to simplify the digest code and compare alternatives. > > I've run various tests and concluded that the `VarHandle`ized code is matching or improving upon the `Unsafe`-riddled code in `ByteArrayAccess`. I then went ahead and consolidated to use similar code pattern in `ByteArrayAccess` for consistency, which amounts to a good cleanup. > > With MD5 intrinsics disabled, I get this baseline: > > Benchmark (size) Mode Cnt Score Error Units > UUIDBench.fromType3Bytes 20000 thrpt 12 1.245 ? 0.077 ops/us > UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 488.042 ? 0.004 B/op > > With the current patch here (not including #1933): > Benchmark (size) Mode Cnt Score Error Units > UUIDBench.fromType3Bytes 20000 thrpt 12 1.431 ? 0.106 ops/us > UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 408.035 ? 0.006 B/op > > If I isolate the `ByteArrayAccess` changes I'm getting performance neutral or slightly better numbers compared to baseline for these tests: > > Benchmark (size) Mode Cnt Score Error Units > UUIDBench.fromType3Bytes 20000 thrpt 12 1.317 ? 0.092 ops/us > UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 488.042 ? 0.004 B/op Thanks for the performance enhancement, I will take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From xuelei at openjdk.java.net Wed Jan 13 01:14:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 13 Jan 2021 01:14:57 GMT Subject: Integrated: 8253635: Implement toString() for SSLEngineImpl In-Reply-To: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> References: <822qArp7ib6Ad3eRUlMvyMUjL461kBZuhM1az9pDkBM=.9a645550-a3df-48a4-b84b-428b983797f1@github.com> Message-ID: On Mon, 11 Jan 2021 04:57:19 GMT, Xue-Lei Andrew Fan wrote: > The SSLSocketImpl and SSLEngineImpl implementation does not override the toString() method. The old code did. BTW, I also made a few code clean up in the SSLSocketImpl.java. > > Code clean up, trivial update, no new regression test. This pull request has now been integrated. Changeset: 65bed647 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/65bed647 Stats: 42 lines in 2 files changed: 18 ins; 12 del; 12 mod 8253635: Implement toString() for SSLEngineImpl Reviewed-by: coffeys, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/2019 From hchao at openjdk.java.net Wed Jan 13 01:21:14 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 01:21:14 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> > The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: No warning for trusted cert's SHA1, and added debug output to test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2042/files - new: https://git.openjdk.java.net/jdk/pull/2042/files/eb4f93eb..5a3e184a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=00-01 Stats: 39 lines in 2 files changed: 25 ins; 8 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042 From hchao at openjdk.java.net Wed Jan 13 01:21:16 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 01:21:16 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: On Tue, 12 Jan 2021 20:57:41 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> No warning for trusted cert's SHA1, and added debug output to test > > Changes requested by mullan (Reviewer). Thanks for your review, Sean and Rajan. I've updated the webrev with your comments. > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1404: > >> 1402: } >> 1403: >> 1404: private String checkWeakKey(PublicKey key) { > > Can this method be static? static added. > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1421: > >> 1419: } >> 1420: >> 1421: private String checkWeakAlg(String alg) { > > Can this method be static? static added. > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1483: > >> 1481: certStr.append("\n").append(tab) >> 1482: .append("Signature algorithm: ") >> 1483: .append(checkWeakAlg(sigalg)) > > If the cert is trusted, I don't think we should print a warning if the signature algorithm is weak. Otherwise this will generate false warnings for SHA-1 roots which are not an issue. You should check the key size though. And you can still print the signature algorithm. You may need to move line 1489-1490 before this to first determine if the cert is trusted. Fixed to not check the signature algorithm for a trusted cert, and updated the test accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From hchao at openjdk.java.net Wed Jan 13 01:21:17 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 01:21:17 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: On Tue, 12 Jan 2021 22:22:55 GMT, Rajan Halade wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> No warning for trusted cert's SHA1, and added debug output to test > > test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java line 52: > >> 50: public static void main(String[] args) throws Exception { >> 51: >> 52: // root certificate using SHA1withRSA and 1024-bit key > > It will be helpful to have these comments logged as debug messages with System.out comment messages added. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From cverghese at openjdk.java.net Wed Jan 13 12:53:12 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 13 Jan 2021 12:53:12 GMT Subject: RFR: 8259662: SocketException should be passed through Message-ID: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake ------------- Commit messages: - 8259662: SocketException should be passed through Changes: https://git.openjdk.java.net/jdk/pull/2057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259662 Stats: 488 lines in 7 files changed: 479 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From dfuchs at openjdk.java.net Wed Jan 13 13:16:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 13 Jan 2021 13:16:07 GMT Subject: RFR: 8259662: SocketException should be passed through In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 13 Jan 2021 06:19:18 GMT, Clive Verghese wrote: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake The changes to the HttpClient test look reasonable to me. I'll let the security libs experts comment on the rest of this change however. best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From weijun at openjdk.java.net Wed Jan 13 15:23:06 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 13 Jan 2021 15:23:06 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> Message-ID: On Wed, 13 Jan 2021 01:21:14 GMT, Hai-May Chao wrote: >> The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > No warning for trusted cert's SHA1, and added debug output to test Marked as reviewed by weijun (Reviewer). src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1484: > 1482: // If the cert is trusted, only check its key size, but not its > 1483: // signature algorithm. This is because warning should not be > 1484: // generated for SHA-1 roots which are not an issue. In my opinion, the reason we don't checked the signature is that we trust its origin anyway and we don't verify the signature at all (do we?). On the other hand, since its key is used to sign other certs, we need to make sure the key size is big enough so that no one else is able to recover the key and use it to sign other certs. src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1491: > 1489: .append(checkWeakKey(key)); > 1490: > 1491: certStr.append("\n").append(tab).append("["); It's a little strange to leave the other half of the bracket (`certStr.append("]");` on line 1568) outside the if-else block. Can you please move it inside? Of course you will have to duplicate them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From weijun at openjdk.java.net Wed Jan 13 17:10:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 13 Jan 2021 17:10:08 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: On Wed, 13 Jan 2021 00:54:16 GMT, Valerie Peng wrote: >> Can someone help review this? >> >> This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year from 2020 to 2021. Marked as reviewed by weijun (Reviewer). src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 47: > 45: * For public keys: > 46: * . PublicKey with an X.509 encoding > 47: * . RSA PublicKey with an PKCS#1 encoding The line above has not mentioned "RSA". Maybe better to be consistent. Same as for private key. src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 344: > 342: if (keySpec instanceof PKCS8EncodedKeySpec) { > 343: return RSAPrivateCrtKeyImpl.newKey(type, "PKCS#8", > 344: ((PKCS8EncodedKeySpec)keySpec).getEncoded()); Will you clean up the `getEncoded()` output or shall I? src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 101: > 99: return new RSAPrivateKeyImpl(key.type, key.keyParams, > 100: key.getModulus(), key.getPrivateExponent()); > 101: } else return key; Create a one-line block for else inside "{" and "}". test/jdk/sun/security/rsa/TestKeyFactory.java line 159: > 157: throw new Exception("Encodings not equal"); > 158: } > 159: } Can we combine the 2 blocks above into one? That is to say, when key1 and key2 have the same format, we check the equality of both getEncoded() and themselves. Same for the P11 test. test/jdk/sun/security/rsa/TestKeyFactory.java line 89: > 87: static { > 88: byte[] encodedPriv = Base64.getDecoder().decode(PKCS1_PRIV_STR); > 89: CUSTOM_PRIV = new PrivateKey() { How about just P1_PRIV? ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From rhalade at openjdk.java.net Wed Jan 13 18:31:02 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 13 Jan 2021 18:31:02 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> Message-ID: On Wed, 13 Jan 2021 01:21:14 GMT, Hai-May Chao wrote: >> The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > No warning for trusted cert's SHA1, and added debug output to test Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From rhalade at openjdk.java.net Wed Jan 13 18:49:04 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 13 Jan 2021 18:49:04 GMT Subject: RFR: 8259662: SocketException should be passed through In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 13 Jan 2021 06:19:18 GMT, Clive Verghese wrote: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Changes requested by rhalade (Reviewer). test/jdk/sun/security/ssl/SSLContextImpl/ShouldThrowSSLExceptionWhenPeerClosesSocket.java line 32: > 30: > 31: /* > 32: * @test Suggestion: * @test * @bug 8259662 8259516 ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From weijun at openjdk.java.net Wed Jan 13 19:01:04 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 13 Jan 2021 19:01:04 GMT Subject: [jdk16] Withdrawn: 8258915: More temporary buffer cleanup In-Reply-To: References: Message-ID: <7iGGBHJcXunbXZkGjMVyNzsYFr6Dwco4i5OzeBod3eU=.92c96c1d-2910-4c4c-865d-962d4bb5103a@github.com> On Fri, 8 Jan 2021 19:08:34 GMT, Weijun Wang wrote: > More temporary byte array, char array, keyspec cleanup around keys and passwords. > > No new regression test. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk16/pull/98 From mullan at openjdk.java.net Wed Jan 13 20:29:05 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 13 Jan 2021 20:29:05 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> Message-ID: <6LlY5TfMeHg0VFVV6yu6dX8wRFz6JJ6pi_tkBB4XI7o=.6ee3643b-3250-42ed-870f-355f25a78628@github.com> On Wed, 13 Jan 2021 01:21:14 GMT, Hai-May Chao wrote: >> The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > No warning for trusted cert's SHA1, and added debug output to test Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From mullan at openjdk.java.net Wed Jan 13 20:29:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 13 Jan 2021 20:29:09 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> Message-ID: <_1Yn62GWqV1kv5BvV05xqRK3WNt_Lnl_UzJjR7pfpr0=.e9c93f3c-6c6b-4d43-8f17-13e7a6ce890e@github.com> On Wed, 13 Jan 2021 15:13:52 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> No warning for trusted cert's SHA1, and added debug output to test > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1484: > >> 1482: // If the cert is trusted, only check its key size, but not its >> 1483: // signature algorithm. This is because warning should not be >> 1484: // generated for SHA-1 roots which are not an issue. > > SHA-1 is just a glitch in the long history at this very moment, and thus I think it's inappropriate to mention it in the source code. In my opinion, the general reason we don't check the signature is that we trust its origin anyway and we don't verify the signature at all (do we?). On the other hand, since its key is used to sign other certs, we need to make sure the key size is big enough so that no one else is able to recover the key and use it to sign other certs. Yes, I would remove the 2nd sentence that starts with "This is ...". There are plenty of references on the Internet which explain this, so no need to add much detail. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From weijun at openjdk.java.net Wed Jan 13 21:38:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 13 Jan 2021 21:38:21 GMT Subject: RFR: 8258915: Temporary buffer cleanup Message-ID: Clean up temporary byte array, char array, and keyspec around keys and passwords. No new regression test. ------------- Commit messages: - 8258915: More temporary buffer cleanup Changes: https://git.openjdk.java.net/jdk/pull/2070/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258915 Stats: 1571 lines in 51 files changed: 731 ins; 428 del; 412 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From hchao at openjdk.java.net Wed Jan 13 22:15:26 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 22:15:26 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v2] In-Reply-To: <_1Yn62GWqV1kv5BvV05xqRK3WNt_Lnl_UzJjR7pfpr0=.e9c93f3c-6c6b-4d43-8f17-13e7a6ce890e@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> <_1Yn62GWqV1kv5BvV05xqRK3WNt_Lnl_UzJjR7pfpr0=.e9c93f3c-6c6b-4d43-8f17-13e7a6ce890e@github.com> Message-ID: On Wed, 13 Jan 2021 20:25:53 GMT, Sean Mullan wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1484: >> >>> 1482: // If the cert is trusted, only check its key size, but not its >>> 1483: // signature algorithm. This is because warning should not be >>> 1484: // generated for SHA-1 roots which are not an issue. >> >> SHA-1 is just a glitch in the long history at this very moment, and thus I think it's inappropriate to mention it in the source code. In my opinion, the general reason we don't check the signature is that we trust its origin anyway and we don't verify the signature at all (do we?). On the other hand, since its key is used to sign other certs, we need to make sure the key size is big enough so that no one else is able to recover the key and use it to sign other certs. > > Yes, I would remove the 2nd sentence that starts with "This is ...". There are plenty of references on the Internet which explain this, so no need to add much detail. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From hchao at openjdk.java.net Wed Jan 13 22:15:25 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 22:15:25 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= [v3] In-Reply-To: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: <03ezEtdHnYv5C2jyc4OcT3sdxPbzVxoiGjtTRIk0Zp0=.f3f02b95-d325-4138-815a-4f3ff8f6d18e@github.com> > The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: remove comment about checking sigalg for trusted cert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2042/files - new: https://git.openjdk.java.net/jdk/pull/2042/files/5a3e184a..88d94dfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042 From hchao at openjdk.java.net Wed Jan 13 22:20:08 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 22:20:08 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2lnbmVy4oCZcw==?= cert chain [v2] In-Reply-To: <6LlY5TfMeHg0VFVV6yu6dX8wRFz6JJ6pi_tkBB4XI7o=.6ee3643b-3250-42ed-870f-355f25a78628@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> <6LlY5TfMeHg0VFVV6yu6dX8wRFz6JJ6pi_tkBB4XI7o=.6ee3643b-3250-42ed-870f-355f25a78628@github.com> Message-ID: On Wed, 13 Jan 2021 20:26:17 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> No warning for trusted cert's SHA1, and added debug output to test > > Marked as reviewed by mullan (Reviewer). Thanks for the review, Max. The comment about trusted cert's sigalg checking has been removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From hchao at openjdk.java.net Wed Jan 13 22:20:09 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 22:20:09 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2lnbmVy4oCZcw==?= cert chain [v2] In-Reply-To: References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> <8-NRiQejpvReDf0xHmvmlQxjmKu1g_ccnGtptDUlv9k=.4c9799f4-5bad-4433-9675-34727ea1f710@github.com> Message-ID: On Wed, 13 Jan 2021 15:17:22 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> No warning for trusted cert's SHA1, and added debug output to test > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1491: > >> 1489: .append(checkWeakKey(key)); >> 1490: >> 1491: certStr.append("\n").append(tab).append("["); > > It's a little strange to leave the other half of the bracket (`certStr.append("]");` on line 1568) outside the if-else block. Can you please move it inside? Of course you will have to duplicate them. I'd prefer to keep it as is instead of duplicating the code in several places inside if block and else block. ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From rhalade at openjdk.java.net Wed Jan 13 22:22:01 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 13 Jan 2021 22:22:01 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:32:07 GMT, Weijun Wang wrote: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. please add noreg label to the JBS bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From hchao at openjdk.java.net Wed Jan 13 22:36:05 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 13 Jan 2021 22:36:05 GMT Subject: Integrated: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2lnbmVy4oCZcw==?= cert chain In-Reply-To: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> References: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> Message-ID: On Tue, 12 Jan 2021 03:34:00 GMT, Hai-May Chao wrote: > The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. This pull request has now been integrated. Changeset: c7e2174b Author: Hai-May Chao Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/c7e2174b Stats: 143 lines in 2 files changed: 140 ins; 0 del; 3 mod 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain Reviewed-by: mullan, weijun, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2042 From cverghese at openjdk.java.net Wed Jan 13 23:39:24 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 13 Jan 2021 23:39:24 GMT Subject: RFR: 8259662: SocketException should be passed through [v2] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 13 Jan 2021 18:41:26 GMT, Rajan Halade wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bugids and use server port passed as a parameter > > test/jdk/sun/security/ssl/SSLContextImpl/ShouldThrowSSLExceptionWhenPeerClosesSocket.java line 32: > >> 30: >> 31: /* >> 32: * @test > > Suggestion: > > * @test > * @bug 8259662 8259516 Thank you for the feedback. I have updated the change to include the bug ids. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Wed Jan 13 23:39:23 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 13 Jan 2021 23:39:23 GMT Subject: RFR: 8259662: SocketException should be passed through [v2] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: <1R1rhrDWvm5jAoJUf9CqivIDf5BfP7csOBJhGfxHu1g=.b3517dc8-c0b6-4d7d-a739-5e3326469a3a@github.com> > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Fix bugids and use server port passed as a parameter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/00667985..da98249d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From jnimeh at openjdk.java.net Thu Jan 14 02:22:01 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 02:22:01 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> References: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> Message-ID: On Tue, 12 Jan 2021 19:18:18 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > update to use List.of() and typo changes Looks good. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2039 From weijun at openjdk.java.net Thu Jan 14 02:55:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Jan 2021 02:55:02 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: Message-ID: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> On Wed, 13 Jan 2021 22:19:00 GMT, Rajan Halade wrote: > please add noreg label to the JBS bug. Added. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From jnimeh at openjdk.java.net Thu Jan 14 06:38:15 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 06:38:15 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh Message-ID: This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) - master/slave in KRB5 -> primary/replica - blacklist in other files -> deny list - whitelist -> allow list Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. ------------- Commit messages: - Merge main branch - 8253866: Security Libs Terminology Refresh Changes: https://git.openjdk.java.net/jdk/pull/2074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253866 Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074 From erikj at openjdk.java.net Thu Jan 14 13:48:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Jan 2021 13:48:04 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074 From ljiang at openjdk.java.net Thu Jan 14 14:05:11 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:05:11 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Message-ID: This is the changes for JDK 16 msg drop 10. ------------- Commit messages: - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Changes: https://git.openjdk.java.net/jdk16/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259732 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Thu Jan 14 14:13:02 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:13:02 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Thu Jan 14 14:27:25 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:27:25 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: > This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into msgdrop - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/230117b4..d72f444a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00-01 Stats: 718 lines in 32 files changed: 616 ins; 38 del; 64 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From mullan at openjdk.java.net Thu Jan 14 15:08:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Jan 2021 15:08:09 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status =?UTF-8?B?UHJvdG9jb2zigKY=?= [v2] In-Reply-To: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> References: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> Message-ID: On Tue, 12 Jan 2021 19:18:18 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > update to use List.of() and typo changes Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 88: > 86: boolean ocspNonce; > 87: } > 88: private RevocationProperties rp; I think this field could be `final`. src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 107: > 105: > 106: private void setDefaultNonce() { > 107: byte[] nonce = null; This variable looks like it is not used and can be removed. src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 109: > 107: byte[] nonce = null; > 108: > 109: // Set the nonce by default in OCSP request extension when the sytem property Typo: s/sytem/system/ src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 113: > 111: if (rp.ocspNonce) { > 112: try { > 113: setOcspExtensions(List.of(new OCSPNonceExtension(DEFAULT_NONCE_BYTES))); I don't think we should use the `PKIXRevocationChecker.setOcspExtensions()` API to add an OCSP Nonce extension. That API is intended to be called by applications. I think the Nonce extension should be set by the implementation only and not exposed via the standard API. Also, a nonce should be unique for each OCSP request, but setting it here means that it could re-use the same nonce for different OCSP requests. I think a better place to create/add the OCSPExtension is in the `checkOCSP` method, and the extension should be created each time that method is called (if the system property is enabled), so a new nonce is created for each OCSP request. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From weijun at openjdk.java.net Thu Jan 14 15:30:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Jan 2021 15:30:02 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Code change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074 From ljiang at openjdk.java.net Thu Jan 14 15:38:09 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 15:38:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) > > Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review. @naotoj Would you have time to take a look at this change? Very appreciated! ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From mullan at openjdk.java.net Thu Jan 14 15:51:04 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Jan 2021 15:51:04 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by mullan (Reviewer). src/java.base/share/conf/security/java.security line 454: > 452: # configuration, but with smaller max_retries and timeout values. > 453: # max_retries and timeout are optional numerical parameters (default 1 and > 454: # 5000, which means once and 5 seconds). Please notes that if any of the Typo: s/notes/note/ src/java.base/share/conf/security/java.security line 455: > 453: # max_retries and timeout are optional numerical parameters (default 1 and > 454: # 5000, which means once and 5 seconds). Please notes that if any of the > 455: # values defined here is more than what is defined in krb5.conf, it will be Typo: s/is more/are more/ ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:15 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:15 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Minor grammatical fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2074/files - new: https://git.openjdk.java.net/jdk/pull/2074/files/9d44a9e1..45492f55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:18 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:18 GMT Subject: Integrated: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. This pull request has now been integrated. Changeset: 8554fe6e Author: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/8554fe6e Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod 8253866: Security Libs Terminology Refresh Reviewed-by: erikj, weijun, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:17 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:17 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: <0T5q-e3tXNFq1QKgKV3YvjgFIhNZG6QpmhnG2_Y3JrA=.2a06de53-02db-4b9b-b58c-5f8220c83a71@github.com> On Thu, 14 Jan 2021 15:45:43 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor grammatical fixes > > src/java.base/share/conf/security/java.security line 455: > >> 453: # max_retries and timeout are optional numerical parameters (default 1 and >> 454: # 5000, which means once and 5 seconds). Please notes that if any of the >> 455: # values defined here is more than what is defined in krb5.conf, it will be > > Typo: s/is more/are more/ Done. Good catch. > src/java.base/share/conf/security/java.security line 454: > >> 452: # configuration, but with smaller max_retries and timeout values. >> 453: # max_retries and timeout are optional numerical parameters (default 1 and >> 454: # 5000, which means once and 5 seconds). Please notes that if any of the > > Typo: s/notes/note/ fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From naoto at openjdk.java.net Thu Jan 14 17:22:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Jan 2021 17:22:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into msgdrop > - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: > 516: doclet.footer_specified=\ > 517: The -footer option is no longer supported and will be ignored.\n\ > 518: It may be removed in a future release. I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From valeriep at openjdk.java.net Thu Jan 14 20:02:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 20:02:07 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: <1bvht1qLz1oQGOSFX8M_xOg1TPVkwgG42ZKRWDe_k2Y=.ecae1409-e8fe-4058-b570-f2dc77968e9d@github.com> On Wed, 13 Jan 2021 16:11:02 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 47: > >> 45: * For public keys: >> 46: * . PublicKey with an X.509 encoding >> 47: * . RSA PublicKey with an PKCS#1 encoding > > The line above has not mentioned "RSA". Maybe better to be consistent. Same as for private key. Sure~ ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Thu Jan 14 20:08:08 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 20:08:08 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: <4Dsf85C-v85cMvsPUcNyzxFUK4t2ImMcP9nJxHiAU8E=.ab8664b3-eda6-49ff-ae20-9d4bc7f746ff@github.com> On Wed, 13 Jan 2021 16:23:17 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 344: > >> 342: if (keySpec instanceof PKCS8EncodedKeySpec) { >> 343: return RSAPrivateCrtKeyImpl.newKey(type, "PKCS#8", >> 344: ((PKCS8EncodedKeySpec)keySpec).getEncoded()); > > Will you clean up the `getEncoded()` output or shall I? Maybe it's better that you do it this time? Just so that the backport won't miss it. > src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 101: > >> 99: return new RSAPrivateKeyImpl(key.type, key.keyParams, >> 100: key.getModulus(), key.getPrivateExponent()); >> 101: } else return key; > > Create a one-line block for else inside "{" and "}". Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Thu Jan 14 20:15:06 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 20:15:06 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: On Wed, 13 Jan 2021 17:02:50 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > test/jdk/sun/security/rsa/TestKeyFactory.java line 89: > >> 87: static { >> 88: byte[] encodedPriv = Base64.getDecoder().decode(PKCS1_PRIV_STR); >> 89: CUSTOM_PRIV = new PrivateKey() { > > How about just P1_PRIV? Either one is fine. I can change to P1_PRIV. ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Thu Jan 14 20:33:03 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 20:33:03 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3] In-Reply-To: References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Tue, 12 Jan 2021 23:20:11 GMT, Martin Balao wrote: >> I understand that the intention/design is to trigger the error condition on various code paths causing the active session to be returned to pool and verify if this issue is fixed or not. What I don't get is that why AES/ECB/NoPadding cipher encrypting a byte[1] w/ an update (where more input could still be given) would trigger an error. The stack trace for the encryption update call (which is the first test, the session should be freshly allocated and not a reused one with active state) is below: >> >> java.security.ProviderException: update() failed >> at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:632) >> at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:529) >> at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:517) >> at java.base/javax.crypto.Cipher.update(Cipher.java:1832) >> at CancelMultipart$LeakByteArray.doOperation(CancelMultipart.java:125) >> at CancelMultipart$SessionLeaker.leakAndTry(CancelMultipart.java:63) >> at CancelMultipart.executeTest(CancelMultipart.java:158) >> at CancelMultipart.main(CancelMultipart.java:140) >> at PKCS11Test.premain(PKCS11Test.java:171) >> at PKCS11Test.testNSS(PKCS11Test.java:568) >> at PKCS11Test.main(PKCS11Test.java:207) >> at CancelMultipart.main(CancelMultipart.java:131) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE >> at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method) >> at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:584) >> ... 17 more > > The update fails because the native mechanism (CKM_AES_ECB) has no padding and OpenJDK does not buffer data in the Java side for encryption [1] (this is a bug that I'll address soon). As a result, there is a PKCS#11 call with an invalid length and we get the error that ends up returning the session to the Session Manager. I just realized that when we fix the previous padding-bug, this test path won't work anymore. CKR_BUFFER_TOO_SMALL errors on updates do not lead to a reset call in the OpenJDK side (contrary to doFinal), so they wouldn't be useful for the test. I'll investigate if there is a way to trigger the path. Otherwise we should keep the doFinal path only. I'd still force a reset if there is an error other than CKR_BUFFER_TOO_SMALL in the update. > > -- > [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L583 It's an update call, isn't padding occur when doFinal() is called for encryption? In any case, it's best for the test case to not have this bug dependency. I am ok if you can only test doFinal path only. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Thu Jan 14 21:06:05 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 21:06:05 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: On Wed, 13 Jan 2021 17:00:36 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > test/jdk/sun/security/rsa/TestKeyFactory.java line 159: > >> 157: throw new Exception("Encodings not equal"); >> 158: } >> 159: } > > Can we combine the 2 blocks above into one? That is to say, when key1 and key2 have the same format, we check the equality of both getEncoded() and themselves. Same for the P11 test. Sure, will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Thu Jan 14 23:18:18 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Jan 2021 23:18:18 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v4] In-Reply-To: References: Message-ID: > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update to address review comments from Weijun ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1787/files - new: https://git.openjdk.java.net/jdk/pull/1787/files/b48afddd..6f498af0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=02-03 Stats: 26 lines in 4 files changed: 3 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1787/head:pull/1787 PR: https://git.openjdk.java.net/jdk/pull/1787 From mstjohns at comcast.net Thu Jan 14 23:24:15 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 14 Jan 2021 18:24:15 -0500 Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: <67d476aa-577c-23f7-b25b-9f5e6391f799@comcast.net> Sorry - I'm coming to this a bit late. Any chance of adding the logic for generatePublic() from a PKCS8 RSA private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes the modulus and publicExponent - so it should be a pretty straight forward add to generate a public key. PKCS11 2.40 started requiring that the publicExponent be stored with the private key to allow for the public key to be regenerated from a private key object.?? Going forward,? it might be a good idea to modify the RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. Mike On 1/14/2021 4:06 PM, Valerie Peng wrote: > On Wed, 13 Jan 2021 17:00:36 GMT, Weijun Wang wrote: > >>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Update copyright year from 2020 to 2021. >> test/jdk/sun/security/rsa/TestKeyFactory.java line 159: >> >>> 157: throw new Exception("Encodings not equal"); >>> 158: } >>> 159: } >> Can we combine the 2 blocks above into one? That is to say, when key1 and key2 have the same format, we check the equality of both getEncoded() and themselves. Same for the P11 test. > Sure, will do. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Fri Jan 15 01:48:03 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Jan 2021 01:48:03 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> Message-ID: <3QzXUD_r9pymbEqZPGqJ8HSk7SWfvv_ID5lPfU2ONnk=.ac6a3adc-1e14-4750-a87f-139934081cc6@github.com> On Wed, 13 Jan 2021 17:07:20 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > Marked as reviewed by weijun (Reviewer). > > > _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at openjdk.java.net):_ > > Sorry - I'm coming to this a bit late. > > Any chance of adding the logic for generatePublic() from a PKCS8 RSA > private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes > the modulus and publicExponent - so it should be a pretty straight > forward add to generate a public key. > > PKCS11 2.40 started requiring that the publicExponent be stored with the > private key to allow for the public key to be regenerated from a private > key object.?? Going forward,? it might be a good idea to modify the > RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. > > Mike You are correct that for RSA private CRT keys the necessary values are there for figuring out its corresponding public keys. This change is about adding support for PKCS#1 encoded RSA keys and be able to translate them into PKCS#8 encoded keys and/or extract various key specs out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign provider, you can call its getPublicExponent() method and use that to create a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd party impl which does not return the public exponent value somehow, then you can translate it using the RSA key factory impl from SunRsaSign provider and then repeat the fore-mentioned step. Will this address your need? If not, could you elaborate the usage that you have in mind? Not sure if you are suggesting a new KeyFactory.generatePublic() method which take a PrivateKey or else. ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From ljiang at openjdk.java.net Fri Jan 15 02:02:11 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Fri, 15 Jan 2021 02:02:11 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato wrote: >> Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into msgdrop >> - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: > >> 516: doclet.footer_specified=\ >> 517: The -footer option is no longer supported and will be ignored.\n\ >> 518: It may be removed in a future release. > > I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? doclet.help.systemProperties.body=\ The {0} page lists references to system properties. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From mbaesken at openjdk.java.net Fri Jan 15 11:29:16 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 15 Jan 2021 11:29:16 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r Message-ID: We have a couple of calls to getpwuid_r in the codebase, like g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). This triggers also Sonar warnings like : https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? ------------- Commit messages: - JDK-8259786 Changes: https://git.openjdk.java.net/jdk/pull/2098/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259786 Stats: 13 lines in 4 files changed: 0 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2098/head:pull/2098 PR: https://git.openjdk.java.net/jdk/pull/2098 From hseigel at openjdk.java.net Fri Jan 15 13:57:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 15 Jan 2021 13:57:02 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 11:24:49 GMT, Matthias Baesken wrote: > We have a couple of calls to getpwuid_r in the codebase, like > g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); > > Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). > > This triggers also Sonar warnings like : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG > > > Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? Hi Matthias, These changes look good, but could you hold off on making these changes until pull request https://github.com/openjdk/jdk/pull/2037, which consolidates the perfMemory_{aix,bsd,linux].cpp files into one perfMemory_posix.cpp file, has been integrated? Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/2098 From mbaesken at openjdk.java.net Fri Jan 15 14:04:02 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 15 Jan 2021 14:04:02 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 13:54:15 GMT, Harold Seigel wrote: >> We have a couple of calls to getpwuid_r in the codebase, like >> g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); >> >> Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). >> >> This triggers also Sonar warnings like : >> https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG >> >> >> Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? > > Hi Matthias, > These changes look good, but could you hold off on making these changes until pull request https://github.com/openjdk/jdk/pull/2037, which consolidates the perfMemory_{aix,bsd,linux].cpp files into one perfMemory_posix.cpp file, has been integrated? > Thanks, Harold > Hi Matthias, > These changes look good, but could you hold off on making these changes until pull request #2037, which consolidates the perfMemory_{aix,bsd,linux].cpp files into one perfMemory_posix.cpp file, has been integrated? > Thanks, Harold Hi Harold, thanks for reviewing . I will wait until your change is in . Good to see that you already started consolidating the perfmem code into posix, my question >Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code >(currently we have it for bsd, linux, aix but the functions look very similar ? was pointing into the same direction but looks like you already started the effort ! Thanks, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/2098 From alanb at openjdk.java.net Fri Jan 15 15:01:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Jan 2021 15:01:09 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote: >> Marked as reviewed by prr (Reviewer). > > This PR is not stale; it's just still waiting for input from @AlanBateman. @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From hchao at openjdk.java.net Fri Jan 15 17:31:22 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 15 Jan 2021 17:31:22 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v3] In-Reply-To: References: Message-ID: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Revert changes to UnitTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/26254d59..949ee2be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=01-02 Stats: 43 lines in 1 file changed: 0 ins; 41 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From mark.reinhold at oracle.com Fri Jan 15 18:27:09 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Jan 2021 10:27:09 -0800 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: <20210115102709.538599954@eggemoggin.niobe.net> 2020/12/4 6:08:13 -0800, erikj at openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to maintain that document, and >>> I made my best guess at where to place it. >> >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably >> the most suitable home because Java SE specifies JDWP as an optional >> interface. So nothing to do with java.base and the build will need to >> continue to generate the sources for the front-end (jdk.jdi) and >> back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living > documents. In this case, I think it's perfectly valid to update JEP > 201 with additional source code layout. Both for this and for the > other missing dirs. Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we?d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what?d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. - Mark From ihse at openjdk.java.net Fri Jan 15 18:30:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Jan 2021 18:30:07 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman That sounds like an excellent idea. I'll update the PR first thing next week. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mbalao at openjdk.java.net Fri Jan 15 18:39:24 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 18:39:24 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v4] In-Reply-To: References: Message-ID: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with six additional commits since the last revision: - More consistent documentation about Cancel Operation in P11-services. - Consistent Cancel Operation behavior across P11-services: do not fail when the operation being cancelled was not initialized. - Better error handling in P11PSSSignature Cancel Operation and documentation improvements. - C_DecryptFinal/C_EncryptFinal failures do not need a Cancel Operation; only C_DecryptUpdate/C_EncryptUpdate ones. - Documentation note explaining why Cancel Operation is not required in P11AEADCipher - Documentation note explaining why Cancel Operation is not required in P11PSSSignature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/5bf00de0..ee90166e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=02-03 Stats: 60 lines in 5 files changed: 53 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Fri Jan 15 18:39:25 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 18:39:25 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Wed, 13 Jan 2021 00:53:01 GMT, Valerie Peng wrote: >>> For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. >> >> Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. > >> >> >> > For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. >> >> Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. > > Wonderful, thanks! P11PSSSignature --------------------- The P11PSSSignature case is analogous to PSSSignature, because the PKCS#11 primitives and their use from OpenJDK are similar. Added a note explaining why doCancel = false is safe even after C_Sign or C_SignFinal (so anyone reading the PKCS#11 standard and wondering about cancellation after CKR_BUFFER_TOO_SMALL errors or successful calls to determine the output length will have an answer there). In summary, this is handled at libj2pkcs native level. The only theoretical way I see to get an error here is that the output of the signature is greater than MAX_STACK_BUFFER_LEN -which, of course, will cause more critical issues-. Added a check in cancelOperation, so we have a consistent behavior with other P11 services. Cancel Operation should not fail if the operation being cancelled was not initialized. P11AEADCipher --------------------- In P11AEADCipher C_EncryptUpdate/C_DecryptUpdate/C_EncryptFinal/C_DecryptFinal PKCS#11 calls are not used but C_Encrypt/C_Decrypt only. According to the PKCS#11 standard [1], C_Encrypt does not cancel the operation in these cases: 1) CKR_BUFFER_TOO_SMALL error; and, 2) Successful call to determine the length of the output buffer. The NSS Software Token implementation seems to honor this specification in NSC_Encrypt [2]. These paths are not triggerable from OpenJDK because the output length is checked against an expected value before making the PKCS#11 call [3]. So it should be safe to assume that the operation will always be terminated in P11AEADCipher::implDoFinal. As a result, I conclude that no code changes are require in P11AEADCipher::implDoFinal but a documentation note explaining why doCancel = false is safe there [4]. The C_Decrypt case is analogous to C_Encrypt. Added a check in cancelOperation as in P11PSSSignature. P11RSACipher --------------------- C_WrapKey/C_UnwrapKey/C_GenerateKey: these calls are atomic, instead of multi-part operations; so there shouldn't be an issue there. In the case of C_Encrypt, C_Decrypt, C_Sign and C_VerifyRecover (P11RSACipher::implDoFinal), a reset with doCancel = true is not done. C_Encrypt/C_Decrypt can theoretically keep an operation active as listed for P11AEADCipher. However, I was unable to find in the NSS Software Token a path leading to a CKR_BUFFER_TOO_SMALL error from P11RSACipher::implDoFinal (CKM_RSA_PKCS or CKM_RSA_X_509 schemes): if the output buffer length is too short, we get a CKR_DEVICE_ERROR error coming from here [5]. I was unable to trigger a successful call with output length equal to 0 (to get the output length from the library) because direct buffers are not used [6] -see argument #6-, length-0 buffers do not return a null pointer here [7] (which is checked here [8] in the NSS side) and null buffers do not make the PKCS#11 call [9]. Looks to me that C_Encrypt may return CKR_BUFFER_TOO_SMALL for some algorithms such as RSA-OAEP, but that's not what P11RSACipher is currently using. C_Sign may return CKR_BUFFER_TOO_SMALL from NSC_SignFinal. However, the user does seem to have enough influence on the PKCS#11 call here [10] to trigger this path. I don't have evidence that the bug could be triggered in P11RSACipher; but the static analysis I've done is limited/error-prone. I'm inclined not to make any change unless we have real evidence that a cancel is required. Added a check in cancelOperation as in P11PSSSignature. P11Mac --------------------- Not cancelling from OpenJDK when C_SignFinal is called is safe as described before in this thread. In the case of a C_SignUpdate error, P11Mac::reset is not called so the Session is not returned to the Session Manager. Added a check in cancelOperation as in P11PSSSignature. P11Cipher --------------------- Revisiting the P11Cipher case, I realised that the bug can be triggered from C_EncryptUpdate/C_DecryptUpdate calls only and not from C_EncryptFinal/C_DecryptFinal. Thus, in P11Cipher::implDoFinal we might be cancelling when not necessary. Note that P11Cipher::implDoFinal may perform a C_EncryptUpdate/C_DecryptUpdate call internally. Fixed that: do not cancel as a result of a C_EncryptFinal/C_DecryptFinal failure. -- [1] - https://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aC_Encrypt [2] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1437 [3] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java#L588 [4] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java#L619 [5] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/freebl/rsapkcs.c#L911 [6] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSACipher.java#L278 [7] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L156 [8] - https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1463 [9] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L158 [10] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSACipher.java#L382 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Fri Jan 15 18:51:20 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 18:51:20 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v5] In-Reply-To: References: Message-ID: <_AjxOMzdr5Yuk1iYzOjgIeaqViOV8uKswq1GVg01RFs=.ac073be9-36ab-4626-a703-eb366a3c7fde@github.com> > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Minor documentation improvement in P11Mac regarding Cancel Operation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/ee90166e..0f96ddf1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Fri Jan 15 18:51:21 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 18:51:21 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: <-Y1bqFAoFBfbJ_cRfc8f4aea9rAEKVE163GqrwczbP8=.04c31523-d856-4cdb-83d5-40a59a9d6b26@github.com> Message-ID: On Wed, 13 Jan 2021 00:53:01 GMT, Valerie Peng wrote: >>> For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. >> >> Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. > >> >> >> > For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. >> >> Sure, I was going to go through each of them. Only P11Cipher and P11Signature so far but I'm working on this. > > Wonderful, thanks! @valeriepeng let me know your thoughts. Nothing else from my side now, unless you want me to revisit something. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Fri Jan 15 20:28:28 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 20:28:28 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/0f96ddf1..4c892a44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=04-05 Stats: 22 lines in 1 file changed: 0 ins; 20 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Fri Jan 15 20:28:29 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 15 Jan 2021 20:28:29 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: <2jE_ELoDdyYWln5jqcYNSYp7Fb3RnsDVl8oCyxy11xI=.fda11597-8f21-42b5-89be-0bd091746110@github.com> Message-ID: On Thu, 14 Jan 2021 20:29:54 GMT, Valerie Peng wrote: >> The update fails because the native mechanism (CKM_AES_ECB) has no padding and OpenJDK does not buffer data in the Java side for encryption [1] (this is a bug that I'll address soon). As a result, there is a PKCS#11 call with an invalid length and we get the error that ends up returning the session to the Session Manager. I just realized that when we fix the previous padding-bug, this test path won't work anymore. CKR_BUFFER_TOO_SMALL errors on updates do not lead to a reset call in the OpenJDK side (contrary to doFinal), so they wouldn't be useful for the test. I'll investigate if there is a way to trigger the path. Otherwise we should keep the doFinal path only. I'd still force a reset if there is an error other than CKR_BUFFER_TOO_SMALL in the update. >> >> -- >> [1] - https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L583 > > It's an update call, isn't padding occur when doFinal() is called for encryption? > In any case, it's best for the test case to not have this bug dependency. I am ok if you can only test doFinal path only. Yes, makes sense to remove the bug dependency and the whole encrypt-update path. I'll keep the test extensible, though; so we can include new paths eventually. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 15 23:08:21 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Jan 2021 23:08:21 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: <4Dsf85C-v85cMvsPUcNyzxFUK4t2ImMcP9nJxHiAU8E=.ab8664b3-eda6-49ff-ae20-9d4bc7f746ff@github.com> References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> <4Dsf85C-v85cMvsPUcNyzxFUK4t2ImMcP9nJxHiAU8E=.ab8664b3-eda6-49ff-ae20-9d4bc7f746ff@github.com> Message-ID: On Thu, 14 Jan 2021 20:04:33 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 344: >> >>> 342: if (keySpec instanceof PKCS8EncodedKeySpec) { >>> 343: return RSAPrivateCrtKeyImpl.newKey(type, "PKCS#8", >>> 344: ((PKCS8EncodedKeySpec)keySpec).getEncoded()); >> >> Will you clean up the `getEncoded()` output or shall I? > > Maybe it's better that you do it this time? Just so that the backport won't miss it. Or if you integrated before me, I will manually merge the changes and clean up the getEncoded() also. ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Fri Jan 15 23:09:12 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Jan 2021 23:09:12 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java line 214: Why do we remove the index checking from all methods? Isn't it safer to check here in case the caller didn't? Or is it such checking is already implemented inside the the various methods of VarHandle? ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From hchao at openjdk.java.net Fri Jan 15 23:09:26 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 15 Jan 2021 23:09:26 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v4] In-Reply-To: References: Message-ID: <4oMMmLQlJhwCzBxXUc73ALSfcA8XYfLhH3l4KHdCl-w=.71a71556-8773-46b9-b8b0-3d8cbc5b5a99@github.com> > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Nonce creation is done in checkOCSP method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/949ee2be..da6e5bab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=02-03 Stats: 68 lines in 1 file changed: 36 ins; 31 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Fri Jan 15 23:09:29 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 15 Jan 2021 23:09:29 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v2] In-Reply-To: References: <2qfGUobOcvCZrTF1oPX3qRPeI4SCw1aJoKHax4G9_VQ=.d5080529-8136-4bba-83bb-fdf7e548142e@github.com> Message-ID: On Thu, 14 Jan 2021 14:35:25 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use List.of() and typo changes > > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 88: > >> 86: boolean ocspNonce; >> 87: } >> 88: private RevocationProperties rp; > > I think this field could be `final`. No change made due to getting an error: cannot assign a value to final variable rp. > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 107: > >> 105: >> 106: private void setDefaultNonce() { >> 107: byte[] nonce = null; > > This variable looks like it is not used and can be removed. The setDefaultNonce() method is removed. > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 109: > >> 107: byte[] nonce = null; >> 108: >> 109: // Set the nonce by default in OCSP request extension when the sytem property > > Typo: s/sytem/system/ The setDefaultNonce() method is removed as creating nonce is done in checkOCSP() method now. > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 113: > >> 111: if (rp.ocspNonce) { >> 112: try { >> 113: setOcspExtensions(List.of(new OCSPNonceExtension(DEFAULT_NONCE_BYTES))); > > I don't think we should use the `PKIXRevocationChecker.setOcspExtensions()` API to add an OCSP Nonce extension. That API is intended to be called by applications. I think the Nonce extension should be set by the implementation only and not exposed via the standard API. Also, a nonce should be unique for each OCSP request, but setting it here means that it could re-use the same nonce for different OCSP requests. > > I think a better place to create/add the OCSPExtension is in the `checkOCSP` method, and the extension should be created each time that method is called (if the system property is enabled), so a new nonce is created for each OCSP request. Creating the nonce is moved to checkOCSP() method. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From redestad at openjdk.java.net Fri Jan 15 23:24:07 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 15 Jan 2021 23:24:07 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 22:54:32 GMT, Valerie Peng wrote: >> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms >> MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms >> MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms >> MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms >> MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms >> MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op >> >> Target: >> Benchmark (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms >> MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms >> MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms >> MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms >> MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms >> MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms >> >> GC >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op >> >> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. >> >> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. >> >> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. > > src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java line 214: > > > Why do we remove the index checking from all methods? Isn't it safer to check here in case the caller didn't? Or is it such checking is already implemented inside the the various methods of VarHandle? Yes, IOOBE checking is done by the VarHandle methods, while the Unsafe API is unsafe and needs careful precondition checking. It doesn't seem to matter for performance (interpreted code sees some benefit by the removal). With the current usage an IOOBE is probably not observable, but there's a test that reflects into ByteArrayAccess and verifies exceptions are thrown as expected on faulty inputs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From valeriep at openjdk.java.net Fri Jan 15 23:24:09 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Jan 2021 23:24:09 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. test/micro/org/openjdk/bench/java/util/UUIDBench.java line 2: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. nit: other files should also have this 2021 update. It seems most of them are not updated and still uses 2020. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 15 23:36:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 15 Jan 2021 23:36:42 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 23:21:00 GMT, Valerie Peng wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: >> >> - Copyrights >> - Merge branch 'master' into improve_md5 >> - Remove unused Unsafe import >> - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) >> - Merge branch 'master' into improve_md5 >> - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 >> - Remove unused reverseBytes imports >> - Copyrights >> - Fix copy-paste error >> - Various fixes (IDE stopped IDEing..) >> - ... and 10 more: https://git.openjdk.java.net/jdk/compare/6e03c8d3...cafa3e49 > > test/micro/org/openjdk/bench/java/util/UUIDBench.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > > nit: other files should also have this 2021 update. It seems most of them are not updated and still uses 2020. fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From redestad at openjdk.java.net Fri Jan 15 23:36:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 15 Jan 2021 23:36:35 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2] In-Reply-To: References: Message-ID: <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com> > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Copyrights - Merge branch 'master' into improve_md5 - Remove unused Unsafe import - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) - Merge branch 'master' into improve_md5 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 - Remove unused reverseBytes imports - Copyrights - Fix copy-paste error - Various fixes (IDE stopped IDEing..) - ... and 10 more: https://git.openjdk.java.net/jdk/compare/03e99844...cafa3e49 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1855/files - new: https://git.openjdk.java.net/jdk/pull/1855/files/e1c943c5..cafa3e49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=00-01 Stats: 28760 lines in 1103 files changed: 16020 ins; 7214 del; 5526 mod Patch: https://git.openjdk.java.net/jdk/pull/1855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855 PR: https://git.openjdk.java.net/jdk/pull/1855 From valeriep at openjdk.java.net Sat Jan 16 00:25:19 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 16 Jan 2021 00:25:19 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2] In-Reply-To: <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com> References: <0P4s8RVq7nJd-ZOK8o1RRnrNTQbf_sw1mk6q4dHpOI8=.14574584-f50a-4ce0-8d55-2dfb3bdf0fa0@github.com> Message-ID: On Fri, 15 Jan 2021 23:36:35 GMT, Claes Redestad wrote: >> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms >> MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms >> MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms >> MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms >> MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms >> MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op >> >> Target: >> Benchmark (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms >> MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms >> MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms >> MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms >> MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms >> MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms >> >> GC >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op >> >> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. >> >> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. >> >> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: > > - Copyrights > - Merge branch 'master' into improve_md5 > - Remove unused Unsafe import > - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) > - Merge branch 'master' into improve_md5 > - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 > - Remove unused reverseBytes imports > - Copyrights > - Fix copy-paste error > - Various fixes (IDE stopped IDEing..) > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/18f8493b...cafa3e49 Changes look good. Thanks. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1855 From naoto at openjdk.java.net Sat Jan 16 00:51:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 16 Jan 2021 00:51:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> References: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> Message-ID: On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: >> >>> 516: doclet.footer_specified=\ >>> 517: The -footer option is no longer supported and will be ignored.\n\ >>> 518: It may be removed in a future release. >> >> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? > > Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? > doclet.help.systemProperties.body=\ > The {0} page lists references to system properties. I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From ecki at zusammenkunft.net Mon Jan 18 00:39:42 2021 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 18 Jan 2021 01:39:42 +0100 Subject: Java and the NTFS Path weakness Message-ID: Hello, you might have seen the media coverage on a Microsoft Windows 10 and Windows Server problem where a certain NTFS internal path causes the Windows driver to claim corruption and mark the filesystem dirty. (Some even reported actual corruption of their filesystems). The java.nio Path seems to be resistance against that, as it detects an illegal path itself: | Welcome to JShell -- Version 11.0.9.1 | For an introduction type: /help intro jshell> var bad = "C:\\:$i30:$bitmap"; bad ==> "C:\\:$i30:$bitmap" jshell> new File(bad).toPath() | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap | at WindowsPathParser.normalize (WindowsPathParser.java:182) | at WindowsPathParser.parse (WindowsPathParser.java:153) | at WindowsPathParser.parse (WindowsPathParser.java:77) | at WindowsPath.parse (WindowsPath.java:92) | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) | at File.toPath (File.java:2292) | at (#6:1) jshell> Paths.get(bad) | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap | at WindowsPathParser.normalize (WindowsPathParser.java:182) | at WindowsPathParser.parse (WindowsPathParser.java:153) | at WindowsPathParser.parse (WindowsPathParser.java:77) | at WindowsPath.parse (WindowsPath.java:92) | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) | at Path.of (Path.java:147) | at Paths.get (Paths.java:69) | at (#7:1) jshell> Path.of(bad) | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap | at WindowsPathParser.normalize (WindowsPathParser.java:182) | at WindowsPathParser.parse (WindowsPathParser.java:153) | at WindowsPathParser.parse (WindowsPathParser.java:77) | at WindowsPath.parse (WindowsPath.java:92) | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) | at Path.of (Path.java:147) | at (#8:1) (not sure if there is a way to construct a path without that normalization). Unfortunally, however, the java.io.File and its IO functions to not provide this protection, when you call jshell> new File(bad).exists() $9 ==> false (or some other methods accessing the file) you will see the crash message in the event log. I am not sure if Java should or could filter that (however since java.nio already does it might be an option, not sure however if Microsoft would be faster and fixing that problem). But I thought I mention this here in case you have Java server applications which derive file names from untrusted user input (including uncompressing ZIP files). Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Mon Jan 18 02:29:38 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 18 Jan 2021 02:29:38 GMT Subject: Integrated: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 20:29:08 GMT, Valerie Peng wrote: > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 68cf65d2 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/68cf65d2 Stats: 462 lines in 6 files changed: 303 ins; 55 del; 104 mod 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From valeriep at openjdk.java.net Mon Jan 18 02:29:36 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 18 Jan 2021 02:29:36 GMT Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: <3QzXUD_r9pymbEqZPGqJ8HSk7SWfvv_ID5lPfU2ONnk=.ac6a3adc-1e14-4750-a87f-139934081cc6@github.com> References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> <3QzXUD_r9pymbEqZPGqJ8HSk7SWfvv_ID5lPfU2ONnk=.ac6a3adc-1e14-4750-a87f-139934081cc6@github.com> Message-ID: On Fri, 15 Jan 2021 01:45:07 GMT, Valerie Peng wrote: >> Marked as reviewed by weijun (Reviewer). > >> >> >> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at openjdk.java.net):_ >> >> Sorry - I'm coming to this a bit late. >> >> Any chance of adding the logic for generatePublic() from a PKCS8 RSA >> private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes >> the modulus and publicExponent - so it should be a pretty straight >> forward add to generate a public key. >> >> PKCS11 2.40 started requiring that the publicExponent be stored with the >> private key to allow for the public key to be regenerated from a private >> key object.?? Going forward,? it might be a good idea to modify the >> RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. >> >> Mike > > You are correct that for RSA private CRT keys the necessary values are there for figuring out its corresponding public keys. > > This change is about adding support for PKCS#1 encoded RSA keys and be able to translate them into PKCS#8 encoded keys and/or extract various key specs out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign provider, you can call its getPublicExponent() method and use that to create a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd party impl which does not return the public exponent value somehow, then you can translate it using the RSA key factory impl from SunRsaSign provider and then repeat the fore-mentioned step. Will this address your need? If not, could you elaborate the usage that you have in mind? Not sure if you are suggesting a new KeyFactory.generatePublic() method which take a PrivateKey or else. Mike, We can continue your feedback with a separate RFE since this RFE is just about adding support for PKCS#1 encoding. I need to wrap this up before my upcoming trip this Wed, hope that's ok with you. Thanks! Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/1787 From ljiang at openjdk.java.net Mon Jan 18 05:52:57 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Mon, 18 Jan 2021 05:52:57 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3] In-Reply-To: References: Message-ID: > This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request incrementally with one additional commit since the last revision: fix the missing copyright year for standard.properties ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/d72f444a..9c7574e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Mon Jan 18 05:52:57 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Mon, 18 Jan 2021 05:52:57 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> Message-ID: On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato wrote: >> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? >> doclet.help.systemProperties.body=\ >> The {0} page lists references to system properties. > > I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file. Thx! Fixed the copyright year for this file. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From redestad at openjdk.java.net Mon Jan 18 12:58:20 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 18 Jan 2021 12:58:20 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v3] In-Reply-To: References: Message-ID: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Adjust to keep reflection-driven tests from failing - Merge branch 'master' into improve_md5 - Copyrights - Merge branch 'master' into improve_md5 - Remove unused Unsafe import - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) - Merge branch 'master' into improve_md5 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 - Remove unused reverseBytes imports - Copyrights - ... and 12 more: https://git.openjdk.java.net/jdk/compare/25fa448d...fdd2d19e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1855/files - new: https://git.openjdk.java.net/jdk/pull/1855/files/cafa3e49..fdd2d19e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=01-02 Stats: 11783 lines in 75 files changed: 1309 ins; 9196 del; 1278 mod Patch: https://git.openjdk.java.net/jdk/pull/1855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855 PR: https://git.openjdk.java.net/jdk/pull/1855 From magnus.ihse.bursie at oracle.com Mon Jan 18 13:21:07 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 14:21:07 +0100 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: <20210115102709.538599954@eggemoggin.niobe.net> References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> <20210115102709.538599954@eggemoggin.niobe.net> Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com> On 2021-01-15 19:27, mark.reinhold at oracle.com wrote: > Feature JEPs are living documents until such time as they are delivered. > In this case it would not be appropriate to update JEP 201, which is as > much about the transition from the old source-code layout as it is about > the new layout as of 2014. > > At this point, and given that we?d already gone beyond JEP 201 prior to > this change (with `man` and `lib` subdirectories), what?d make the most > sense is a new informational JEP that documents the source-code layout. > Informational JEPs can, within reason, be updated over time. So I take it I need to create a new informational JEP. :-) Fine, I can do that. I assume I mostly need to extract the parts of JEP 201 that describes the (then "new") layout, update wording to show that this is a description of the current layout, and add the new additions. It'll be a very short JEP, but in this case, that's probably a virtue. /Magnus From redestad at openjdk.java.net Mon Jan 18 13:39:04 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 18 Jan 2021 13:39:04 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4] In-Reply-To: References: Message-ID: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove unused code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1855/files - new: https://git.openjdk.java.net/jdk/pull/1855/files/fdd2d19e..4c2798aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=02-03 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855 PR: https://git.openjdk.java.net/jdk/pull/1855 From ihse at openjdk.java.net Mon Jan 18 13:47:20 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:47:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move characterdata templates to share/classes/java/lang. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03-04 Stats: 4 lines in 9 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Jan 18 13:49:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:49:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman When I moved the charset templates, I found this gold nugget: # Copy two Java files that need no preprocessing. $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template $(call LogInfo, Generating $(@F)) $(call install-file) GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlaskey at openjdk.java.net Mon Jan 18 16:38:09 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 18 Jan 2021 16:38:09 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v13] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into 8248862 - Correct range used by nextBytes - Merge branch 'master' into 8248862 - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators Added coverage testing - 8248862: Implement Enhanced Pseudo-Random Number Generators Cleanups from Chris H. - 8248862: Implement Enhanced Pseudo-Random Number Generators Propagate exception - ... and 30 more: https://git.openjdk.java.net/jdk/compare/061ffc47...772abef6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=12 Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Mon Jan 18 16:45:00 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 18 Jan 2021 16:45:00 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update package info to credit LMX algorithm ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/772abef6..38369702 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=12-13 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From mstjohns at comcast.net Mon Jan 18 20:56:05 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 18 Jan 2021 15:56:05 -0500 Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3] In-Reply-To: References: <2dq0tv2Sw28noH7k5pYcC6x6eFRgzjuobAGQph2iC3M=.4b81574a-a6b7-4325-a284-6a6a1a976998@github.com> <3QzXUD_r9pymbEqZPGqJ8HSk7SWfvv_ID5lPfU2ONnk=.ac6a3adc-1e14-4750-a87f-139934081cc6@github.com> Message-ID: <9b222ece-e6c0-d602-6907-6e7244f8ff2e@comcast.net> On 1/17/2021 9:29 PM, Valerie Peng wrote: > On Fri, 15 Jan 2021 01:45:07 GMT, Valerie Peng wrote: > >>> Marked as reviewed by weijun (Reviewer). >>> >>> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at openjdk.java.net):_ >>> >>> Sorry - I'm coming to this a bit late. >>> >>> Any chance of adding the logic for generatePublic() from a PKCS8 RSA >>> private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes >>> the modulus and publicExponent - so it should be a pretty straight >>> forward add to generate a public key. >>> >>> PKCS11 2.40 started requiring that the publicExponent be stored with the >>> private key to allow for the public key to be regenerated from a private >>> key object.?? Going forward,? it might be a good idea to modify the >>> RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. >>> >>> Mike >> You are correct that for RSA private CRT keys the necessary values are there for figuring out its corresponding public keys. >> >> This change is about adding support for PKCS#1 encoded RSA keys and be able to translate them into PKCS#8 encoded keys and/or extract various key specs out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign provider, you can call its getPublicExponent() method and use that to create a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd party impl which does not return the public exponent value somehow, then you can translate it using the RSA key factory impl from SunRsaSign provider and then repeat the fore-mentioned step. Will this address your need? If not, could you elaborate the usage that you have in mind? Not sure if you are suggesting a new KeyFactory.generatePublic() method which take a PrivateKey or else. > Mike, > We can continue your feedback with a separate RFE since this RFE is just about adding support for PKCS#1 encoding. > I need to wrap this up before my upcoming trip this Wed, hope that's ok with you. > > Thanks! Valerie > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1787 No worries - I got busy with other things for a few days. To answer your other question, I've had a few cases where the public key for a private key has been misplaced and where we needed it back.? Ideally,? it should be possible to take a PrivateKey object (in whatever form including just PrivateKey) and run it through the KeyFactory to extract a PublicKey.? I've used the technique you suggest above before (and the related multiply the private scalar against G for EC keys) to retrieve the data needed to build a public key, but each of these is a bit ad hoc. I'd really prefer to have a standard pattern for all key types. About 4 years or so ago (e.g. when 2.40 was released), the PKCS11 group started requiring that the private keys include the attributes necessary to retrieve the public key - for RSA it was the public exponent, and for EC it was the public point (which could be stored or regenerated upon demand).? It may be time to think about doing something similar here and going forward for any given asymmetric key type. That's a more general RFE than just updating the current implementing classes, but as far as I can tell, doesn't change any of the APIs, but may change the factory class implementation guidance. An interesting addition would be to have the Impl classes implement both the appropriate public key and private key interfaces. From ecki at zusammenkunft.net Mon Jan 18 21:29:04 2021 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 18 Jan 2021 22:29:04 +0100 Subject: Java and the NTFS Path weakness In-Reply-To: References: Message-ID: Hello, bad news everyone. The second Windows Filesystem related security bug reported by Jonas Lykkegaard which allows crashing Windows with a unpriveledged read access also affects JVM and it is not filtered by Path.of. Which means bot new File(bad).exists() and Files.readAllLines(Path.of(bad)) will crash Windows immediatelly. I verified this on the latest Windows Server 2019 January Security Update. var bad = "\\\\.\\globalroot\\device\\condrv\\kernelconnect" Gruss Bernd Am Mo., 18. Jan. 2021 um 01:39 Uhr schrieb Bernd : > Hello, > > you might have seen the media coverage on a Microsoft Windows 10 and > Windows Server problem where a certain NTFS internal path causes the > Windows driver to claim corruption and mark the filesystem dirty. (Some > even reported actual corruption of their filesystems). > > The java.nio Path seems to be resistance against that, as it detects an > illegal path itself: > > | Welcome to JShell -- Version 11.0.9.1 > | For an introduction type: /help intro > > jshell> var bad = "C:\\:$i30:$bitmap"; > bad ==> "C:\\:$i30:$bitmap" > > jshell> new File(bad).toPath() > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > | at WindowsPathParser.normalize (WindowsPathParser.java:182) > | at WindowsPathParser.parse (WindowsPathParser.java:153) > | at WindowsPathParser.parse (WindowsPathParser.java:77) > | at WindowsPath.parse (WindowsPath.java:92) > | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > | at File.toPath (File.java:2292) > | at (#6:1) > > jshell> Paths.get(bad) > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > | at WindowsPathParser.normalize (WindowsPathParser.java:182) > | at WindowsPathParser.parse (WindowsPathParser.java:153) > | at WindowsPathParser.parse (WindowsPathParser.java:77) > | at WindowsPath.parse (WindowsPath.java:92) > | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > | at Path.of (Path.java:147) > | at Paths.get (Paths.java:69) > | at (#7:1) > > jshell> Path.of(bad) > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > | at WindowsPathParser.normalize (WindowsPathParser.java:182) > | at WindowsPathParser.parse (WindowsPathParser.java:153) > | at WindowsPathParser.parse (WindowsPathParser.java:77) > | at WindowsPath.parse (WindowsPath.java:92) > | at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > | at Path.of (Path.java:147) > | at (#8:1) > > (not sure if there is a way to construct a path without that > normalization). > > Unfortunally, however, the java.io.File and its IO functions to not > provide this protection, when you call > > jshell> new File(bad).exists() > $9 ==> false > > (or some other methods accessing the file) you will see the crash message > in the event log. > > I am not sure if Java should or could filter that (however since java.nio > already does it might be an option, not sure however if Microsoft would be > faster and fixing that problem). But I thought I mention this here in case > you have Java server applications which derive file names from untrusted > user input (including uncompressing ZIP files). > > Gruss > Bernd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 19 08:26:02 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jan 2021 08:26:02 +0000 Subject: Java and the NTFS Path weakness In-Reply-To: References: Message-ID: <18c73acc-32ed-6688-4a1c-bf3e0dfa73e5@oracle.com> On 18/01/2021 21:29, Bernd wrote: > Hello, > > bad news everyone. The second Windows Filesystem related security bug > reported by Jonas Lykkegaard which allows crashing Windows with a > unpriveledged read access also affects JVM and it is not filtered by > Path.of. Which means bot new File(bad).exists() and > Files.readAllLines(Path.of(bad)) will crash Windows immediatelly. > > I verified this on the latest Windows Server 2019 January Security Update. > > var bad = "\\\\.\\globalroot\\device\\condrv\\kernelconnect" > BSOD issues should be reported to Microsoft. If there is any suggestion of a JDK bug here then it should be reported to vuln-report at openjdk.java.net. We (at least Oracle engineers) cannot engage in any discussion of vulnerability issues here. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Tue Jan 19 10:18:03 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 19 Jan 2021 10:18:03 +0000 Subject: Java and the NTFS Path weakness In-Reply-To: <18c73acc-32ed-6688-4a1c-bf3e0dfa73e5@oracle.com> References: , <18c73acc-32ed-6688-4a1c-bf3e0dfa73e5@oracle.com> Message-ID: Hello Alan, I don?t think this is a Java vulnerability (but something Java application programmers have to deal with), that?s why I sent it to the mailing list (for lack of better channels). Still there is a lesson to learn, we have two different windows file Name parsing behaviors in the openjdk. Microsoft (and the mass media) seems to be aware of the Windows problems. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Alan Bateman Gesendet: Tuesday, January 19, 2021 9:26:02 AM An: Bernd ; OpenJDK Dev list ; nio-dev Betreff: Re: Java and the NTFS Path weakness On 18/01/2021 21:29, Bernd wrote: Hello, bad news everyone. The second Windows Filesystem related security bug reported by Jonas Lykkegaard which allows crashing Windows with a unpriveledged read access also affects JVM and it is not filtered by Path.of. Which means bot new File(bad).exists() and Files.readAllLines(Path.of(bad)) will crash Windows immediatelly. I verified this on the latest Windows Server 2019 January Security Update. var bad = "\\\\.\\globalroot\\device\\condrv\\kernelconnect" BSOD issues should be reported to Microsoft. If there is any suggestion of a JDK bug here then it should be reported to vuln-report at openjdk.java.net. We (at least Oracle engineers) cannot engage in any discussion of vulnerability issues here. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From research at bensmyth.com Tue Jan 19 10:32:08 2021 From: research at bensmyth.com (Ben Smyth) Date: Tue, 19 Jan 2021 11:32:08 +0100 Subject: TLS Manual: Call for contributions Message-ID: I've written a TLS manual, intended to ease readers into the most recent specification. (At the very least, it helped me get to grips with the spec!) I've now made the manual available on GitHub: https://github.com/BenSmyth/tls-tutorial/ A pdf is also available (https://bensmyth.com/files/Smyth19-TLS-tutorial.pdf). I'm far from perfect and I'm sure the manuscript houses numerous deficiencies. Interesting aspects are omitted, because I didn't have the time, knowledge, or expertise to add them. For instance, the specification hasn't been entirely covered, as is documented; discussion of security guarantees are notably lacking; and an introduction to the underlying cryptography is absent. (E.g., some details on DHKE, AEAD, etc. would be grand.) Directions for further exploration are missing, hands-on teaching opportunities foregone. For instance, a Davies-style exploration of TLS on-the-wire, with notes on Wireshark and SSLKEYLOGFILE---perhaps as dirty as readers can get, without bursting-out soldering irons. Mistakes and issues are no doubt numerous. I encourage you to improve this manuscript. Fix a typo. Patch grammar. Revise awkward, overcomplicated, or otherwise poorly-written passages. Contribute an entire section. Help evolve the manual. (Perhaps get in touch prior to writing an entire section! We should probably reach consensus on what to add.) Contributions will be recognised through acknowledgements or co-authorship. Best regards, Ben -- https://bensmyth.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.java.net Tue Jan 19 16:55:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 19 Jan 2021 16:55:46 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix the missing copyright year for standard.properties Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From coffeys at openjdk.java.net Tue Jan 19 17:59:55 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 19 Jan 2021 17:59:55 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code Message-ID: Correction of NPE and updating of test cases. Minor refactoring of test library also. ------------- Commit messages: - 8255348: NPE in PKIXCertPathValidator event logging code Changes: https://git.openjdk.java.net/jdk/pull/2150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255348 Stats: 83 lines in 6 files changed: 60 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150 From valeriep at openjdk.java.net Tue Jan 19 22:29:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Jan 2021 22:29:44 GMT Subject: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:39:04 GMT, Claes Redestad wrote: >> - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms >> MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms >> MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms >> MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms >> MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms >> MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op >> >> Target: >> Benchmark (digesterName) (length) Cnt Score Error Units >> MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms >> MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms >> MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms >> MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms >> MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms >> MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms >> MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms >> MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms >> MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms >> MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms >> MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms >> MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms >> >> GC >> MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op >> MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op >> >> For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. >> >> For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. >> >> I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused code Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From github.com+1966176+lic9 at openjdk.java.net Wed Jan 20 00:13:03 2021 From: github.com+1966176+lic9 at openjdk.java.net (Chen Li) Date: Wed, 20 Jan 2021 00:13:03 GMT Subject: RFR: 8253821: Improve ByteBuffer performance with GCM In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 20:22:55 GMT, Anthony Scarpino wrote: > 8253821: Improve ByteBuffer performance with GCM Hi @ascarpino, could you please share which Flink test you ran? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/411 From valeriep at openjdk.java.net Wed Jan 20 03:19:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Jan 2021 03:19:44 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 353: > 351: } > 352: } catch (PKCS11Exception e) { > 353: if (e.getErrorCode() == CKR_OPERATION_NOT_INITIALIZED) { nit: update copyright year to 2021 ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Wed Jan 20 05:23:46 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Jan 2021 05:23:46 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. 2021? ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Wed Jan 20 05:58:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Jan 2021 05:58:45 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 631: > 629: // these cases are not expected here because the output length > 630: // is checked in the OpenJDK side before making the PKCS#11 call. > 631: // Thus, doCancel can safely be 'false'. Since the code is following the spec, I am not sure if this comment provides additional info? Fine to leave it if you prefer to have it. Just a thought. This goes for the same comments for other classes where we are not changing the behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Wed Jan 20 06:07:48 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Jan 2021 06:07:48 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: <8mLh5Fxwe88-zi6XF1X2IXYJnwvzHY1wkN2TN69G7IM=.4a3b884e-568f-478a-953f-7a4da68f0088@github.com> On Fri, 15 Jan 2021 20:28:28 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. Just made some feedback regarding comments, the actual changes look good. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 638: > 636: (new ShortBufferException().initCause(e)); > 637: } > 638: reset(true); Per PKCS#11 spec, "A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation.", so I'd expect comment here to explain why we are doing reset(true). If not mentioning the known NSS behavior which triggered this change, at least comment the bug id so we don't lost track of the reason for the switch. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 756: > 754: (new ShortBufferException().initCause(e)); > 755: } > 756: reset(true); Comment for line 638 apply here as well. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Wed Jan 20 06:07:50 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Jan 2021 06:07:50 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v5] In-Reply-To: <_AjxOMzdr5Yuk1iYzOjgIeaqViOV8uKswq1GVg01RFs=.ac073be9-36ab-4626-a703-eb366a3c7fde@github.com> References: <_AjxOMzdr5Yuk1iYzOjgIeaqViOV8uKswq1GVg01RFs=.ac073be9-36ab-4626-a703-eb366a3c7fde@github.com> Message-ID: <19_cMqLif9bWpqTVluk1OfxIY_l5WLvl7amSH9a_OGw=.2414b4c3-785c-4f9f-b383-46e7670ac73a@github.com> On Fri, 15 Jan 2021 18:51:20 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Minor documentation improvement in P11Mac regarding Cancel Operation src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 802: > 800: System.arraycopy(padBuffer, 0, out, outOfs, k); > 801: } else { > 802: k = token.p11.C_DecryptFinal(session.id(), 0, out, outOfs, Comment for line 638 apply here as well. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 887: > 885: (!(outBuffer instanceof DirectBuffer) && > 886: !outBuffer.hasArray())) { > 887: outBuffer.put(outArray, outOfs, k); Comment for line 638 apply here as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbaesken at openjdk.java.net Wed Jan 20 11:53:13 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 11:53:13 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r [v2] In-Reply-To: References: Message-ID: > We have a couple of calls to getpwuid_r in the codebase, like > g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); > > Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). > > This triggers also Sonar warnings like : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG > > > Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: revert perfMemory changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2098/files - new: https://git.openjdk.java.net/jdk/pull/2098/files/15075d1e..a98df02b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=00-01 Stats: 11 lines in 3 files changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2098/head:pull/2098 PR: https://git.openjdk.java.net/jdk/pull/2098 From mbaesken at openjdk.java.net Wed Jan 20 11:59:12 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 11:59:12 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r [v3] In-Reply-To: References: Message-ID: > We have a couple of calls to getpwuid_r in the codebase, like > g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); > > Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). > > This triggers also Sonar warnings like : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG > > > Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: More revert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2098/files - new: https://git.openjdk.java.net/jdk/pull/2098/files/a98df02b..9fa25435 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2098/head:pull/2098 PR: https://git.openjdk.java.net/jdk/pull/2098 From mbaesken at openjdk.java.net Wed Jan 20 12:05:03 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 12:05:03 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r [v4] In-Reply-To: References: Message-ID: > We have a couple of calls to getpwuid_r in the codebase, like > g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); > > Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). > > This triggers also Sonar warnings like : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG > > > Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - bring initialization to perfMemory_posix - Merge branch 'master' into JDK-8259786 - More revert - revert perfMemory changes - JDK-8259786 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2098/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2098&range=03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2098/head:pull/2098 PR: https://git.openjdk.java.net/jdk/pull/2098 From mbalao at openjdk.java.net Wed Jan 20 12:40:49 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 12:40:49 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: <5fOQwsS2SKT67HA21dxTT3H0LzfSiKTHnZ19rxlEzXE=.f23c4c8b-77d2-482f-8975-d5e5acabf678@github.com> On Wed, 20 Jan 2021 03:16:32 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 353: > >> 351: } >> 352: } catch (PKCS11Exception e) { >> 353: if (e.getErrorCode() == CKR_OPERATION_NOT_INITIALIZED) { > > nit: update copyright year to 2021. Same goes for other sources. right, thanks > test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Red Hat, Inc. > > 2021? right, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Wed Jan 20 12:46:53 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 12:46:53 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: References: Message-ID: <0VOYeQah1wm5t50ju5XX-ekWM0JN8KAKAkpmai5xaC0=.d207270a-681e-4b56-bb4c-774d7368f5e0@github.com> On Wed, 20 Jan 2021 05:55:26 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 631: > >> 629: // these cases are not expected here because the output length >> 630: // is checked in the OpenJDK side before making the PKCS#11 call. >> 631: // Thus, doCancel can safely be 'false'. > > Since the code is following the spec, I am not sure if this comment provides additional info? Fine to leave it if you prefer to have it. Just a thought. This goes for the same comments for other classes where we are not changing the behavior. I wish we could keep the comment and make the previous assumption more explicit, even when someone can read the code above and arrive to the same conclusion. If the code around ever changes, this comment is something we must consider and, eventually, take action. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Wed Jan 20 12:55:58 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 12:55:58 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v6] In-Reply-To: <8mLh5Fxwe88-zi6XF1X2IXYJnwvzHY1wkN2TN69G7IM=.4a3b884e-568f-478a-953f-7a4da68f0088@github.com> References: <8mLh5Fxwe88-zi6XF1X2IXYJnwvzHY1wkN2TN69G7IM=.4a3b884e-568f-478a-953f-7a4da68f0088@github.com> Message-ID: On Wed, 20 Jan 2021 05:58:49 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing the encryption-update path in CancelMultipart test as it depends on a know bug to cause a PKCS#11 error. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 638: > >> 636: (new ShortBufferException().initCause(e)); >> 637: } >> 638: reset(true); > > Per PKCS#11 spec, "A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation.", so I'd expect comment here to explain why we are doing reset(true). If not mentioning the known NSS behavior which triggered this change, at least comment the bug id so we don't lost track of the reason for the switch. Yes, makes sense. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mbalao at openjdk.java.net Wed Jan 20 12:59:50 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 12:59:50 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v5] In-Reply-To: <19_cMqLif9bWpqTVluk1OfxIY_l5WLvl7amSH9a_OGw=.2414b4c3-785c-4f9f-b383-46e7670ac73a@github.com> References: <_AjxOMzdr5Yuk1iYzOjgIeaqViOV8uKswq1GVg01RFs=.ac073be9-36ab-4626-a703-eb366a3c7fde@github.com> <19_cMqLif9bWpqTVluk1OfxIY_l5WLvl7amSH9a_OGw=.2414b4c3-785c-4f9f-b383-46e7670ac73a@github.com> Message-ID: On Wed, 20 Jan 2021 06:00:41 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor documentation improvement in P11Mac regarding Cancel Operation > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 802: > >> 800: System.arraycopy(padBuffer, 0, out, outOfs, k); >> 801: } else { >> 802: k = token.p11.C_DecryptFinal(session.id(), 0, out, outOfs, > > Comment for line 638 apply here as well. I agree, but the comment (in my opinion) should be right after the C_EncryptUpdate/C_DecryptUpdate call when doCancel is set to false. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From mdoerr at openjdk.java.net Wed Jan 20 13:01:49 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 20 Jan 2021 13:01:49 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r [v4] In-Reply-To: References: Message-ID: <0mIikFkef8bnlR4pWQ4fxrXuVmzEQbphq_o4haah82g=.69830301-fc23-431f-be30-fec32e497365@github.com> On Wed, 20 Jan 2021 12:05:03 GMT, Matthias Baesken wrote: >> We have a couple of calls to getpwuid_r in the codebase, like >> g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); >> >> Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). >> >> This triggers also Sonar warnings like : >> https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG >> >> >> Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? > > Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - bring initialization to perfMemory_posix > - Merge branch 'master' into JDK-8259786 > - More revert > - revert perfMemory changes > - JDK-8259786 Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2098 From mbalao at openjdk.java.net Wed Jan 20 13:47:13 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 13:47:13 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v7] In-Reply-To: References: Message-ID: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. Martin Balao has updated the pull request incrementally with two additional commits since the last revision: - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to 'P11Cipher::implDoFinal(ByteBuffer..'. Better documentation in P11Cipher. Copyright date updated. - Copyright dates updated to 2021 on modified files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1901/files - new: https://git.openjdk.java.net/jdk/pull/1901/files/4c892a44..bb52a064 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1901&range=05-06 Stats: 40 lines in 6 files changed: 31 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1901/head:pull/1901 PR: https://git.openjdk.java.net/jdk/pull/1901 From mullan at openjdk.java.net Wed Jan 20 13:53:49 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Jan 2021 13:53:49 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v4] In-Reply-To: <4oMMmLQlJhwCzBxXUc73ALSfcA8XYfLhH3l4KHdCl-w=.71a71556-8773-46b9-b8b0-3d8cbc5b5a99@github.com> References: <4oMMmLQlJhwCzBxXUc73ALSfcA8XYfLhH3l4KHdCl-w=.71a71556-8773-46b9-b8b0-3d8cbc5b5a99@github.com> Message-ID: On Fri, 15 Jan 2021 23:09:26 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Nonce creation is done in checkOCSP method Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 762: > 760: } catch (IOException e) { > 761: throw new CertPathValidatorException("Failed to create the default nonce " + > 762: "in OCSP entensions"); Typo: s/entensions/extensions/ Also, use the `CertPathValidatorException(String, Throwable)` ctor instead and pass the `IOException` as the 2nd parameter. src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 755: > 753: // create the 16-byte nonce by default > 754: Extension nonceExt = new OCSPNonceExtension(DEFAULT_NONCE_BYTES); > 755: tmpExtensions.add(nonceExt); I think you should add the OCSPNonce extension to the list of extensions that the application passed in, as there may be other extensions that have been specified and should be sent in the OCSP response, ex: `ocspExtensions.add(new OCSPNonceExtension(DEFAULT_NONCE_BYTES));` This means you don't need the `tmpExtensions` variable. src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 779: > 777: response = OCSP.check(Collections.singletonList(certId), > 778: responderURI, issuerInfo, responderCert, null, > 779: rp.ocspNonce ? tmpExtensions : ocspExtensions, params.variant()); Here you can just pass in `ocspExtensions` since it will contain the nonce if the property has been set. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hseigel at openjdk.java.net Wed Jan 20 13:54:50 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 20 Jan 2021 13:54:50 GMT Subject: RFR: JDK-8259786: initialize last parameter of getpwuid_r [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 12:05:03 GMT, Matthias Baesken wrote: >> We have a couple of calls to getpwuid_r in the codebase, like >> g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); >> >> Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). >> >> This triggers also Sonar warnings like : >> https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG >> >> >> Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? > > Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - bring initialization to perfMemory_posix > - Merge branch 'master' into JDK-8259786 > - More revert > - revert perfMemory changes > - JDK-8259786 Changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2098 From mbalao at openjdk.java.net Wed Jan 20 13:55:48 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Jan 2021 13:55:48 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v7] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 13:47:13 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to 'P11Cipher::implDoFinal(ByteBuffer..'. Better documentation in P11Cipher. Copyright date updated. > - Copyright dates updated to 2021 on modified files src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 793: > 791: // only after this point. See JDK-8258833 for further > 792: // information. > 793: doCancel = false; @valeriepeng I made a code change here so I'd like you to have a final look and validate. I'm just aligning the 'P11Cipher::implDoFinal(byte[]..' function to 'P11Cipher::implDoFinal(ByteBuffer..'. The rationale is that 'doFalse = false' can be placed before the C_EncryptFinal call because any error on it does not require a cancel (it already cancels the operation) src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 812: > 810: // only after this point. See JDK-8258833 for further > 811: // information. > 812: doCancel = false; Same comment that for line 793 of P11Cipher src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 820: > 818: System.arraycopy(padBuffer, 0, out, outOfs, k); > 819: } else { > 820: doCancel = false; Same comment than for line 793 of P11Cipher ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From ljiang at openjdk.java.net Wed Jan 20 14:01:48 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Wed, 20 Jan 2021 14:01:48 GMT Subject: [jdk16] Integrated: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. This pull request has now been integrated. Changeset: 01205109 Author: Leo Jiang URL: https://git.openjdk.java.net/jdk16/commit/01205109 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod 8259732: JDK 16 L10n resource file update - msg drop 10 Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From mbaesken at openjdk.java.net Wed Jan 20 15:07:57 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 15:07:57 GMT Subject: Integrated: JDK-8259786: initialize last parameter of getpwuid_r In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 11:24:49 GMT, Matthias Baesken wrote: > We have a couple of calls to getpwuid_r in the codebase, like > g= getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd); > > Usually we NULL-check pwd after the call because we do not fully trust the return code of the function (it is documented in the codebase why we do not fully trust the return code) . However we miss to initialize pwd at some places before the call, which might we a little problematic and should be improved (at other places we already initialize it). > > This triggers also Sonar warnings like : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0dsA8L9hkQskGEbA&resolved=false&types=BUG > > > Aside from this issue , should we in other issue , unify the OS versions of static char* get_user_name(uid_t uid) in posix code (currently we have it for bsd, linux, aix but the functions look very similar ? This pull request has now been integrated. Changeset: 52ed2aab Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/52ed2aab Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8259786: initialize last parameter of getpwuid_r Reviewed-by: mdoerr, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/2098 From hchao at openjdk.java.net Wed Jan 20 19:37:10 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 19:37:10 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v5] In-Reply-To: References: Message-ID: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Add nonce to the list of extensions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/da6e5bab..a14a2bdb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=03-04 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 19:37:11 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 19:37:11 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v4] In-Reply-To: References: <4oMMmLQlJhwCzBxXUc73ALSfcA8XYfLhH3l4KHdCl-w=.71a71556-8773-46b9-b8b0-3d8cbc5b5a99@github.com> Message-ID: On Wed, 20 Jan 2021 13:41:04 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Nonce creation is done in checkOCSP method > > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 762: > >> 760: } catch (IOException e) { >> 761: throw new CertPathValidatorException("Failed to create the default nonce " + >> 762: "in OCSP entensions"); > > Typo: s/entensions/extensions/ > > Also, use the `CertPathValidatorException(String, Throwable)` ctor instead and pass the `IOException` as the 2nd parameter. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 19:45:49 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 19:45:49 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v4] In-Reply-To: References: <4oMMmLQlJhwCzBxXUc73ALSfcA8XYfLhH3l4KHdCl-w=.71a71556-8773-46b9-b8b0-3d8cbc5b5a99@github.com> Message-ID: <93Zob46oLPNCANvoAP_pZjYi8YojgjlsC410gnep3bY=.30e7f1d9-c839-4dc4-9900-9fc35f1c37f9@github.com> On Wed, 20 Jan 2021 13:46:58 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Nonce creation is done in checkOCSP method > > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 755: > >> 753: // create the 16-byte nonce by default >> 754: Extension nonceExt = new OCSPNonceExtension(DEFAULT_NONCE_BYTES); >> 755: tmpExtensions.add(nonceExt); > > I think you should add the OCSPNonce extension to the list of extensions that the application passed in, as there may be other extensions that have been specified and should be sent in the OCSP response, ex: > > `ocspExtensions.add(new OCSPNonceExtension(DEFAULT_NONCE_BYTES));` > > This means you don't need the `tmpExtensions` variable. During testing, I got the "java.base/java.util.Collections$UnmodifiableCollection.add(Collections.java:1062) exception with this line of change. I've changed to use a tmpExtensions variable when setting the OCSP nonce to the extension sets instead of modifying the ocspExtensions. > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 779: > >> 777: response = OCSP.check(Collections.singletonList(certId), >> 778: responderURI, issuerInfo, responderCert, null, >> 779: rp.ocspNonce ? tmpExtensions : ocspExtensions, params.variant()); > > Here you can just pass in `ocspExtensions` since it will contain the nonce if the property has been set. No change as tmpExtensions is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From mullan at openjdk.java.net Wed Jan 20 21:00:54 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Jan 2021 21:00:54 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v5] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 19:37:10 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Add nonce to the list of extensions Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 762: > 760: } > 761: > 762: tmpExtensions.add(nonceExt); If you only need the nonce, you could use List.of and save a little bit of memory, ex: if (ocspExtensions.size() > 0) { tmpExtensions = new ArrayList(ocspExtensions); tmpExtensions.add(nonceExt); } else { tmpExtensions = List.of(nonceExt); } ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 21:37:10 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 21:37:10 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v6] In-Reply-To: References: Message-ID: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Change to save memory by List.of ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/a14a2bdb..b4b3a485 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 21:37:11 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 21:37:11 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v5] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:57:49 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add nonce to the list of extensions > > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 762: > >> 760: } >> 761: >> 762: tmpExtensions.add(nonceExt); > > If you only need the nonce, you could use List.of and save a little bit of memory, ex: > > if (ocspExtensions.size() > 0) { > tmpExtensions = new ArrayList(ocspExtensions); > tmpExtensions.add(nonceExt); > } else { > tmpExtensions = List.of(nonceExt); > } Thanks for the review. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From mullan at openjdk.java.net Wed Jan 20 21:42:53 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Jan 2021 21:42:53 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v6] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 21:37:10 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Change to save memory by List.of src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 749: > 747: } > 748: > 749: List tmpExtensions = Collections.emptyList(); One other comment - I think you can just set this to null. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 21:57:13 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 21:57:13 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v7] In-Reply-To: References: Message-ID: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Set tmpExtensions to null instead of using emptyList() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2039/files - new: https://git.openjdk.java.net/jdk/pull/2039/files/b4b3a485..b334a5d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2039&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 21:57:14 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 21:57:14 GMT Subject: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension [v6] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 21:40:12 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Change to save memory by List.of > > src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 749: > >> 747: } >> 748: >> 749: List tmpExtensions = Collections.emptyList(); > > One other comment - I think you can just set this to null. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From hchao at openjdk.java.net Wed Jan 20 22:27:56 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 20 Jan 2021 22:27:56 GMT Subject: Integrated: 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 21:41:56 GMT, Hai-May Chao wrote: > This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. > > Please review the CSR at: > https://bugs.openjdk.java.net/browse/JDK-8257766 This pull request has now been integrated. Changeset: 8b95d954 Author: Hai-May Chao Committer: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/8b95d954 Stats: 83 lines in 5 files changed: 59 ins; 6 del; 18 mod 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Reviewed-by: jnimeh, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2039 From redestad at openjdk.java.net Wed Jan 20 23:48:55 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 20 Jan 2021 23:48:55 GMT Subject: Integrated: 8259498: Reduce overhead of MD5 and SHA digests In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 2714.307 ? 21.133 ops/ms > MessageDigests.digest MD5 1024 15 318.087 ? 0.637 ops/ms > MessageDigests.digest SHA-1 16 15 1387.266 ? 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 109.273 ? 0.149 ops/ms > MessageDigests.digest SHA-256 16 15 995.566 ? 21.186 ops/ms > MessageDigests.digest SHA-256 1024 15 89.104 ? 0.079 ops/ms > MessageDigests.digest SHA-512 16 15 803.030 ? 15.722 ops/ms > MessageDigests.digest SHA-512 1024 15 115.611 ? 0.234 ops/ms > MessageDigests.getAndDigest MD5 16 15 2190.367 ? 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 302.903 ? 1.809 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1262.656 ? 43.751 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 104.889 ? 3.554 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 914.541 ? 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 85.708 ? 1.394 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 737.719 ? 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.307 ? 1.950 ops/ms > > GC: > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 312.011 ? 0.005 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.020 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 544.019 ? 0.016 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 1056.037 ? 0.003 B/op > > Target: > Benchmark (digesterName) (length) Cnt Score Error Units > MessageDigests.digest MD5 16 15 3134.462 ? 43.685 ops/ms > MessageDigests.digest MD5 1024 15 323.667 ? 0.633 ops/ms > MessageDigests.digest SHA-1 16 15 1418.742 ? 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 110.178 ? 0.788 ops/ms > MessageDigests.digest SHA-256 16 15 1037.949 ? 21.214 ops/ms > MessageDigests.digest SHA-256 1024 15 89.671 ? 0.228 ops/ms > MessageDigests.digest SHA-512 16 15 812.028 ? 39.489 ops/ms > MessageDigests.digest SHA-512 1024 15 116.738 ? 0.249 ops/ms > MessageDigests.getAndDigest MD5 16 15 2314.379 ? 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 307.835 ? 5.730 ops/ms > MessageDigests.getAndDigest SHA-1 16 15 1326.887 ? 63.263 ops/ms > MessageDigests.getAndDigest SHA-1 1024 15 106.611 ? 2.292 ops/ms > MessageDigests.getAndDigest SHA-256 16 15 961.589 ? 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 88.646 ? 0.194 ops/ms > MessageDigests.getAndDigest SHA-512 16 15 775.417 ? 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 112.904 ? 2.014 ops/ms > > GC > MessageDigests.getAndDigest:?gc.alloc.rate.norm MD5 16 15 232.009 ? 0.006 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-1 16 15 584.021 ? 0.001 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-256 16 15 272.012 ? 0.015 B/op > MessageDigests.getAndDigest:?gc.alloc.rate.norm SHA-512 16 15 400.017 ? 0.019 B/op > > For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. > > For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. > > I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. This pull request has now been integrated. Changeset: 35c9da70 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/35c9da70 Stats: 655 lines in 8 files changed: 79 ins; 350 del; 226 mod 8259498: Reduce overhead of MD5 and SHA digests Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/1855 From jwilhelm at openjdk.java.net Thu Jan 21 04:41:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 04:41:15 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259757: add a regression test for 8259353 and 8259601 - 8259732: JDK 16 L10n resource file update - msg drop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2176/files Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/2176.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176 PR: https://git.openjdk.java.net/jdk/pull/2176 From jwilhelm at openjdk.java.net Thu Jan 21 05:26:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 05:26:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com> On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 133bcb09 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/133bcb09 Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2176 From fguallini at openjdk.java.net Thu Jan 21 11:21:08 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 21 Jan 2021 11:21:08 GMT Subject: RFR: 8244411: javax/net/ssl/TLSCommon/CipherSuite.java should cover DTLS protocols Message-ID: test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java only indicates which TLS protocols support a cipher suite. It should also indicate which DTLS protocols support a cipher suite. ------------- Commit messages: - remove not used protocols - rename vars - Merge branch 'master' into 8244411 - update legal year - update legal year and remove comments - add indication of which DTLS protocols support a cipher suite Changes: https://git.openjdk.java.net/jdk/pull/2182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244411 Stats: 140 lines in 2 files changed: 24 ins; 4 del; 112 mod Patch: https://git.openjdk.java.net/jdk/pull/2182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2182/head:pull/2182 PR: https://git.openjdk.java.net/jdk/pull/2182 From fguallini at openjdk.java.net Thu Jan 21 12:57:59 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 21 Jan 2021 12:57:59 GMT Subject: Withdrawn: 8244411: javax/net/ssl/TLSCommon/CipherSuite.java should cover DTLS protocols In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 11:15:20 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java only indicates which TLS protocols support a cipher suite. > It should also indicate which DTLS protocols support a cipher suite. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2182 From weijun at openjdk.java.net Thu Jan 21 16:23:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 21 Jan 2021 16:23:21 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - rsa - Merge - 8258915: More temporary buffer cleanup 8258915: More temporary buffer cleanup ------------- Changes: https://git.openjdk.java.net/jdk/pull/2070/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=01 Stats: 1666 lines in 53 files changed: 795 ins; 429 del; 442 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Jan 21 16:28:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 21 Jan 2021 16:28:30 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Thu, 14 Jan 2021 02:52:08 GMT, Weijun Wang wrote: >> please add noreg label to the JBS bug. > >> please add noreg label to the JBS bug. > > Added. Thanks. Just pushed a new commit. First I merged into the RSA PKCS #1 code change from @valeriepeng, and then reapplied the cleanup to `RSAKeyFactory`. Most new code change is inside `RSAPrivateCrtKeyImpl`. I also updated `DerValue` and `DerOutpuStream` a little to avoid unnecessary array copying. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From cverghese at openjdk.java.net Thu Jan 21 17:30:54 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Jan 2021 17:30:54 GMT Subject: RFR: 8259662: SocketException should be passed through [v3] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add error handling guidelines ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/da98249d..4e715ba9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=01-02 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Thu Jan 21 18:42:28 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Jan 2021 18:42:28 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v4] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Add error handling guidelines - Fix bugids and use server port passed as a parameter - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl ------------- Changes: https://git.openjdk.java.net/jdk/pull/2057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=03 Stats: 499 lines in 7 files changed: 490 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From xuelei.fan at oracle.com Thu Jan 21 18:56:48 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Thu, 21 Jan 2021 18:56:48 +0000 Subject: CFV: New JDK Committer: Hai-May Chao In-Reply-To: <117acb29-a5ac-de36-7f13-8c519691ad23@oracle.com> References: <117acb29-a5ac-de36-7f13-8c519691ad23@oracle.com> Message-ID: <0A76D11B-A822-435C-B1E1-94D66A34D155@ORACLE.COM> Vote: yes. Xuelei > On Jan 21, 2021, at 10:36 AM, sean.mullan at oracle.com wrote: > > I hereby nominate Hai-May Chao to JDK Committer. > > Hai-May is a member of the Java Security Libraries team at Oracle. She has contributed 13 fixes [0][1] to the JDK which span a wide range of security functionality, including significant changes in TLS, OCSP, and security tools (keytool and jarsigner). > > Votes are due by 19:00 UTC, 4th February 2021. > > Only current JDK Committers [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]. > > Sean Mullan > > [0] https://github.com/openjdk/jdk/search?q=author-name%3A%22Hai-may%20Chao%22&type=commits > [1] https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22Hai-May%20Chao%22&type=commits > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From mullan at openjdk.java.net Thu Jan 21 19:47:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 21 Jan 2021 19:47:43 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > Correction of NPE and updating of test cases. Minor refactoring of test library also. src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 248: > 246: int anchorCertId = 0; > 247: X509Certificate trustedCert = anchor.getTrustedCert(); > 248: if (trustedCert != null) { You could use the `anchorCert` variable which was set earlier instead of calling `getTrustedCert()` again. src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 251: > 249: anchorCertId = trustedCert.hashCode(); > 250: } else { > 251: if (anchor.getCAPublicKey() != null) { Per the TrustAnchor API, you can't create a TrustAnchor with a null public key, so I don't think you need this check. ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From valeriep at openjdk.java.net Fri Jan 22 02:16:01 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 02:16:01 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v7] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 13:51:56 GMT, Martin Balao wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to 'P11Cipher::implDoFinal(ByteBuffer..'. Better documentation in P11Cipher. Copyright date updated. >> - Copyright dates updated to 2021 on modified files > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 793: > >> 791: // only after this point. See JDK-8258833 for further >> 792: // information. >> 793: doCancel = false; > > @valeriepeng I made a code change here so I'd like you to have a final look and validate. I'm just aligning the 'P11Cipher::implDoFinal(byte[]..' function to 'P11Cipher::implDoFinal(ByteBuffer..'. The rationale is that 'doFalse = false' can be placed before the C_EncryptFinal call because any error on it does not require a cancel (it already cancels the operation) Yes, aligning them is better. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 22 02:22:14 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 02:22:14 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v7] In-Reply-To: References: Message-ID: <9L-VQ-X_c_nY0SaNu3eG6SRCgB-AXcuRI1gt14-9srA=.a0a0097d-d2fc-4d64-b3ee-b4bcbe17b3b2@github.com> On Wed, 20 Jan 2021 13:52:26 GMT, Martin Balao wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to 'P11Cipher::implDoFinal(ByteBuffer..'. Better documentation in P11Cipher. Copyright date updated. >> - Copyright dates updated to 2021 on modified files > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 812: > >> 810: // only after this point. See JDK-8258833 for further >> 811: // information. >> 812: doCancel = false; > > Same comment that for line 793 of P11Cipher Yes, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 22 07:08:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 07:08:45 GMT Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v7] In-Reply-To: References: Message-ID: <0mdlGmmf3XGc4-DUmizwz6nIgMeeDLs863QK5j4bJLg=.51e43bb6-9395-4b88-b18c-4f5190ab1c72@github.com> On Wed, 20 Jan 2021 13:47:13 GMT, Martin Balao wrote: >> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. >> >> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. >> >> No regressions found in jdk/sun/security/pkcs11. > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Align doCancel pattern in 'P11Cipher::implDoFinal(byte[]..' to 'P11Cipher::implDoFinal(ByteBuffer..'. Better documentation in P11Cipher. Copyright date updated. > - Copyright dates updated to 2021 on modified files Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From valeriep at openjdk.java.net Fri Jan 22 07:14:20 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 07:14:20 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - rsa > - Merge > - 8258915: More temporary buffer cleanup > > 8258915: More temporary buffer cleanup src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java line 163: > 161: } > 162: Arrays.fill(encoding, (byte)0); > 163: spec.clearPassword(); nit: move to inside the if-check block above? src/java.base/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java line 163: > 161: } > 162: Arrays.fill(encoding, (byte)0); > 163: spec.clearPassword(); same nit: move to inside of the if-check block. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Fri Jan 22 07:21:33 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 07:21:33 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - rsa > - Merge > - 8258915: More temporary buffer cleanup > > 8258915: More temporary buffer cleanup src/java.base/share/classes/com/sun/crypto/provider/PrivateKeyInfo.java line 98: > 96: > 97: public void clear() { > 98: Arrays.fill(privkey, (byte)0); check for null just in case? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Fri Jan 22 07:50:54 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 07:50:54 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - rsa > - Merge > - 8258915: More temporary buffer cleanup > > 8258915: More temporary buffer cleanup src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 234: > 232: encodedKey = out.toByteArray(); > 233: // Copy the actual bytes > 234: System.arraycopy(key, 0, encodedKey, encodedKey.length - key.length, key.length); I think this can now be updated with the newer DerValue.wrap(....) then DerValue.clear() approach? src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 676: > 674: // effectively once required. > 675: secretKeyInfo.putOctetString(new byte[encoded.length]); > 676: pkcs8.write(DerValue.tag_Sequence, secretKeyInfo); Same as earlier comment - can switch to DerValue.wrap() and then clear() approach? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Fri Jan 22 08:21:59 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 08:21:59 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: <6ETiYfPLPGpwPHeu0bTO0oolB9JeiJ4G8uGvnK2RPZE=.a248c237-112e-42b1-9d0a-6d4ee321694d@github.com> On Thu, 21 Jan 2021 16:23:21 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - rsa > - Merge > - 8258915: More temporary buffer cleanup > > 8258915: More temporary buffer cleanup src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 233: > 231: DerValue val = DerValue.wrap(DerValue.tag_Sequence, out); > 232: key = val.toByteArray(); > 233: val.clear(); Update RSAPrivateKeyImpl.java also for consistency sake? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From sean.coffey at oracle.com Fri Jan 22 13:13:55 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 22 Jan 2021 13:13:55 +0000 Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: <2195f270-b3d9-f92d-35ec-e83e3c93b883@oracle.com> Thanks for the comments Sean. Code updated. https://github.com/openjdk/jdk/pull/2150/commits/8a344a85303297f17a6e75e7c1f423c2d16c451a regards, Sean. On 21/01/2021 19:47, Sean Mullan wrote: > On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > >> Correction of NPE and updating of test cases. Minor refactoring of test library also. > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 248: > >> 246: int anchorCertId = 0; >> 247: X509Certificate trustedCert = anchor.getTrustedCert(); >> 248: if (trustedCert != null) { > You could use the `anchorCert` variable which was set earlier instead of calling `getTrustedCert()` again. > > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 251: > >> 249: anchorCertId = trustedCert.hashCode(); >> 250: } else { >> 251: if (anchor.getCAPublicKey() != null) { > Per the TrustAnchor API, you can't create a TrustAnchor with a null public key, so I don't think you need this check. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2150 From coffeys at openjdk.java.net Fri Jan 22 13:15:17 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 22 Jan 2021 13:15:17 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code [v2] In-Reply-To: References: Message-ID: > Correction of NPE and updating of test cases. Minor refactoring of test library also. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Sean Mullan review update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2150/files - new: https://git.openjdk.java.net/jdk/pull/2150/files/a59dd592..8a344a85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150 From weijun at openjdk.java.net Fri Jan 22 14:41:10 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 14:41:10 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 07:18:22 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - rsa >> - Merge >> - 8258915: More temporary buffer cleanup >> >> 8258915: More temporary buffer cleanup > > src/java.base/share/classes/com/sun/crypto/provider/PrivateKeyInfo.java line 98: > >> 96: >> 97: public void clear() { >> 98: Arrays.fill(privkey, (byte)0); > > check for null just in case? `val.data.getOctetString()` on line 82 should never return null, so I think a null check is not necessary here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From mullan at openjdk.java.net Fri Jan 22 14:41:50 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 22 Jan 2021 14:41:50 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 13:15:17 GMT, Sean Coffey wrote: >> Correction of NPE and updating of test cases. Minor refactoring of test library also. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Sean Mullan review update Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From weijun at openjdk.java.net Fri Jan 22 14:54:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 14:54:45 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 07:44:41 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - rsa >> - Merge >> - 8258915: More temporary buffer cleanup >> >> 8258915: More temporary buffer cleanup > > src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 234: > >> 232: encodedKey = out.toByteArray(); >> 233: // Copy the actual bytes >> 234: System.arraycopy(key, 0, encodedKey, encodedKey.length - key.length, key.length); > > I think this can now be updated with the newer DerValue.wrap(....) then DerValue.clear() approach? Good idea! ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Fri Jan 22 14:57:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Jan 2021 14:57:40 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 14:35:46 GMT, Weijun Wang wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PrivateKeyInfo.java line 98: >> >>> 96: >>> 97: public void clear() { >>> 98: Arrays.fill(privkey, (byte)0); >> >> check for null just in case? > > `val.data.getOctetString()` on line 82 should never return null, so I think a null check is not necessary here. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Jan 22 15:19:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 15:19:44 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v2] In-Reply-To: <6ETiYfPLPGpwPHeu0bTO0oolB9JeiJ4G8uGvnK2RPZE=.a248c237-112e-42b1-9d0a-6d4ee321694d@github.com> References: <6ETiYfPLPGpwPHeu0bTO0oolB9JeiJ4G8uGvnK2RPZE=.a248c237-112e-42b1-9d0a-6d4ee321694d@github.com> Message-ID: On Fri, 22 Jan 2021 08:18:15 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - rsa >> - Merge >> - 8258915: More temporary buffer cleanup >> >> 8258915: More temporary buffer cleanup > > src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 233: > >> 231: DerValue val = DerValue.wrap(DerValue.tag_Sequence, out); >> 232: key = val.toByteArray(); >> 233: val.clear(); > > Update RSAPrivateKeyImpl.java also for consistency sake? Good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From coffeys at openjdk.java.net Fri Jan 22 15:34:41 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 22 Jan 2021 15:34:41 GMT Subject: Integrated: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: <2hqGUlO6rON1q2LX8p86ol_YA1BsSvDLV2oxtgQMsuo=.a3b4a0e7-cf57-47d7-a393-929c8a3a1091@github.com> On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > Correction of NPE and updating of test cases. Minor refactoring of test library also. This pull request has now been integrated. Changeset: 18eb6d9e Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/18eb6d9e Stats: 77 lines in 6 files changed: 53 ins; 2 del; 22 mod 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From weijun at openjdk.java.net Fri Jan 22 15:43:05 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 15:43:05 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v3] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more wrap, less copy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/7129df6a..b7216061 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=01-02 Stats: 50 lines in 7 files changed: 12 ins; 23 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Jan 22 15:43:06 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 15:43:06 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Thu, 21 Jan 2021 16:25:13 GMT, Weijun Wang wrote: >>> please add noreg label to the JBS bug. >> >> Added. Thanks. > > Just pushed a new commit. First I merged into the RSA PKCS #1 code change from @valeriepeng, and then reapplied the cleanup to `RSAKeyFactory`. Most new code change is inside `RSAPrivateCrtKeyImpl`. I also updated `DerValue` and `DerOutpuStream` a little to avoid unnecessary array copying. New commit. However, I was writing test to detect leak in `RSAPrivateKeySpec` conversion and add more key->spec->key for other algorithms and find more leaks. Will fix in another commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From xuelei at openjdk.java.net Fri Jan 22 16:40:38 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 22 Jan 2021 16:40:38 GMT Subject: RFR: 8217633: Configurable extensions with system properties In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 23:20:34 GMT, Xue-Lei Andrew Fan wrote: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From mullan at openjdk.java.net Fri Jan 22 17:34:49 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 22 Jan 2021 17:34:49 GMT Subject: RFR: 8259801: Enable XML Signature secure validation mode by default Message-ID: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> This change enables the XML Signature secure validation mode by default. This will improve out of the box security by restricting signatures that contain potentially unsafe content by default. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 ------------- Commit messages: - Minor re-wording of implNote. - Initial fix. Changes: https://git.openjdk.java.net/jdk/pull/2197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259801 Stats: 55 lines in 3 files changed: 12 ins; 3 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/2197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2197/head:pull/2197 PR: https://git.openjdk.java.net/jdk/pull/2197 From rriggs at openjdk.java.net Fri Jan 22 20:00:56 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 22 Jan 2021 20:00:56 GMT Subject: RFR: 8217633: Configurable extensions with system properties In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 23:20:34 GMT, Xue-Lei Andrew Fan wrote: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Where will the new properties be documented? In the CSR, it may be worth mentioning that the extension names are case sensitive. ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From akozlov at openjdk.java.net Fri Jan 22 20:02:56 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 22 Jan 2021 20:02:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port Message-ID: Please review the implementation of JEP 391: macOS/AArch64 Port. It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. Major changes are in: * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) ------------- Commit messages: - Fix build - JDK-8253816: Update after recent changes - Rework gtests to always have wx_write - Revert gtest changes - Fix gtests in debug - Merge remote-tracking branch 'upstream/master' into jdk-macos - Fix windows_aarch64 - Use r18_tls instead of r18_reserved - JDK-8253742: bsd_aarch64 part - JDK-8257882: bsd_aarch64 part - ... and 40 more: https://git.openjdk.java.net/jdk/compare/82adfb32...3d4f4c23 Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253795 Stats: 3335 lines in 117 files changed: 3230 ins; 41 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From xuelei at openjdk.java.net Fri Jan 22 20:22:41 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 22 Jan 2021 20:22:41 GMT Subject: RFR: 8217633: Configurable extensions with system properties In-Reply-To: References: Message-ID: <8j2KeSqC77Fc1E8xl_cg4zMP6HbMqooyRXxaXAGuBQg=.848408f8-d61f-4cd1-ab2d-c0dd7dd17a94@github.com> On Fri, 22 Jan 2021 19:07:48 GMT, Roger Riggs wrote: > Where will the new properties be documented? > Yes. The properties will be described in the JSSE Reference Guide. I added a "Documentation" section in the CSR. > In the CSR, it may be worth mentioning that the extension names are case sensitive. Good point. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From erikj at openjdk.java.net Fri Jan 22 20:27:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Jan 2021 20:27:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port In-Reply-To: References: Message-ID: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Build changes in general look good. make/autoconf/flags-cflags.m4 line 169: > 167: WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL" > 168: > 169: DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral" Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Fri Jan 22 21:28:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 21:28:53 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: keyfactory operations on own keyspec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/b7216061..9b17b1a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=02-03 Stats: 57 lines in 7 files changed: 34 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Jan 22 21:28:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Jan 2021 21:28:54 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Fri, 22 Jan 2021 15:39:53 GMT, Weijun Wang wrote: >> Just pushed a new commit. First I merged into the RSA PKCS #1 code change from @valeriepeng, and then reapplied the cleanup to `RSAKeyFactory`. Most new code change is inside `RSAPrivateCrtKeyImpl`. I also updated `DerValue` and `DerOutpuStream` a little to avoid unnecessary array copying. > > New commit. However, I was writing test to detect leak in `RSAPrivateKeySpec` conversion and add more key->spec->key for other algorithms and find more leaks. Will fix in another commit. Another new commit. Last time I only fixed KeySpec on PKCS8 format. This time it's for an algorithm's _own_ spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From jwilhelm at openjdk.java.net Sat Jan 23 02:19:01 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 23 Jan 2021 02:19:01 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" - 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation - 8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation - 8255199: Catching a few NumberFormatExceptions in xmldsig - 8247619: Improve Direct Buffering of Characters The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2207&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2207&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2207/files Stats: 131 lines in 11 files changed: 111 ins; 4 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2207/head:pull/2207 PR: https://git.openjdk.java.net/jdk/pull/2207 From jwilhelm at openjdk.java.net Sat Jan 23 03:19:42 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 23 Jan 2021 03:19:42 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 02:13:06 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 6f2a3943 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/6f2a3943 Stats: 131 lines in 11 files changed: 111 ins; 4 del; 16 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2207 From valeriep at openjdk.java.net Sat Jan 23 04:05:42 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 23 Jan 2021 04:05:42 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 15:43:05 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more wrap, less copy src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 221: > 219: if (encodedKey == null) { > 220: try { > 221: DerOutputStream tmp = new DerOutputStream(); What is the criteria of using the default constructor vs the one with a initial size? Here is using the default, are we sure about the key (line 224 below) will always fit? src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 664: > 662: > 663: // Encode secret key in a PKCS#8 > 664: DerOutputStream secretKeyInfo = new DerOutputStream(); Same, using default constructor here and we write encodedKey into it at line 670 below. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Sat Jan 23 05:12:42 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 23 Jan 2021 05:12:42 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 21:28:53 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > keyfactory operations on own keyspec src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 116: > 114: encode(); > 115: } catch (IOException e) { > 116: throw new ProviderException("Cannot produce ASN.1 encoding", e); Supposedly the IOException should never happen? Otherwise the Arrays.fill(...) call may not happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Sat Jan 23 05:23:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 23 Jan 2021 05:23:44 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: <4dPa0UXMSy5GvOLNtXuVB4xeEG4iX1kxcJb9br0o_iA=.597cac73-f839-4811-b285-64f5c6005913@github.com> On Fri, 22 Jan 2021 21:28:53 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > keyfactory operations on own keyspec src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 133: > 131: out.putInteger(1); // version 1 > 132: out.putOctetString(sOctets); > 133: Arrays.fill(sOctets, (byte)0); The same handling should apply to line 106 above inside makeEncoding(byte[])? src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 136: > 134: DerValue val = DerValue.wrap(DerValue.tag_Sequence, out); > 135: key = val.toByteArray(); > 136: val.clear(); Same handling should apply to line 107-109 above inside makeEncoding(byte[])? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From alanb at openjdk.java.net Sat Jan 23 07:57:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Jan 2021 07:57:43 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? > @AlanBateman When I moved the charset templates, I found this gold nugget: > > ``` > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > ``` > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. Good find, surprised this wasn't spotted before now. We should create a separate issue to rename them and get rid of the copying in the make file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From aph at openjdk.java.net Sat Jan 23 11:46:45 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 23 Jan 2021 11:46:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: > 84: > 85: switch (_num_int_args) { > 86: case 0: I don't think you need such a large switch statement. I think this can be expressed as if (num_int_args <= 6) { ldr(as_Register(num_int_args + 1), src); ... etc. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 43: > 41: //describe amount of space in bytes occupied by type on native stack > 42: #ifdef __APPLE__ > 43: const int nativeByteSpace = sizeof(jbyte); I'm not sure these names should be in the global name space, and they're not very descriptive. Something like NativeStack::byteSpace would be better. Then you can use them with a `using namespace NativeStack` declaration. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433: > 431: store_and_inc(_to, from_obj, nativeShortSpace); > 432: > 433: _num_int_args++; Please lift this increment out of the conditional. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: > 392: > 393: class SlowSignatureHandler > 394: : public NativeSignatureIterator { SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and=paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: > 5270: void MacroAssembler::get_thread(Register dst) { > 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; > 5272: push(saved_regs, sp); This isn't very nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Sat Jan 23 16:07:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 23 Jan 2021 16:07:42 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v3] In-Reply-To: References: Message-ID: <8m6bckoydUYRnnG4V6V7IRZxdRC-LakABYEhmmurg9w=.c23cdb7b-f67c-420b-a891-f00a55ee0e2a@github.com> On Sat, 23 Jan 2021 03:59:12 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more wrap, less copy > > src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 221: > >> 219: if (encodedKey == null) { >> 220: try { >> 221: DerOutputStream tmp = new DerOutputStream(); > > What is the criteria of using the default constructor vs the one with a initial size? Here is using the default, are we sure about the key (line 224 below) will always fit? Here the key is the last thing to be written into the DerOutputStream, so there will be no more reallocation after and its content will not be leaked. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 664: > >> 662: >> 663: // Encode secret key in a PKCS#8 >> 664: DerOutputStream secretKeyInfo = new DerOutputStream(); > > Same, using default constructor here and we write encodedKey into it at line 670 below. Same as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Sat Jan 23 16:18:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 23 Jan 2021 16:18:40 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 05:09:46 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> keyfactory operations on own keyspec > > src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 116: > >> 114: encode(); >> 115: } catch (IOException e) { >> 116: throw new ProviderException("Cannot produce ASN.1 encoding", e); > > Supposedly the IOException should never happen? Otherwise the Arrays.fill(...) call may not happen. Some throws AssertionError wrapping the IOException, just checking to see this is also the case. No, it should never happen. `DerValue::toByteArray` claims it might throw an IOE because `DerOutputStream::putLength` claims so, but you can see the latter never throws one. I thought about removing those `throws IOE` but there are too many. We can do it in another code change. > src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 133: > >> 131: out.putInteger(1); // version 1 >> 132: out.putOctetString(sOctets); >> 133: Arrays.fill(sOctets, (byte)0); > > The same handling should apply to line 106 above inside makeEncoding(byte[])? I'll take a look. The test does not show it. Maybe because of the reversing? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Sat Jan 23 16:34:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 23 Jan 2021 16:34:41 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: <24qb98s0Aq5fP5k18eSP8J4VI5HjjyHAyvcyUbRUfZQ=.314d9664-9349-4751-be74-5aa5ecf2fab2@github.com> On Sat, 23 Jan 2021 16:12:43 GMT, Weijun Wang wrote: >> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 133: >> >>> 131: out.putInteger(1); // version 1 >>> 132: out.putOctetString(sOctets); >>> 133: Arrays.fill(sOctets, (byte)0); >> >> The same handling should apply to line 106 above inside makeEncoding(byte[])? > > I'll take a look. The test does not show it. Maybe because of the reversing? I found out the reason. This method is called during key pair generation but my test only deals with manually crafted keys (so that I know what special bytes to search for). I think I'll need to find out a different test method. This might reveal other leaks in key generation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From akozlov at openjdk.java.net Sun Jan 24 15:32:59 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:32:59 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Address feedback for signature generators - Enable -Wformat-nonliteral back ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3d4f4c23..50b55f66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00-01 Stats: 204 lines in 2 files changed: 20 ins; 138 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 15:37:43 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:37:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> References: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> Message-ID: On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/autoconf/flags-cflags.m4 line 169: > >> 167: WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL" >> 168: >> 169: DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral" > > Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered? It seems to be a leftover from the past. I tried to revert the line and the build went fine. Thanks for noticing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 15:52:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:52:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: > >> 84: >> 85: switch (_num_int_args) { >> 86: case 0: > > I don't think you need such a large switch statement. I think this can be expressed as > if (num_int_args <= 6) { > ldr(as_Register(num_int_args + r1.encoding()), src); > ... etc. I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 16:13:42 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 16:13:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: > >> 392: >> 393: class SlowSignatureHandler >> 394: : public NativeSignatureIterator { > > SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Sun Jan 24 16:32:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Sun, 24 Jan 2021 16:32:41 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: > >> 5270: void MacroAssembler::get_thread(Register dst) { >> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >> 5272: push(saved_regs, sp); > > This isn't very nice. Hello Why is it not nice ? linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s which clobbers only r0 and r1 macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); Hence we are saving possibly clobbered regs here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Mon Jan 25 10:00:41 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 10:00:41 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: >> >>> 392: >>> 393: class SlowSignatureHandler >>> 394: : public NativeSignatureIterator { >> >> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. > > Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Mon Jan 25 10:00:43 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 10:00:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: >> >>> 5270: void MacroAssembler::get_thread(Register dst) { >>> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >>> 5272: push(saved_regs, sp); >> >> This isn't very nice. > > Hello > Why is it not nice ? > linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s > which clobbers only r0 and r1 > macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); > Hence we are saving possibly clobbered regs here. Surely if you did as Linux does you wouldn't need to clobber all those registers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From valeriep at openjdk.java.net Mon Jan 25 11:37:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 25 Jan 2021 11:37:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v3] In-Reply-To: <8m6bckoydUYRnnG4V6V7IRZxdRC-LakABYEhmmurg9w=.c23cdb7b-f67c-420b-a891-f00a55ee0e2a@github.com> References: <8m6bckoydUYRnnG4V6V7IRZxdRC-LakABYEhmmurg9w=.c23cdb7b-f67c-420b-a891-f00a55ee0e2a@github.com> Message-ID: On Sat, 23 Jan 2021 16:04:53 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 221: >> >>> 219: if (encodedKey == null) { >>> 220: try { >>> 221: DerOutputStream tmp = new DerOutputStream(); >> >> What is the criteria of using the default constructor vs the one with a initial size? Here is using the default, are we sure about the key (line 224 below) will always fit? > > Here the key is the last thing to be written into the DerOutputStream, so there will be no more reallocation after and its content will not be leaked. I see. Interesting... ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Mon Jan 25 11:37:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 25 Jan 2021 11:37:45 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 16:11:02 GMT, Weijun Wang wrote: >> src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 116: >> >>> 114: encode(); >>> 115: } catch (IOException e) { >>> 116: throw new ProviderException("Cannot produce ASN.1 encoding", e); >> >> Supposedly the IOException should never happen? Otherwise the Arrays.fill(...) call may not happen. Some throws AssertionError wrapping the IOException, just checking to see this is also the case. > > No, it should never happen. `DerValue::toByteArray` claims it might throw an IOE because `DerOutputStream::putLength` claims so, but you can see the latter never throws one. I thought about removing those `throws IOE` but there are too many. We can do it in another code change. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Mon Jan 25 11:37:47 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 25 Jan 2021 11:37:47 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v4] In-Reply-To: <24qb98s0Aq5fP5k18eSP8J4VI5HjjyHAyvcyUbRUfZQ=.314d9664-9349-4751-be74-5aa5ecf2fab2@github.com> References: <24qb98s0Aq5fP5k18eSP8J4VI5HjjyHAyvcyUbRUfZQ=.314d9664-9349-4751-be74-5aa5ecf2fab2@github.com> Message-ID: On Sat, 23 Jan 2021 16:32:16 GMT, Weijun Wang wrote: >> I'll take a look. The test does not show it. Maybe because of the reversing? > > I found out the reason. This method is called during key pair generation but my test only deals with manually crafted keys (so that I know what special bytes to search for). I think I'll need to find out a different test method. This might reveal other leaks in key generation. Yes, your approach is based on the test and the code path it exercised. I manually code inspected the files that you touched. Even with both approaches, it's still not gonna be 100%. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From ihse at openjdk.java.net Mon Jan 25 13:25:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 13:25:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back Changes requested by ihse (Reviewer). make/autoconf/jvm-features.m4 line 269: > 267: if test "x$OPENJDK_TARGET_OS" != xaix && \ > 268: !( test "x$OPENJDK_TARGET_OS" = "xmacosx" && \ > 269: test "x$OPENJDK_TARGET_CPU" = "xaarch64" ) ; then This test is making my head spin. Can't you just invert it to this structure: if OS=aix || OS+CPU = mac+aarch64; then no else yes fi make/autoconf/platform.m4 line 75: > 73: ;; > 74: esac > 75: ;; This is solved in the wrong place. This code should just use the result from `config.guess/config.sub`. These files are imported from the autoconf project. Unfortunately, they have changed the license to one incompatible with OpenJDK, so we are stuck with an old version. Instead, we have created a "bugfix wrapper" that calls the original `autoconf-config.guess/sub` and fixes up the result, with stuff like this. make/autoconf/platform.m4 line 273: > 271: # Convert the autoconf OS/CPU value to our own data, into the VAR_OS/CPU/LIBC variables. > 272: PLATFORM_EXTRACT_VARS_FROM_OS($build_os) > 273: PLATFORM_EXTRACT_VARS_FROM_CPU($build_cpu, $build_os) Fixing the comment above means this change, and the one below, can be reverted. make/common/NativeCompilation.gmk line 1180: > 1178: # silently fail otherwise. > 1179: ifneq ($(CODESIGN), ) > 1180: $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \ What does -f do, and is it needed for macos-x64 as well? make/modules/jdk.hotspot.agent/Lib.gmk line 34: > 32: > 33: else ifeq ($(call isTargetOs, macosx), true) > 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 13:33:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 13:33:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/common/NativeCompilation.gmk line 1180: > >> 1178: # silently fail otherwise. >> 1179: ifneq ($(CODESIGN), ) >> 1180: $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \ > > What does -f do, and is it needed for macos-x64 as well? -f - replace signature if it's present, if not - just sign as usual macos-aarch64 binaries always have adhoc signature, so need to replace it. > make/modules/jdk.hotspot.agent/Lib.gmk line 34: > >> 32: >> 33: else ifeq ($(call isTargetOs, macosx), true) >> 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ > > Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). @luhenry , could you please check this comment, I think SA-agent was MS's job here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 14:09:44 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 14:09:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden wrote: > In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that? because it does not work processor_id has no "official docs"-friendly implementation, only a hacky one from ios world. Also ZGC needs additional W^X work. I believe zgc supports needs to be done in a separate commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From pliden at openjdk.java.net Mon Jan 25 14:06:46 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 25 Jan 2021 14:06:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > Changes requested by ihse (Reviewer). In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 14:39:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:39:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: > 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); > 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; > 87: Thread::WXWriteFromExecSetter wx_write; Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 14:43:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:43:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back src/hotspot/share/runtime/thread.hpp line 915: > 913: verify_wx_state(WXExec); > 914: } > 915: }; Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 14:43:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:43:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> Message-ID: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/share/runtime/thread.hpp line 915: > >> 913: verify_wx_state(WXExec); >> 914: } >> 915: }; > > Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? This could be a follow-up RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Jan 25 15:03:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 15:03:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: > >> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >> 87: Thread::WXWriteFromExecSetter wx_write; > > Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Mon Jan 25 16:02:45 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 25 Jan 2021 16:02:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik wrote: >> make/modules/jdk.hotspot.agent/Lib.gmk line 34: >> >>> 32: >>> 33: else ifeq ($(call isTargetOs, macosx), true) >>> 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ >> >> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). > > @luhenry , could you please check this comment, I think SA-agent was MS's job here. The target is identified by the header file now: https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41 Do you think there is any problem with this approach? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From fguallini at openjdk.java.net Mon Jan 25 17:13:53 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Mon, 25 Jan 2021 17:13:53 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails Message-ID: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification ------------- Commit messages: - rename method - handle warning for SHA-1 weak algorithm Changes: https://git.openjdk.java.net/jdk/pull/2224/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260286 Stats: 19 lines in 2 files changed: 17 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2224/head:pull/2224 PR: https://git.openjdk.java.net/jdk/pull/2224 From aph at openjdk.java.net Mon Jan 25 17:21:46 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 17:21:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: >> >>> 84: >>> 85: switch (_num_int_args) { >>> 86: case 0: >> >> I don't think you need such a large switch statement. I think this can be expressed as >> if (num_int_args <= 6) { >> ldr(as_Register(num_int_args + r1.encoding()), src); >> ... etc. > > I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 17:45:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 17:45:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back Changes requested by prr (Reviewer). src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: > 111: > 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) > 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) I need a robust explanation of these changes. They are not mentioned, nor are they in upstream harfbuzz. Likely these should be pushed to upstream first if there is a reason for them. src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193: > 191: * crbug.com/549610 */ > 192: // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h > 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10 I need a robust explanation of these changes. They are not mentioned, nor are they in upstream harfbuzz. Likely these should be pushed to upstream first if there is a reason for them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Jan 25 17:45:47 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 17:45:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley wrote: >> Hello >> Why is it not nice ? >> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s >> which clobbers only r0 and r1 >> macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); >> Hence we are saving possibly clobbered regs here. > > Surely if you did as Linux does you wouldn't need to clobber all those registers. I see how this can be done, from looking at C example with `__thread`, which involves poorly documented relocations and private libc interface invocation. But now I also wonder how much benefit would we have from this optimization. `get_thread` is called from few places and all of them are guarded by `#ifdef ASSERT`. The release build is still fine after I removed MacroAssembler::get_thread definition (as a verification). Callers of get_thread: * StubAssembler::call_RT * Runtime1::generate_patching * StubGenerator::generate_call_stub * StubGenerator::generate_catch_exception All of them are heavy-weight functions, nonoptimal get_thread is unlikely to slow them down even in fastdebug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mbalao at openjdk.java.net Mon Jan 25 18:05:46 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Mon, 25 Jan 2021 18:05:46 GMT Subject: Integrated: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote: > When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library. > > The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR. > > No regressions found in jdk/sun/security/pkcs11. This pull request has now been integrated. Changeset: 47c7dc77 Author: Martin Balao URL: https://git.openjdk.java.net/jdk/commit/47c7dc77 Stats: 301 lines in 6 files changed: 286 ins; 8 del; 7 mod 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/1901 From coleenp at openjdk.java.net Mon Jan 25 19:14:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 19:14:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov wrote: >> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: >> >>> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >>> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >>> 87: Thread::WXWriteFromExecSetter wx_write; >> >> Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? > > I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: class ThreadInVMfromNative : public ThreadStateTransition { ResetNoHandleMark __rnhm; We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Jan 25 19:38:16 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 19:38:16 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Refactor CDS disabling - Redo builsys support for aarch64-darwin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/50b55f66..0c2cb0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01-02 Stats: 36 lines in 3 files changed: 12 ins; 15 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 20:50:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 20:50:57 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: > 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ > 572: WARNINGS_AS_ERRORS_xlc := false, \ > 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. I've built JDK using Xcode 12.3 and not had any need for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 21:21:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 21:21:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: > >> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ >> 572: WARNINGS_AS_ERRORS_xlc := false, \ >> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ > > I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. > I've built JDK using Xcode 12.3 and not had any need for this. Hello I believe it was a workaround for issues with xcode 12.2 in early beta days. Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 21:21:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 21:21:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: >> >>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ >>> 572: WARNINGS_AS_ERRORS_xlc := false, \ >>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ >> >> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. >> I've built JDK using Xcode 12.3 and not had any need for this. > > Hello > I believe it was a workaround for issues with xcode 12.2 in early beta days. > Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. It seems these workarounds are still needed: jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat ^~~~~~~~~~~~~~~~~~~~~~~~ NSBitmapFormatAlphaFirst jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] styleMask: NSBorderlessWindowMask ^~~~~~~~~~~~~~~~~~~~~~ NSWindowStyleMaskBorderless ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Mon Jan 25 21:40:42 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 25 Jan 2021 21:40:42 GMT Subject: RFR: 8217633: Configurable extensions with system properties In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 23:20:34 GMT, Xue-Lei Andrew Fan wrote: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Changes requested by rhalade (Reviewer). test/jdk/sun/security/ssl/SSLSocketImpl/BlockedExtension.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. test/jdk/sun/security/ssl/SSLSocketImpl/BlockedExtension.java line 62: > 60: } catch (SSLException | IllegalStateException ssle) { > 61: if (shouldSuccess) { > 62: throw new Exception( Suggestion: throw new RuntimeException( test/jdk/sun/security/ssl/SSLSocketImpl/BlockedExtension.java line 70: > 68: > 69: if (!shouldSuccess) { > 70: throw new Exception( Suggestion: throw new RuntimeException( ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From rhalade at openjdk.java.net Mon Jan 25 21:53:45 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 25 Jan 2021 21:53:45 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails In-Reply-To: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 17:08:45 GMT, Fernando Guallini wrote: > Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From xuelei at openjdk.java.net Mon Jan 25 22:17:56 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Jan 2021 22:17:56 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: Message-ID: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update copyright years to 2021 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1752/files - new: https://git.openjdk.java.net/jdk/pull/1752/files/ad5f3330..5bd6e865 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752 PR: https://git.openjdk.java.net/jdk/pull/1752 From xuelei at openjdk.java.net Mon Jan 25 22:17:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Jan 2021 22:17:57 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 21:32:18 GMT, Rajan Halade wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years to 2021 > > test/jdk/sun/security/ssl/SSLSocketImpl/BlockedExtension.java line 70: > >> 68: >> 69: if (!shouldSuccess) { >> 70: throw new Exception( > > Suggestion: > > throw new RuntimeException( Good catches, the years should be 2021 now. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From jnimeh at openjdk.java.net Mon Jan 25 22:22:43 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 25 Jan 2021 22:22:43 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:17:56 GMT, Xue-Lei Andrew Fan wrote: >> The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. >> >> With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years to 2021 Looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1752 From prr at openjdk.java.net Mon Jan 25 22:24:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 22:24:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik wrote: >> Hello >> I believe it was a workaround for issues with xcode 12.2 in early beta days. >> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. > > It seems these workarounds are still needed: > > jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] > bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat > ^~~~~~~~~~~~~~~~~~~~~~~~ > NSBitmapFormatAlphaFirst > > jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] > styleMask: NSBorderlessWindowMask > ^~~~~~~~~~~~~~~~~~~~~~ > NSWindowStyleMaskBorderless Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. I think we currently target a macOS 10.9 and if you are changing that it would need discussion. If you are changing it only for Mac ARM that may make more sense .. And these appear to be just API churn by Apple NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc NSBorderlessWindowMask is replaced by NSWindowStyleMask https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 22:28:46 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 22:28:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race wrote: >> It seems these workarounds are still needed: >> >> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] >> bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat >> ^~~~~~~~~~~~~~~~~~~~~~~~ >> NSBitmapFormatAlphaFirst >> >> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] >> styleMask: NSBorderlessWindowMask >> ^~~~~~~~~~~~~~~~~~~~~~ >> NSWindowStyleMaskBorderless > > Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. > I think we currently target a macOS 10.9 and if you are changing that it would need discussion. > If you are changing it only for Mac ARM that may make more sense .. > > And these appear to be just API churn by Apple > NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst > > https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc > > NSBorderlessWindowMask is replaced by NSWindowStyleMask > > https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ Min_macos version is changed to 11.0 for macos_aarch64 https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Mon Jan 25 22:29:43 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 25 Jan 2021 22:29:43 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:17:56 GMT, Xue-Lei Andrew Fan wrote: >> The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. >> >> With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years to 2021 Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From prr at openjdk.java.net Mon Jan 25 22:45:42 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 22:45:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik wrote: >> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. >> I think we currently target a macOS 10.9 and if you are changing that it would need discussion. >> If you are changing it only for Mac ARM that may make more sense .. >> >> And these appear to be just API churn by Apple >> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst >> >> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc >> >> NSBorderlessWindowMask is replaced by NSWindowStyleMask >> >> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ > > Min_macos version is changed to 11.0 for macos_aarch64 > > https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From hchao at openjdk.java.net Mon Jan 25 22:48:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 25 Jan 2021 22:48:41 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails In-Reply-To: References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 21:51:19 GMT, Rajan Halade wrote: >> Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification > > Marked as reviewed by rhalade (Reviewer). Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From vkempik at openjdk.java.net Mon Jan 25 22:50:44 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 22:50:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race wrote: >> Min_macos version is changed to 11.0 for macos_aarch64 >> >> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 > > 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask > 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. > Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From hchao at openjdk.java.net Mon Jan 25 22:55:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 25 Jan 2021 22:55:41 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails In-Reply-To: References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 22:45:31 GMT, Hai-May Chao wrote: >> Marked as reviewed by rhalade (Reviewer). > > Looks good. One comment: Add bug id to the changed test. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From hchao at openjdk.java.net Mon Jan 25 22:59:43 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 25 Jan 2021 22:59:43 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails In-Reply-To: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 17:08:45 GMT, Fernando Guallini wrote: > Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification Change copyright year to 2021 ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From cjplummer at openjdk.java.net Mon Jan 25 23:01:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Jan 2021 23:01:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin I looked through the SA changes. Overall looks good except for a couple of minor issues noted. For the most part it seems to have been boilerplate copy-n-paste from existing ports. If there is anything you want me to take a closer look at, let me know. src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702: > 700: primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL); > 701: > 702: #undef REG_INDEX I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64ThreadContext.java line 2: > 1: /* > 2: * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. Update copyright. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From cjplummer at openjdk.java.net Mon Jan 25 23:08:48 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Jan 2021 23:08:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <0a4qdfSXm3tmLgOW3MJoTc8VSL4XGnaKXrSEbaeL3h0=.d7c6ce7f-183f-429c-8b3e-7f6bc3379f23@github.com> On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin JDI changes also look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 23:38:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 23:38:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race wrote: >> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. > > That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. Maybe you should just file a bug after all for this to be dealt with separately. Certainly if it is NOT fixed now such a bug needs to be filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 23:38:43 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 23:38:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik wrote: >> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask >> 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. >> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... > > that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ecki at zusammenkunft.net Tue Jan 26 00:10:21 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 Jan 2021 00:10:21 +0000 Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: , Message-ID: Hello, I wanted to mention again, that all those System property configurations are good, especially to resolve the update pains, but not really useful if you want to make configurations on a per-connection base. If you have to support multiple partners it can be a real pain to setup a common feature set or multiple instances. For this a generic feature setter for the context would be really useful. Most prominent recent example is the ca-extension, which only really makes sense if you also did programmatically configure a small list of trusted CAs. I also think it would overall clean up the code and give a good place for Javadoc all those options. Not to mention the default could be tied to a few new context names. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xue-Lei Andrew Fan Gesendet: Monday, January 25, 2021 11:17:56 PM An: security-dev at openjdk.java.net Betreff: Re: RFR: 8217633: Configurable extensions with system properties [v2] > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update copyright years to 2021 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1752/files - new: https://git.openjdk.java.net/jdk/pull/1752/files/ad5f3330..5bd6e865 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752 PR: https://git.openjdk.java.net/jdk/pull/1752 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkempik at openjdk.java.net Tue Jan 26 07:26:43 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 07:26:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race wrote: >> That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. > > Maybe you should just file a bug after all for this to be dealt with separately. > Certainly if it is NOT fixed now such a bug needs to be filed. I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is blocked by jep-391 currently ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From stefank at openjdk.java.net Tue Jan 26 08:57:54 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 26 Jan 2021 08:57:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. I wonder if this is the right choice. I think it would have been good if this could have been completely hidden in the transition classes. However, that doesn't seem to have been enough and now there are explicit Thread::WXWriteFromExecSetter instances where it's not at all obvious why they are needed. For example, why was it added here?: OopStorageParIterPerf::~OopStorageParIterPerf() { // missing transition to vm state Thread::WXWriteFromExecSetter wx_write; _storage.release(_entries, ARRAY_SIZE(_entries)); } You need to dig down in the OopStorage implementation to find that it's because it uses SafeFetch, which has the opposite transition: inline int SafeFetch32(int* adr, int errValue) { assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); Thread::WXExecFromWriteSetter wx_exec; return StubRoutines::SafeFetch32_stub()(adr, errValue); } I think this adds complexity to code that shouldn't have to deal with this. I'm fine with having to force devs / code that writes to exec memory to have to deal with a bit more complexity, but it seems wrong to let this leak out to code that is staying far away from that. For my understanding, was this choice made because the nmethods instances (and maybe other types as well) are placed in the code cache memory segment, which is executable? If the code cache only contained the JIT:ed code, and not object instances, I think this could more easily have been contained a bit more. If the proposed solution is going to stay, maybe this could be made a little bit nicer by changing the SafeFetch implementation to use a new scoped object that doesn't enforce the "from" state to be "write"? Instead it could check if the state is "write" and only then flip the state back and forth. I think, this would remove the change needed OopStorageParIterPerf, and probably other places as well. src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 38: > 36: #include "runtime/os.hpp" > 37: #include "runtime/stubRoutines.hpp" > 38: #include "runtime/stubRoutines.inline.hpp" Remove stubRutines.hpp line src/hotspot/share/runtime/stubRoutines.inline.hpp line 29: > 27: > 28: #include > 29: #include Replace < > with " " src/hotspot/os/aix/os_aix.cpp line 70: > 68: #include "runtime/statSampler.hpp" > 69: #include "runtime/stubRoutines.hpp" > 70: #include "runtime/stubRoutines.inline.hpp" Remove stubRutines.hpp line ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From fguallini at openjdk.java.net Tue Jan 26 09:06:57 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 26 Jan 2021 09:06:57 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2] In-Reply-To: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: > Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add bugid and missing space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2224/files - new: https://git.openjdk.java.net/jdk/pull/2224/files/e3b011d9..b1162373 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2224&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2224&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2224/head:pull/2224 PR: https://git.openjdk.java.net/jdk/pull/2224 From ihse at openjdk.java.net Tue Jan 26 09:25:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 09:25:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin Changes requested by ihse (Reviewer). make/autoconf/build-aux/autoconf-config.guess line 1275: > 1273: UNAME_PROCESSOR="aarch64" > 1274: fi > 1275: fi ;; Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Tue Jan 26 10:14:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 10:14:41 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote: > We should create a separate issue to rename them and get rid of the copying in the make file. I opened https://bugs.openjdk.java.net/browse/JDK-8260406. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From fguallini at openjdk.java.net Tue Jan 26 10:40:42 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 26 Jan 2021 10:40:42 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2] In-Reply-To: References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 22:57:04 GMT, Hai-May Chao wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> add bugid and missing space > > Change copyright year to 2021 Thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From akozlov at openjdk.java.net Tue Jan 26 11:33:45 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 11:33:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/thread.hpp line 915: >> >>> 913: verify_wx_state(WXExec); >>> 914: } >>> 915: }; >> >> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? > > This could be a follow-up RFE. I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. If such costs are negligible, I can do as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Tue Jan 26 12:04:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 12:04:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov wrote: >> This could be a follow-up RFE. > > I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. > * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. > * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. > > If such costs are negligible, I can do as suggested. I really just want the minimal number of lines of code and hooks in thread.hpp. You can still access it through the thread, just like these lines currently. Look at HandshakeState as an example. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 12:09:42 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 12:09:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework > ie: > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > Otherwise there will be missing _JNFNative* functions. > > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? There is ongoing work by P. Race to eliminate dependence on JNF at all ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Jan 26 12:04:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 26 Jan 2021 12:04:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:23:23 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > Changes requested by ihse (Reviewer). AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework ie: ` --with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/' ` Otherwise there will be missing _JNFNative* functions. Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Jan 26 12:36:44 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 26 Jan 2021 12:36:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> On Tue, 26 Jan 2021 12:06:28 GMT, Vladimir Kempik wrote: > > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework > > ie: > > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > Otherwise there will be missing _JNFNative* functions. > > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? > > There is ongoing work by P. Race to eliminate dependence on JNF at all Ok, that's great. In the meantime is it worth adding something to the MacOS section of doc/building.* ? (I pieced together the required line from multiple posts in a mailing list) ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From magnus.ihse.bursie at oracle.com Tue Jan 26 12:44:34 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 13:44:34 +0100 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> On 2021-01-26 13:09, Vladimir Kempik wrote: > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: > >> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >> ie: >> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >> >> Otherwise there will be missing _JNFNative* functions. >> >> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? > There is ongoing work by P. Race to eliminate dependence on JNF at all How far has that work come? Otherwise the logic should be added to configure to look for this framework automatically, and provide a way to override it/set it if not found. I don't think it's OK to publish a new port that cannot build out-of-the-box without hacks like this. /Magnus > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 12:52:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 12:52:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore wrote: >> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. > > Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: > class ThreadInVMfromNative : public ThreadStateTransition { > ResetNoHandleMark __rnhm; > > We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 15:06:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 15:06:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0c2cb0a3..fef36580 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02-03 Stats: 98 lines in 1 file changed: 74 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 15:06:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 15:06:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4] In-Reply-To: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> References: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> Message-ID: On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley wrote: >> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 > > This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch. Makes sense, I've reverted changes in the old code but will propose them in the separate PR shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 16:09:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 16:09:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: > >> 111: >> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) >> 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) > > I need a robust explanation of these changes. > They are not mentioned, nor are they in upstream harfbuzz. > Likely these should be pushed to upstream first if there is a reason for them. @lewurm This and other harfbuzz changes came from MS, could you please comment here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Jan 26 16:38:47 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 26 Jan 2021 16:38:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Tue, 26 Jan 2021 16:07:19 GMT, Vladimir Kempik wrote: >> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: >> >>> 111: >>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) >>> 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) >> >> I need a robust explanation of these changes. >> They are not mentioned, nor are they in upstream harfbuzz. >> Likely these should be pushed to upstream first if there is a reason for them. > > @lewurm This and other harfbuzz changes came from MS, could you please comment here ? This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Tue Jan 26 17:11:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 26 Jan 2021 17:11:41 GMT Subject: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2] In-Reply-To: References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Tue, 26 Jan 2021 09:06:57 GMT, Fernando Guallini wrote: >> Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > add bugid and missing space Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From fguallini at openjdk.java.net Tue Jan 26 18:18:42 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 26 Jan 2021 18:18:42 GMT Subject: Integrated: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails In-Reply-To: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> References: <7PBiZ_ERg4EP2smqbrLkW1_tOmkf8CNmuTRedXeAquo=.0b506e97-396d-4342-bbde-b5f1a7ad1357@github.com> Message-ID: On Mon, 25 Jan 2021 17:08:45 GMT, Fernando Guallini wrote: > Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification This pull request has now been integrated. Changeset: 9f0a0436 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/9f0a0436 Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails Reviewed-by: rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2224 From cverghese at openjdk.java.net Tue Jan 26 18:35:03 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Tue, 26 Jan 2021 18:35:03 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v5] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/4f7f9e31..983842df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=03-04 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From xuelei at openjdk.java.net Tue Jan 26 18:35:41 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Jan 2021 18:35:41 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:27:25 GMT, Rajan Halade wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years to 2021 > > Marked as reviewed by rhalade (Reviewer). Hi Bernd, I agree with you that System property is not as useful to configure individual connections. It is mostly used for corner cases that have interoperability or compatibility issues. A general program should use APIs and the default system properties. > _Mailing list message from [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) on [security-dev](mailto:security-dev at openjdk.java.net):_ > > Hello, > > I wanted to mention again, that all those System property configurations are good, especially to resolve the update pains, but not really useful if you want to make configurations on a per-connection base. If you have to support multiple partners it can be a real pain to setup a common feature set or multiple instances. For this a generic feature setter for the context would be really useful. Most prominent recent example is the ca-extension, which only really makes sense if you also did programmatically configure a small list of trusted CAs. > Yes, ca-extension is an item I was thinking of to support in JDK. > I also think it would overall clean up the code and give a good place for Javadoc all those options. > Not to mention the default could be tied to a few new context names. > Currently, the system properties are documented in the JSSE Reference Guides. But just as you know, it is as easy to follow. I agree with you that it would be nice to have better place to have them all together. Thank you for the review. Regards, Xuelei > Gruss > Bernd > -- > http://bernd.eckenfels.net ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From akozlov at openjdk.java.net Tue Jan 26 18:42:02 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 18:42:02 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Revert harfbuzz changes, disable warnings for it ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/fef36580..b2b396fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03-04 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From erik.joelsson at oracle.com Tue Jan 26 18:42:49 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 26 Jan 2021 10:42:49 -0800 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> References: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> Message-ID: <58df0666-2c69-a4dd-3bb8-fd00c859b490@oracle.com> On 2021-01-26 04:44, Magnus Ihse Bursie wrote: > On 2021-01-26 13:09, Vladimir Kempik wrote: >> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward >> wrote: >> >>> AIUI, the configure line needs passing a prebuilt >>> JavaNativeFoundation framework >>> ie: >>> `--with-extra-ldflags='-F >>> /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>> >>> Otherwise there will be missing _JNFNative* functions. >>> >>> Is this the long term plan? Or will eventually the required code be >>> moved into JDK and/or the xcode one automatically get picked up by >>> the configure scripts? >> There is ongoing work by P. Race to eliminate dependence on JNF at all > How far has that work come? Otherwise the logic should be added to > configure to look for this framework automatically, and provide a way > to override it/set it if not found. > > I don't think it's OK to publish a new port that cannot build > out-of-the-box without hacks like this. > My understanding is that Apple chose to not provide JNF for aarch64, so if you want to build OpenJDK, you first need to build JNF yourself (it's available in github). Phil is working on removing this dependency completely, which will solve this issue [1]. In the meantime, I don't think we should rely on finding JNF in unsupported locations inside Xcode. Could we wait with integrating this port until it can be built without such hacks? If not, then adding something in the documentation on how to get a working JNF would at least be needed. /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8257852 From akozlov at openjdk.java.net Tue Jan 26 18:54:46 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 18:54:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster wrote: >> @lewurm This and other harfbuzz changes came from MS, could you please comment here ? > > This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e I've reverted this change and disabled some warnings for libharfbuzz instead. I should be blamed, yes. Now this is consistent with other changes covered by JDK-8260402 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From cverghese at openjdk.java.net Tue Jan 26 18:56:57 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Tue, 26 Jan 2021 18:56:57 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: <7nmhhOSot30Inty6U630yqz_XLokbsqzLK4o8CQZ_9A=.b5985092-d19a-40f4-93e5-a17f3478e1f5@github.com> > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Update copyright year - Add error handling guidelines - Fix bugids and use server port passed as a parameter - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl ------------- Changes: https://git.openjdk.java.net/jdk/pull/2057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=05 Stats: 501 lines in 7 files changed: 490 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From weijun at openjdk.java.net Tue Jan 26 19:26:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Jan 2021 19:26:41 GMT Subject: RFR: 8259801: Enable XML Signature secure validation mode by default In-Reply-To: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> References: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> Message-ID: On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote: > This change enables the XML Signature secure validation mode by default. This will improve out of the box security by restricting signatures that contain potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2197 From weijun at openjdk.java.net Tue Jan 26 19:36:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Jan 2021 19:36:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Revert harfbuzz changes, disable warnings for it src/java.security.jgss/share/native/libj2gss/gssapi.h line 48: > 46: // Condition was copied from > 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h > 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) So for macOS/AArch64, this `if` is no longer true? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Jan 26 19:41:50 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 26 Jan 2021 19:41:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Mon, 25 Jan 2021 17:43:35 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193: > >> 191: * crbug.com/549610 */ >> 192: // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h >> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10 > > I need a robust explanation of these changes. > They are not mentioned, nor are they in upstream harfbuzz. > Likely these should be pushed to upstream first if there is a reason for them. I'm afraid it's one of those dirty changes that we did to make progress, but forgot to revisit later. Without the guard you would get: * For target support_native_java.desktop_libharfbuzz_hb-coretext.o: if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) { ^ uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0)); ^ if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) { ^ uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0)); ^ 2 errors generated. For now, it's probably better to go with what Anton did in the latest commit https://github.com/openjdk/jdk/pull/2200/commits/b2b396fca679fbc7ee78fb5bc80191bc79e1c490 Eventually upstream will do something about it I assume? How often does it get synced with upstream? Maybe worth to file an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Tue Jan 26 19:49:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 26 Jan 2021 19:49:41 GMT Subject: RFR: 8259801: Enable XML Signature secure validation mode by default In-Reply-To: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> References: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> Message-ID: On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote: > This change enables the XML Signature secure validation mode by default. This will improve out of the box security by restricting signatures that contain potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2197 From vkempik at openjdk.java.net Tue Jan 26 20:02:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 20:02:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert harfbuzz changes, disable warnings for it > > src/java.security.jgss/share/native/libj2gss/gssapi.h line 48: > >> 46: // Condition was copied from >> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h >> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) > > So for macOS/AArch64, this `if` is no longer true? That is according to Xcode sdk. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 21:59:03 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 21:59:03 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Redo buildsys fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04-05 Stats: 18 lines in 2 files changed: 8 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 22:07:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 22:07:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > make/autoconf/build-aux/autoconf-config.guess line 1275: > >> 1273: UNAME_PROCESSOR="aarch64" >> 1274: fi >> 1275: fi ;; > > Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. Hello I have updated PR and moved this logic to make/autoconf/build-aux/config.guess It's pretty similar to i386 -> x86_64 fix-up on macos_intel ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From martin at openjdk.java.net Wed Jan 27 04:34:39 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Wed, 27 Jan 2021 04:34:39 GMT Subject: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2] In-Reply-To: References: <5u4w-g-wpqqVp3GHPon_vNOhT2Mq0lAowl74fFZwCms=.fc5d8f4c-7e4a-47a4-ad10-02dbe281f16f@github.com> Message-ID: On Sat, 23 Jan 2021 02:03:01 GMT, Valerie Peng wrote: >> Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Marked as reviewed by valeriep (Reviewer). @drott @valeriepeng @AlanBateman @jianglizhou Thanks all ! ------------- PR: https://git.openjdk.java.net/jdk/pull/2119 From martin at openjdk.java.net Wed Jan 27 04:34:40 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Wed, 27 Jan 2021 04:34:40 GMT Subject: Integrated: 8252412: [macos11] system dynamic libraries removed from filesystem In-Reply-To: References: Message-ID: On Sun, 17 Jan 2021 20:24:44 GMT, Martin Buchholz wrote: > 8252412: [macos11] system dynamic libraries removed from filesystem This pull request has now been integrated. Changeset: c836da38 Author: Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/c836da38 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod 8252412: [macos11] system dynamic libraries removed from filesystem Co-authored-by: Dominik R?ttsches Reviewed-by: jiangli, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/2119 From dholmes at openjdk.java.net Wed Jan 27 06:50:45 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 06:50:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> Message-ID: On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: >>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>> ie: >>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>> >>> Otherwise there will be missing _JNFNative* functions. >>> >>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >> >> There is ongoing work by P. Race to eliminate dependence on JNF at all > >> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >> > ie: >> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >> > Otherwise there will be missing _JNFNative* functions. >> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >> >> There is ongoing work by P. Race to eliminate dependence on JNF at all > > Ok, that's great. > In the meantime is it worth adding something to the MacOS section of doc/building.* ? > (I pieced together the required line from multiple posts in a mailing list) Hi Anton, Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:29:45 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:29:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster wrote: >> @luhenry , could you please check this comment, I think SA-agent was MS's job here. > > The target is identified by the header file now: > https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41 > > Do you think there is any problem with this approach? @lewurm No, that's okay. I just wanted to know that this had not been lost. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:32:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:32:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote: >> make/autoconf/build-aux/autoconf-config.guess line 1275: >> >>> 1273: UNAME_PROCESSOR="aarch64" >>> 1274: fi >>> 1275: fi ;; >> >> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. > > Hello > I have updated PR and moved this logic to make/autoconf/build-aux/config.guess > It's pretty similar to i386 -> x86_64 fix-up on macos_intel Thanks. That looks better. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:38:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:38:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Redo buildsys fix Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From david.holmes at oracle.com Wed Jan 27 08:42:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jan 2021 18:42:53 +1000 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> Message-ID: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> I don't know why the Skara tools decided to associate my comment with Alan Hayward's comment as they are not at all related. :( David On 27/01/2021 4:50 pm, David Holmes wrote: > On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: > >>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>>> ie: >>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>>> >>>> Otherwise there will be missing _JNFNative* functions. >>>> >>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >>> >>> There is ongoing work by P. Race to eliminate dependence on JNF at all >> >>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>>> ie: >>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>>> Otherwise there will be missing _JNFNative* functions. >>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >>> >>> There is ongoing work by P. Race to eliminate dependence on JNF at all >> >> Ok, that's great. >> In the meantime is it worth adding something to the MacOS section of doc/building.* ? >> (I pieced together the required line from multiple posts in a mailing list) > > Hi Anton, > > Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods. > > Thanks, > David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 > From djelinski1 at gmail.com Wed Jan 27 09:28:14 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 27 Jan 2021 10:28:14 +0100 Subject: 8259886 : Improve SSL session cache performance and scalability Message-ID: Hi all, I'd like to modify the MemoryCache class that is used for caching SSL sessions in Java 11; when the cache is overloaded (full cache with no expired entries), the computational complexity of put operation is linear in the cache size. I am aware that the current Java versions are using stateless resumption; my company's policy is to use Java LTS, so stateless is not an option to us at the moment. The change I propose would alter the behavior of MemoryCache; currently the cache guarantees that expired entries are removed before live entries when the cache capacity is reached. I'd like to remove that guarantee, and instead always remove the least recently used cache entry. Additionally, to keep the memory use in check, I'd like to check the least recently used entries for expiration, and remove them as needed. This operation would be run on every put(). Evaluated alternatives: - keep MemoryCache as is, increase cache size to avoid overloading. This would reduce the frequency of check for expired entries, but if the larger cache eventually gets overloaded, the put() operation would take even longer to complete. - keep MemoryCache behavior as is, but improve performance of removing expired entries. This would require a new data structure - we would need to have cache entries sorted both by access time and creation time. - always remove entries in insertion order, regardless if they are used or not. - always remove the least recently used entries, even if they are still valid and there are recently used expired entries somewhere in the cache. This is my preferred option. Additionally, we can choose how to remove stale entries: - all reachable stale entries on every put (that is, iterate over the internal data structure removing stale entries until a non-stale one is found); keeps memory use low, but can occasionally scan the entire cache (computational complexity: linear worst case, amortized constant); - fixed number of reachable stale entries on every put (same as above, but stop iterating after a fixed number of removed entries even if more are available); execution time is bounded by a constant, but some entries may stay in cache a bit longer than they need to. - all stale entries on put that would otherwise exceed cache capacity (current implementation) - never; once cache reaches full capacity, it stays full until the application is restarted. Fastest implementation, but at a cost of increased memory use. My preference would be to remove either all or a fixed number of reachable stale entries. I'm willing to prepare a patch for 17 and 11u, if I can find a sponsor. Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Jan 27 09:43:36 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jan 2021 09:43:36 +0000 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> Message-ID: <90fd9651-f954-42da-1282-bf9a7de63e13@redhat.com> On 1/26/21 6:42 PM, erik.joelsson at oracle.com wrote: > My understanding is that Apple chose to not provide JNF for aarch64, so > if you want to build OpenJDK, you first need to build JNF yourself (it's > available in github). Phil is working on removing this dependency > completely, which will solve this issue [1]. > > In the meantime, I don't think we should rely on finding JNF in > unsupported locations inside Xcode. Could we wait with integrating this > port until it can be built without such hacks? That sounds right to me. In the meantime, there is some cleanup work to be done in mainline on slow_signature_handler, which will potentially make the AArch64 back end merge much simpler. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at openjdk.java.net Wed Jan 27 14:50:01 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 27 Jan 2021 14:50:01 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v7] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05-06 Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Wed Jan 27 15:01:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 27 Jan 2021 15:01:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie wrote: > Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From xuelei at openjdk.java.net Wed Jan 27 17:48:40 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Jan 2021 17:48:40 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 13 Jan 2021 18:46:10 GMT, Rajan Halade wrote: >> Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Update copyright year >> - Add error handling guidelines >> - Fix bugids and use server port passed as a parameter >> - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl > > Changes requested by rhalade (Reviewer). For the CSR request, I updated the component to security-libs/javax.net.ssl, add 17 as one of the fix versions, and added myself as reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Wed Jan 27 18:12:40 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 27 Jan 2021 18:12:40 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 27 Jan 2021 17:46:03 GMT, Xue-Lei Andrew Fan wrote: >> Changes requested by rhalade (Reviewer). > > For the CSR request, I updated the component to security-libs/javax.net.ssl, add 17 as one of the fix versions, and added myself as reviewer. Thank you. I will change the status of the CSR to proposed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From xuelei.fan at oracle.com Wed Jan 27 19:36:25 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 27 Jan 2021 19:36:25 +0000 Subject: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: <795181BB-FD2A-420A-A051-1F2D06B1A6F4@ORACLE.COM> Hi Daniel, I would like to help you out. Did you have some numbers about the performance improvement of your evaluation? I had a draft re-write cache by using ConcurrentHashMap, if you have a chance, would you like to evaluate if it could be improved further with your ideas? Thanks, Xuelei On Jan 27, 2021, at 1:28 AM, Daniel Jeli?ski > wrote: Hi all, I'd like to modify the MemoryCache class that is used for caching SSL sessions in Java 11; when the cache is overloaded (full cache with no expired entries), the computational complexity of put operation is linear in the cache size. I am aware that the current Java versions are using stateless resumption; my company's policy is to use Java LTS, so stateless is not an option to us at the moment. The change I propose would alter the behavior of MemoryCache; currently the cache guarantees that expired entries are removed before live entries when the cache capacity is reached. I'd like to remove that guarantee, and instead always remove the least recently used cache entry. Additionally, to keep the memory use in check, I'd like to check the least recently used entries for expiration, and remove them as needed. This operation would be run on every put(). Evaluated alternatives: - keep MemoryCache as is, increase cache size to avoid overloading. This would reduce the frequency of check for expired entries, but if the larger cache eventually gets overloaded, the put() operation would take even longer to complete. - keep MemoryCache behavior as is, but improve performance of removing expired entries. This would require a new data structure - we would need to have cache entries sorted both by access time and creation time. - always remove entries in insertion order, regardless if they are used or not. - always remove the least recently used entries, even if they are still valid and there are recently used expired entries somewhere in the cache. This is my preferred option. Additionally, we can choose how to remove stale entries: - all reachable stale entries on every put (that is, iterate over the internal data structure removing stale entries until a non-stale one is found); keeps memory use low, but can occasionally scan the entire cache (computational complexity: linear worst case, amortized constant); - fixed number of reachable stale entries on every put (same as above, but stop iterating after a fixed number of removed entries even if more are available); execution time is bounded by a constant, but some entries may stay in cache a bit longer than they need to. - all stale entries on put that would otherwise exceed cache capacity (current implementation) - never; once cache reaches full capacity, it stays full until the application is restarted. Fastest implementation, but at a cost of increased memory use. My preference would be to remove either all or a fixed number of reachable stale entries. I'm willing to prepare a patch for 17 and 11u, if I can find a sponsor. Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Wed Jan 27 21:39:50 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 27 Jan 2021 22:39:50 +0100 Subject: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: <795181BB-FD2A-420A-A051-1F2D06B1A6F4@ORACLE.COM> References: <795181BB-FD2A-420A-A051-1F2D06B1A6F4@ORACLE.COM> Message-ID: Hi Xuelei, Thank you, that would be great. Yes, I created a microbenchmark and got some numbers. The benchmark just calls MemoryCache.put() in a loop; baseline results for different size & timeout values: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op And after applying my proposed changes: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op Given that the server-side handshake takes about 2 milliseconds (same machine, TLS 1.2/ECDHE/ECDSA/secp256r1), I don't expect 0.1 microsecond cache access to be a point of contention, but I haven't field-tested it yet. I posted my code and benchmark results here: https://github.com/openjdk/jdk/pull/2255. I'm still struggling with the company's OCA (signed a few years and a few corporate changes ago, and not used in a long time), I hope to get this sorted soon. I went with minimal changes to the existing implementation, hoping that smaller changes will be more likely to be approved for backporting than complete rewrites. I had a quick look at your SessionCache. It looks like your put() operation is constant-time already, so not much else for me to improve. However, please correct me if I'm wrong, but I think SoftCacheEntry.unlink() should be called with a lock held at all times, shouldn't it? SessionCache.get() may call remove() without lock. Also there's no protection against calling unlink() twice on the same entry (for example from concurrent get() calls), which could wreck the linked list; setting prev=next=null would have avoided this. Thanks, Daniel ?r., 27 sty 2021 o 20:36 Xue-Lei Fan napisa?(a): > Hi Daniel, > > I would like to help you out. Did you have some numbers about the > performance improvement of your evaluation? I had a draft re-write cache > by > using ConcurrentHashMap, if you have a chance, would you like to evaluate > if it could be improved further with your ideas? > > Thanks, > Xuelei > > On Jan 27, 2021, at 1:28 AM, Daniel Jeli?ski wrote: > > Hi all, > I'd like to modify the MemoryCache class that is used for caching SSL > sessions in Java 11; when the cache is overloaded (full cache with no > expired entries), the computational complexity of put operation is linear > in the cache size. > > I am aware that the current Java versions are using stateless resumption; > my company's policy is to use Java LTS, so stateless is not an option to us > at the moment. > > The change I propose would alter the behavior of MemoryCache; currently > the cache guarantees that expired entries are removed before live entries > when the cache capacity is reached. I'd like to remove that guarantee, and > instead always remove the least recently used cache entry. Additionally, to > keep the memory use in check, I'd like to check the least recently used > entries for expiration, and remove them as needed. This operation would be > run on every put(). > > Evaluated alternatives: > - keep MemoryCache as is, increase cache size to avoid overloading. This > would reduce the frequency of check for expired entries, but if the larger > cache eventually gets overloaded, the put() operation would take even > longer to complete. > - keep MemoryCache behavior as is, but improve performance of removing > expired entries. This would require a new data structure - we would need to > have cache entries sorted both by access time and creation time. > - always remove entries in insertion order, regardless if they are used or > not. > - always remove the least recently used entries, even if they are still > valid and there are recently used expired entries somewhere in the cache. > This is my preferred option. > > Additionally, we can choose how to remove stale entries: > - all reachable stale entries on every put (that is, iterate over the > internal data structure removing stale entries until a non-stale one is > found); keeps memory use low, but can occasionally scan the entire cache > (computational complexity: linear worst case, amortized constant); > - fixed number of reachable stale entries on every put (same as above, but > stop iterating after a fixed number of removed entries even if more are > available); execution time is bounded by a constant, but some entries may > stay in cache a bit longer than they need to. > - all stale entries on put that would otherwise exceed cache capacity > (current implementation) > - never; once cache reaches full capacity, it stays full until the > application is restarted. Fastest implementation, but at a cost of > increased memory use. > > My preference would be to remove either all or a fixed number of reachable > stale entries. > > I'm willing to prepare a patch for 17 and 11u, if I can find a sponsor. > Thanks, > Daniel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Thu Jan 28 01:15:08 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Jan 2021 01:15:08 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v3] In-Reply-To: References: Message-ID: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: rename the system property names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1752/files - new: https://git.openjdk.java.net/jdk/pull/1752/files/5bd6e865..88beb8ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=01-02 Stats: 158 lines in 3 files changed: 75 ins; 75 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752 PR: https://git.openjdk.java.net/jdk/pull/1752 From xuelei at openjdk.java.net Thu Jan 28 01:25:12 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Jan 2021 01:25:12 GMT Subject: RFR: 8217633: Configurable extensions with system properties [v4] In-Reply-To: References: Message-ID: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - rename the system property names - Update copyright years to 2021 - Remove swp file - Add regression test - 8217633: Configurable extensions with system properties ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1752/files - new: https://git.openjdk.java.net/jdk/pull/1752/files/88beb8ae..ed9409c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=02-03 Stats: 121138 lines in 3068 files changed: 60397 ins; 38820 del; 21921 mod Patch: https://git.openjdk.java.net/jdk/pull/1752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752 PR: https://git.openjdk.java.net/jdk/pull/1752 From rhalade at openjdk.java.net Thu Jan 28 01:28:57 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 28 Jan 2021 01:28:57 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program Message-ID: Following two roots are added to cacerts store - CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR ------------- Commit messages: - 8256421: Add 2 HARICA roots to Oracle Root CA Program Changes: https://git.openjdk.java.net/jdk/pull/2272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256421 Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2272/head:pull/2272 PR: https://git.openjdk.java.net/jdk/pull/2272 From sean.mullan at oracle.com Thu Jan 28 14:32:28 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 28 Jan 2021 09:32:28 -0500 Subject: RFR: Release Note for 8259801: Enable XML Signature secure validation mode by default Message-ID: <91863b5c-6ccb-4a8e-aea5-f64e461c81fc@oracle.com> Please review the release note for JDK-8259801: https://bugs.openjdk.java.net/browse/JDK-8260551 Thanks, Sean From mullan at openjdk.java.net Thu Jan 28 14:33:02 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Jan 2021 14:33:02 GMT Subject: RFR: 8259801: Enable XML Signature secure validation mode by default [v2] In-Reply-To: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> References: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> Message-ID: > This change enables the XML Signature secure validation mode by default. This will improve out of the box security by restricting signatures that contain potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - Minor re-wording of implNote. - Initial fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2197/files - new: https://git.openjdk.java.net/jdk/pull/2197/files/0c2e0498..ff15a1d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2197&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2197&range=00-01 Stats: 37355 lines in 801 files changed: 14132 ins; 17886 del; 5337 mod Patch: https://git.openjdk.java.net/jdk/pull/2197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2197/head:pull/2197 PR: https://git.openjdk.java.net/jdk/pull/2197 From mullan at openjdk.java.net Thu Jan 28 14:33:03 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Jan 2021 14:33:03 GMT Subject: Integrated: 8259801: Enable XML Signature secure validation mode by default In-Reply-To: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> References: <9HRgyPgqRER04apfkOLIIU2ma-9KSFTCO-d2323XgNY=.c4baa239-5a2c-4f41-9718-d154cf06823a@github.com> Message-ID: On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote: > This change enables the XML Signature secure validation mode by default. This will improve out of the box security by restricting signatures that contain potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 This pull request has now been integrated. Changeset: baf46bac Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/baf46bac Stats: 55 lines in 3 files changed: 12 ins; 3 del; 40 mod 8259801: Enable XML Signature secure validation mode by default Reviewed-by: weijun, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2197 From weijun at openjdk.java.net Thu Jan 28 16:12:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Jan 2021 16:12:58 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v5] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: cleanups for key generations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/9b17b1a2..48890a61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=03-04 Stats: 156 lines in 19 files changed: 101 ins; 23 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Jan 28 16:15:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Jan 2021 16:15:40 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Fri, 22 Jan 2021 21:25:25 GMT, Weijun Wang wrote: >> New commit. However, I was writing test to detect leak in `RSAPrivateKeySpec` conversion and add more key->spec->key for other algorithms and find more leaks. Will fix in another commit. > > Another new commit. Last time I only fixed KeySpec on PKCS8 format. This time it's for an algorithm's _own_ spec. New commit for key generations. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From hchao at openjdk.java.net Thu Jan 28 18:16:43 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Jan 2021 18:16:43 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2272 From rhalade at openjdk.java.net Thu Jan 28 18:23:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 28 Jan 2021 18:23:41 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 18:13:39 GMT, Hai-May Chao wrote: > Looks good. Thanks!! Can you please approve review with approval on changeset? With that, your OpenJDK id will be added as reviewer to the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2272 From hchao at openjdk.java.net Thu Jan 28 18:54:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Jan 2021 18:54:41 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 Marked as reviewed by hchao (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/2272 From xuelei at openjdk.java.net Thu Jan 28 19:24:45 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Jan 2021 19:24:45 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6] In-Reply-To: <7nmhhOSot30Inty6U630yqz_XLokbsqzLK4o8CQZ_9A=.b5985092-d19a-40f4-93e5-a17f3478e1f5@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> <7nmhhOSot30Inty6U630yqz_XLokbsqzLK4o8CQZ_9A=.b5985092-d19a-40f4-93e5-a17f3478e1f5@github.com> Message-ID: <6-fZydF35jbPmHK9SxA0WlQPSW22PL2R2-K4as8ceTQ=.83d01e62-cdd9-4447-8f48-163f4903cc23@github.com> On Tue, 26 Jan 2021 18:56:57 GMT, Clive Verghese wrote: >> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed >> >> This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake > > Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Update copyright year > - Add error handling guidelines > - Fix bugids and use server port passed as a parameter > - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1425: > 1423: } catch (SocketException se) { > 1424: // don't change exception in case of SocketException > 1425: throw se; I may add the SocketException catch line together within line 1420. src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1491: > 1489: } catch (SocketException se) { > 1490: // don't change exception in case of SocketException > 1491: throw se; I may add the SocketException catch line together within line 1489. src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1702: > 1700: if (!conContext.isInboundClosed()) { > 1701: try { > 1702: decode(null); One decode may be not sufficient if there are multiple pending handshake messages record, or the connection has been established and application data transportation is in progress. I'm not sure if an additional decode() here really solve the problem as described in JDK-8259516. I did not follow the issue of JDK-8259516. Why an SSLException is desired but not SocketException, as if the socket has been closed? src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 146: > 144: } catch (SocketException se) { > 145: // don't change exception in case of SocketException > 146: throw se; I may add the SocketException catch line together within line 141. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Thu Jan 28 20:12:14 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 28 Jan 2021 20:12:14 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/72fef9b8..888162a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=05-06 Stats: 15 lines in 2 files changed: 0 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From mr at openjdk.java.net Fri Jan 29 00:17:46 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Fri, 29 Jan 2021 00:17:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 16:45:00 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update package info to credit LMX algorithm src/java.base/share/classes/java/util/random/RandomGenerator.java line 110: > 108: /** > 109: * Returns an instance of {@link RandomGenerator} that utilizes the > 110: * {@code name} algorithm. Shouldn't this method, and related methods, mention the fact that `RandomGenerator` instances are located as services? I see no mention of of that fact anywhere, unless I missed it, but I do see the `uses` and `provides` declarations in the module declaration. A paragraph explaining how services are used here, perhaps in the package specification, would be ideal. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From xuelei at openjdk.java.net Fri Jan 29 00:53:44 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 29 Jan 2021 00:53:44 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Thu, 28 Jan 2021 20:12:14 GMT, Clive Verghese wrote: >> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed >> >> This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Please make sure all tier1 and tier2 tests passed on all supported platforms. Except the failed I commented in the update, javax/net/ssl/SSLSession/TestEnabledProtocols.java is also failed with a similar stack on Windows. Maybe, the pull request command "/test tier1" and "/test tier2" could help speed up the testing. test/jdk/sun/security/ssl/SSLContextImpl/ShouldThrowSSLExceptionWhenPeerClosesSocket.java line 137: > 135: // Ignore exception as this is expected. > 136: } > 137: } The test cannot pass tier2 test on Windows. java.net.SocketException: An established connection was aborted by the software in your host machine at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1045) at java.base/sun.security.ssl.SSLSocketOutputRecord.flush(SSLSocketOutputRecord.java:266) at java.base/sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:89) at java.base/sun.security.ssl.CertificateRequest$T12CertificateRequestProducer.produce(CertificateRequest.java:629) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440) at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1120) at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:853) at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:812) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:199) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1501) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:915) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1006) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:966) at ShouldThrowSSLExceptionWhenPeerClosesSocket.runServerApplication(ShouldThrowSSLExceptionWhenPeerClosesSocket.java:131) at SSLSocketTemplate.doServerSide(SSLSocketTemplate.java:280) at SSLSocketTemplate.startServer(SSLSocketTemplate.java:584) at SSLSocketTemplate.bootup(SSLSocketTemplate.java:498) at SSLSocketTemplate.run(SSLSocketTemplate.java:83) at ShouldThrowSSLExceptionWhenPeerClosesSocket.main(ShouldThrowSSLExceptionWhenPeerClosesSocket.java:292) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Suppressed: java.net.SocketException: An established connection was aborted by the software in your host machine at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:325) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:976) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1501) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1696) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:460) ... 15 more test/jdk/sun/security/ssl/SSLSocketImpl/SocketExceptionForSocketIssues.java line 84: > 82: } catch (SocketException se) { > 83: // the expected exception, ignore it > 84: System.err.println("server exception: " + se); The test failed with on Linux/Windows/MacOSX: javax.net.ssl.SSLHandshakeException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:369) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1501) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1696) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:460) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:915) at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1285) at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) at java.base/java.io.BufferedWriter.flush(BufferedWriter.java:257) at SocketExceptionForSocketIssues.test(SocketExceptionForSocketIssues.java:79) at SocketExceptionForSocketIssues.main(SocketExceptionForSocketIssues.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Suppressed: java.net.SocketException: Broken pipe at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:440) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:826) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1045) at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:400) ... 22 more ------------- Changes requested by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Fri Jan 29 08:35:59 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 29 Jan 2021 08:35:59 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v8] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Address review comments - Update copyright year - Add error handling guidelines - Fix bugids and use server port passed as a parameter - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl ------------- Changes: https://git.openjdk.java.net/jdk/pull/2057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=07 Stats: 200 lines in 7 files changed: 178 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Fri Jan 29 08:40:45 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 29 Jan 2021 08:40:45 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6] In-Reply-To: <6-fZydF35jbPmHK9SxA0WlQPSW22PL2R2-K4as8ceTQ=.83d01e62-cdd9-4447-8f48-163f4903cc23@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> <7nmhhOSot30Inty6U630yqz_XLokbsqzLK4o8CQZ_9A=.b5985092-d19a-40f4-93e5-a17f3478e1f5@github.com> <6-fZydF35jbPmHK9SxA0WlQPSW22PL2R2-K4as8ceTQ=.83d01e62-cdd9-4447-8f48-163f4903cc23@github.com> Message-ID: On Thu, 28 Jan 2021 19:04:29 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1702: > >> 1700: if (!conContext.isInboundClosed()) { >> 1701: try { >> 1702: decode(null); > > One decode may be not sufficient if there are multiple pending handshake messages record, or the connection has been established and application data transportation is in progress. I'm not sure if an additional decode() here really solve the problem as described in JDK-8259516. > > I did not follow the issue of JDK-8259516. Why an SSLException is desired but not SocketException, as if the socket has been closed? I have removed issues for JDK-8259516. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From weijun at openjdk.java.net Fri Jan 29 14:35:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:35:50 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) New commit pushed. There is completely no dependency on JavaNativeFramework anymore. Major change this time: Update the format of `SCDynamicStoreConfig::getKerberosConfig`. ToDo: clean up `JNIUtilities.h`, take back `JNFPerformEnvBlock`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 14:35:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:35:50 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Message-ID: This fix covers both - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) ------------- Commit messages: - error check, new JavaStringToNSString - do not find class and method in loop - no more header file - better macro, no more JNI_COCOA_ENTER - Merge branch 'master' into 8257858 - callback libosxsecurity/KeystoreImpl.m - new SCDynamicStoreConfig return value format - add framework so link succeeds - 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Changes: https://git.openjdk.java.net/jdk/pull/1845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257858 Stats: 484 lines in 6 files changed: 153 ins; 212 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From erikj at openjdk.java.net Fri Jan 29 14:48:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Jan 2021 14:48:41 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 14:57:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:57:56 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: Message-ID: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: same behavior as before -- empty realm map ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/cb02503f..b0ee18a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 18:40:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 18:40:02 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v6] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: drbg only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/48890a61..3a074f7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=04-05 Stats: 20 lines in 2 files changed: 8 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From prr at openjdk.java.net Fri Jan 29 21:19:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 21:19:48 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> Message-ID: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> On Fri, 29 Jan 2021 14:57:56 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > same behavior as before -- empty realm map make/modules/java.security.jgss/Lib.gmk line 84: > 82: $(call SET_SHARED_LIBRARY_ORIGIN), \ > 83: LIBS := -framework Cocoa -framework SystemConfiguration \ > 84: -framework Kerberos -ljava, \ The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ?? src/java.base/macosx/classes/apple/security/KeychainStore.java line 820: > 818: private void createKeyEntry(String alias, long creationDate, long secKeyRef, > 819: long[] secCertificateRefs, byte[][] rawCertData) { > 820: KeyEntry ke = new KeyEntry(); removing these exceptions is presumably just clean up - not directly related ?? src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28: > 26: #import "apple_security_KeychainStore.h" > 27: #include "jni.h" > 28: #include "jni_util.h" jni_util.h includes jni.h so I don't understand the need for this change. Also why did you change import to include ? import is the Obj-C norm ... src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: > 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, > 618: JNI_ABORT); > 619: } Although you have it in the later code, here you are missing @catch (NSException *e) { NSLog(@"%@", [e callStackSymbols]); } src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 41: > 39: if ([keys count] == 0) return; > 40: if (![keys containsObject:KERBEROS_DEFAULT_REALMS] && ![keys containsObject:KERBEROS_DEFAULT_REALM_MAPPINGS]) return; > 41: // JNFPerformEnvBlock(JNFThreadDetachOnThreadDeath | JNFThreadSetSystemClassLoaderOnAttach | JNFThreadAttachAsDaemon, ^(JNIEnv *env) { remove commented out code src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: > 55: } > 56: } > 57: (*localVM)->DetachCurrentThread(localVM); I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 21:54:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 21:54:45 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 20:51:04 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> same behavior as before -- empty realm map > > make/modules/java.security.jgss/Lib.gmk line 84: > >> 82: $(call SET_SHARED_LIBRARY_ORIGIN), \ >> 83: LIBS := -framework Cocoa -framework SystemConfiguration \ >> 84: -framework Kerberos -ljava, \ > > The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ?? I tried removing it and the build runs fine. But I remember I have seen some error before. > src/java.base/macosx/classes/apple/security/KeychainStore.java line 820: > >> 818: private void createKeyEntry(String alias, long creationDate, long secKeyRef, >> 819: long[] secCertificateRefs, byte[][] rawCertData) { >> 820: KeyEntry ke = new KeyEntry(); > > removing these exceptions is presumably just clean up - not directly related ?? Yes. > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28: > >> 26: #import "apple_security_KeychainStore.h" >> 27: #include "jni.h" >> 28: #include "jni_util.h" > > jni_util.h includes jni.h so I don't understand the need for this change. > Also why did you change import to include ? import is the Obj-C norm ... Will fix. > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: > >> 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, >> 618: JNI_ABORT); >> 619: } > > Although you have it in the later code, here you are missing > @catch (NSException *e) { > NSLog(@"%@", [e callStackSymbols]); > } Will add. BTW, will these be shown on stdout or stderr? If so, is this a good idea? > src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: > >> 55: } >> 56: } >> 57: (*localVM)->DetachCurrentThread(localVM); > > I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From prr at openjdk.java.net Fri Jan 29 22:08:40 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 22:08:40 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 21:47:32 GMT, Weijun Wang wrote: >> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: >> >>> 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, >>> 618: JNI_ABORT); >>> 619: } >> >> Although you have it in the later code, here you are missing >> @catch (NSException *e) { >> NSLog(@"%@", [e callStackSymbols]); >> } > > Will add. > > BTW, will these be shown on stdout or stderr? If so, is this a good idea? should be stderr. Whether to log is up to you. You could wrap it in something that checks for a debug build. The idea is that if this ever happens there is a serious problem. NSException is only thrown (by the OS frameworks) in supposedly fatal scenarios. >> src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: >> >>> 55: } >>> 56: } >>> 57: (*localVM)->DetachCurrentThread(localVM); >> >> I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. > > So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. Yes that is the idea. BTW which thread was it attached to in what you saw ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 22:38:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 22:38:39 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race wrote: >> So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. > > Yes that is the idea. BTW which thread was it attached to in what you saw ? It's a new thread in the main group. After the method finishes, the thread exits (`Thread::exit`). ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 22:47:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 22:47:52 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: phil comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/b0ee18a8..ba3d1a1f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01-02 Stats: 14 lines in 3 files changed: 7 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From prr at openjdk.java.net Sat Jan 30 00:09:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 30 Jan 2021 00:09:44 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 22:47:52 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > phil comment Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From xuelei.fan at oracle.com Sat Jan 30 00:23:04 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Sat, 30 Jan 2021 00:23:04 +0000 Subject: RFR [17]: JDK-8260310 Release Note: Configurable extensions with system properties Message-ID: <75055880-A671-4201-AD00-DFE49CCF505B@ORACLE.COM> Hi, May I have the following release note reviewed: https://bugs.openjdk.java.net/browse/JDK-8260310 Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Sat Jan 30 00:23:43 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 30 Jan 2021 00:23:43 GMT Subject: Integrated: 8217633: Configurable extensions with system properties In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 23:20:34 GMT, Xue-Lei Andrew Fan wrote: > The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed. > > With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections. Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to established if a mandatory extension is blocked. Please don't use this feature unless you clearly understand the impact. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 > CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 This pull request has now been integrated. Changeset: 71bfe962 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/71bfe962 Stats: 145 lines in 2 files changed: 121 ins; 1 del; 23 mod 8217633: Configurable extensions with system properties Reviewed-by: rhalade, jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/1752 From jamil.j.nimeh at oracle.com Sat Jan 30 00:41:03 2021 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 29 Jan 2021 16:41:03 -0800 Subject: RFR [17]: JDK-8260310 Release Note: Configurable extensions with system properties In-Reply-To: <75055880-A671-4201-AD00-DFE49CCF505B@ORACLE.COM> References: <75055880-A671-4201-AD00-DFE49CCF505B@ORACLE.COM> Message-ID: <39455790-fa40-ce62-5f57-73e0cad55c74@oracle.com> Hi Xuelei, looks good overall, some minor suggestions only: * 1st paragraph: Change "...block extensions used in client side" and "...used to block extensions used in server side" to say "...used in the client." and "...used in the server." (you can remove the "side" words). * 1st paragraph: if you use "neither" then you should follow it with "nor" rather than "or" * The 3rd paragraph's leading sentence is a fragment.? You might be able to remove that sentence entirely without changing the meaning behind the paragraph.? With that first sentence removed and the "But" from the next sentence also omitted I think it reads a little more smoothly, at least to my eyes. * I'm not sure if we have any style guide rules concerning contractions in release notes, but I think changing "don't" -> "do not" also reads better for these kinds of things. --Jamil On 1/29/2021 4:23 PM, Xue-Lei Fan wrote: > Hi, > > May I have the following release note reviewed: > https://bugs.openjdk.java.net/browse/JDK-8260310 > > > > Thanks, > Xuelei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Jan 30 00:52:23 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Sat, 30 Jan 2021 00:52:23 +0000 Subject: RFR [17]: JDK-8260310 Release Note: Configurable extensions with system properties In-Reply-To: <39455790-fa40-ce62-5f57-73e0cad55c74@oracle.com> References: <75055880-A671-4201-AD00-DFE49CCF505B@ORACLE.COM> <39455790-fa40-ce62-5f57-73e0cad55c74@oracle.com> Message-ID: <005B6029-FC5A-4396-9412-FFDCE91C39A4@ORACLE.COM> Hi Jamil, All good catches! Thanks for the review. I updated accordingly. Xuelei On Jan 29, 2021, at 4:41 PM, Jamil Nimeh > wrote: Hi Xuelei, looks good overall, some minor suggestions only: * 1st paragraph: Change "...block extensions used in client side" and "...used to block extensions used in server side" to say "...used in the client." and "...used in the server." (you can remove the "side" words). * 1st paragraph: if you use "neither" then you should follow it with "nor" rather than "or" * The 3rd paragraph's leading sentence is a fragment. You might be able to remove that sentence entirely without changing the meaning behind the paragraph. With that first sentence removed and the "But" from the next sentence also omitted I think it reads a little more smoothly, at least to my eyes. * I'm not sure if we have any style guide rules concerning contractions in release notes, but I think changing "don't" -> "do not" also reads better for these kinds of things. --Jamil On 1/29/2021 4:23 PM, Xue-Lei Fan wrote: Hi, May I have the following release note reviewed: https://bugs.openjdk.java.net/browse/JDK-8260310 Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Sat Jan 30 15:23:09 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 15:23:09 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v4] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: end values should be vectors ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/ba3d1a1f..a0cad8fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02-03 Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Sat Jan 30 18:07:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 18:07:22 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v5] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: a test only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/a0cad8fd..38616b32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03-04 Stats: 200 lines in 3 files changed: 199 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Sat Jan 30 18:07:23 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 18:07:23 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> phil comment > > Marked as reviewed by prr (Reviewer). Added a test. Unfortunately it has to be `manual` because updating the dynamic store needs `sudo` privilege. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From anders.rundgren.net at gmail.com Sun Jan 31 07:12:45 2021 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sun, 31 Jan 2021 08:12:45 +0100 Subject: Keytool does not agree with RFC 8410 Message-ID: Since the JDK bug report tool does not include "keytool" I posted this here. Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate? containing the following public key: 148:???? SEQUENCE { ?150:?????? SEQUENCE { ?152:???????? OBJECT IDENTIFIER X25519 (1.3.101.110) ??????????? } ?157:?????? BIT STRING, 32 bytes ????? 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' ????? 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' ????????? } which seems to be aligned with: https://tools.ietf.org/html/rfc8410#section-10.2 You can verify this issue by importing the certificate in the RFC. Anders From weijun at openjdk.java.net Sun Jan 31 18:45:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 31 Jan 2021 18:45:19 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - move test - Merge branch 'master' into 8257858 - a test only in patch2: unchanged: - end values should be vectors - phil comment - same behavior as before -- empty realm map - error check, new JavaStringToNSString - do not find class and method in loop - no more header file reverted: - better macro, no more JNI_COCOA_ENTER - ... and 5 more: https://git.openjdk.java.net/jdk/compare/bb728c47...ef337f12 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/38616b32..ef337f12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=04-05 Stats: 33763 lines in 708 files changed: 13479 ins; 10043 del; 10241 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun.wang at oracle.com Sun Jan 31 19:00:14 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Sun, 31 Jan 2021 19:00:14 +0000 Subject: Keytool does not agree with RFC 8410 In-Reply-To: References: Message-ID: https://bugs.openjdk.java.net/browse/JDK-8260693 filed. Thanks, Max > On Jan 31, 2021, at 2:12 AM, Anders Rundgren wrote: > > Since the JDK bug report tool does not include "keytool" I posted this here. > > Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate containing the following public key: > > 148: SEQUENCE { > 150: SEQUENCE { > 152: OBJECT IDENTIFIER X25519 (1.3.101.110) > } > 157: BIT STRING, 32 bytes > 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' > 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' > } > > which seems to be aligned with: https://tools.ietf.org/html/rfc8410#section-10.2 > > You can verify this issue by importing the certificate in the RFC. > > Anders From akozlov at openjdk.java.net Sun Jan 31 20:14:01 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 31 Jan 2021 20:14:01 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - Revert harfbuzz changes, disable warnings for it - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. - Refactor CDS disabling - Redo builsys support for aarch64-darwin - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07 Stats: 3266 lines in 114 files changed: 3164 ins; 41 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Sun Jan 31 20:14:02 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Sun, 31 Jan 2021 20:14:02 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley wrote: >> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. > > I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. Hello Does this look like something in the right direction ? https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From davin.kevin at gmail.com Sat Jan 30 09:13:30 2021 From: davin.kevin at gmail.com (Kevin Davin) Date: Sat, 30 Jan 2021 10:13:30 +0100 Subject: fix(truststore): log about truststore not found prints every time the same value Message-ID: Hi everyone, I'm contacting you because I've opened a PR to fix a bug, but it seems to be required to have an issue associated with it. The OCA team said to me I've to ask you to open one for me. Is it ok for you ? Without it, my PR is blocked https://github.com/openjdk/jdk/pull/1690, and the bridgekeeper bot said it should be close if there is no further activity on this PR. Thank you for your help and support. Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: