From github.com+10835776+stsypanov at openjdk.java.net Thu Jul 1 10:38:28 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 1 Jul 2021 10:38:28 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v2] In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? 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 8268764 > - 8268764: Use Long.hashCode() instead of int-cast where applicable Hi Kevin, thanks for review! I've updated copy-right year ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From github.com+10835776+stsypanov at openjdk.java.net Thu Jul 1 10:38:24 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 1 Jul 2021 10:38:24 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v3] In-Reply-To: References: Message-ID: > In some JDK classes there's still the following hashCode() implementation: > > long objNum; > > public int hashCode() { > return (int) objNum; > } > > This outdated expression should be replaced with Long.hashCode(long) as it > > - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). > > - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. > > See https://stackoverflow.com/a/4045083 > > This is related to https://github.com/openjdk/jdk/pull/4309 ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8268764: Update copy-right year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4491/files - new: https://git.openjdk.java.net/jdk/pull/4491/files/12a1d3ac..932c26ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=01-02 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491 From kevinw at openjdk.java.net Thu Jul 1 11:39:00 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 1 Jul 2021 11:39:00 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Marked as reviewed by kevinw (Committer). OK, one more (C) in src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java and done. 8-) Needs a second Review before integrating, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From github.com+10835776+stsypanov at openjdk.java.net Thu Jul 1 12:19:53 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 1 Jul 2021 12:19:53 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: > In some JDK classes there's still the following hashCode() implementation: > > long objNum; > > public int hashCode() { > return (int) objNum; > } > > This outdated expression should be replaced with Long.hashCode(long) as it > > - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). > > - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. > > See https://stackoverflow.com/a/4045083 > > This is related to https://github.com/openjdk/jdk/pull/4309 ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8268764: Update copy-right year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4491/files - new: https://git.openjdk.java.net/jdk/pull/4491/files/932c26ad..20ad76be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491 From github.com+10835776+stsypanov at openjdk.java.net Thu Jul 1 12:19:55 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 1 Jul 2021 12:19:55 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Right, done! ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From lancea at openjdk.java.net Thu Jul 1 15:14:02 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 1 Jul 2021 15:14:02 GMT Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2] In-Reply-To: References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com> Message-ID: On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update cache key from String to Class Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/166 From alanb at openjdk.java.net Fri Jul 2 11:53:02 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 2 Jul 2021 11:53:02 GMT Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2] In-Reply-To: References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com> Message-ID: On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update cache key from String to Class Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/166 From dfuchs at openjdk.java.net Fri Jul 2 13:10:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 2 Jul 2021 13:10:03 GMT Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2] In-Reply-To: References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com> Message-ID: <9-2TmhbxjWMwweT6MU1z_NII6-dFS9I9gmfq2DALNR0=.41d9d65a-fec8-4945-a23c-1037915030e7@github.com> On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update cache key from String to Class Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/166 From weijun at openjdk.java.net Fri Jul 2 14:34:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Jul 2021 14:34:55 GMT Subject: [jdk17] Integrated: 8269543: The warning for System::setSecurityManager should only appear once for each caller In-Reply-To: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com> References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com> Message-ID: On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang wrote: > Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each. This pull request has now been integrated. Changeset: c4ea13ed Author: Weijun Wang URL: https://git.openjdk.java.net/jdk17/commit/c4ea13edd036bd6aeb213bb5391dd374d283d382 Stats: 59 lines in 2 files changed: 40 ins; 6 del; 13 mod 8269543: The warning for System::setSecurityManager should only appear once for each caller Reviewed-by: lancea, alanb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk17/pull/166 From ascarpino at openjdk.java.net Fri Jul 2 19:23:12 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Jul 2021 19:23:12 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers Message-ID: Hi, I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. thanks Tony ------------- Commit messages: - cleanup - initial checkin Changes: https://git.openjdk.java.net/jdk/pull/4672/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269827 Stats: 293 lines in 2 files changed: 293 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4672/head:pull/4672 PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Fri Jul 2 23:30:17 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Jul 2021 23:30:17 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: merge AESGCMByteArray with existing AESGCMBench ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4672/files - new: https://git.openjdk.java.net/jdk/pull/4672/files/ad463039..0c7113ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=00-01 Stats: 205 lines in 4 files changed: 38 ins; 147 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4672/head:pull/4672 PR: https://git.openjdk.java.net/jdk/pull/4672 From yyang at openjdk.java.net Mon Jul 5 06:04:50 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Jul 2021 06:04:50 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Class loading order is different to class initialization order. > > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. > > Thanks, > David @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From dholmes at openjdk.java.net Mon Jul 5 06:32:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Jul 2021 06:32:54 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang wrote: >> Class loading order is different to class initialization order. >> >> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. >> >> Thanks, >> David > > @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks. @kelthuzadx I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Mon Jul 5 08:06:54 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Jul 2021 08:06:54 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang wrote: >> Class loading order is different to class initialization order. >> >> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. >> >> Thanks, >> David > > @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks. > @kelthuzadx I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not. > > Cheers, > David Hi David, the following are initialization orders: $./java -Xlog:class+init -version [0.255s][info][class,init] 0 Initializing 'java/lang/Object'(no method) (0x0000000800000e18) [0.255s][info][class,init] 1 Initializing 'java/lang/CharSequence'(no method) (0x000000080006ba68) [0.255s][info][class,init] 2 Initializing 'java/lang/String' (0x000000080000e978) [0.255s][info][class,init] 3 Initializing 'java/util/Comparator'(no method) (0x00000008000fd760) [0.255s][info][class,init] 4 Initializing 'java/lang/String$CaseInsensitiveComparator'(no method) (0x0000000800130988) [0.255s][info][class,init] 5 Initializing 'java/lang/System' (0x0000000800008c68) [0.256s][info][class,init] 6 Initializing 'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001f88) [0.256s][info][class,init] 7 Initializing 'java/lang/reflect/Type'(no method) (0x0000000800002930) [0.256s][info][class,init] 8 Initializing 'java/lang/Class' (0x0000000800001830) [0.256s][info][class,init] 9 Initializing 'java/lang/ThreadGroup'(no method) (0x000000080001d348) [0.257s][info][class,init] 10 Initializing 'java/lang/Thread' (0x000000080001c470) [0.258s][info][class,init] 11 Initializing 'java/security/AccessController' (0x0000000800009a80) [0.258s][info][class,init] 12 Initializing 'java/security/AccessControlContext' (0x00000008000743c8) [0.258s][info][class,init] 13 Initializing 'java/lang/Module' (0x000000080000bab0) [0.259s][info][class,init] 14 Initializing 'java/lang/Module$ArchivedData' (0x00000008001a05a8) [0.259s][info][class,init] 15 Initializing 'jdk/internal/misc/CDS' (0x0000000800018bf8) [0.259s][info][class,init] 16 Initializing 'java/lang/Iterable'(no method) (0x000000080008be28) [0.259s][info][class,init] 17 Initializing 'java/util/Collection'(no method) (0x000000080008c028) [0.260s][info][class,init] 18 Initializing 'java/util/AbstractCollection'(no method) (0x00000008000381e0) [0.260s][info][class,init] 19 Initializing 'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x000000080008c2f8) [0.260s][info][class,init] 20 Initializing 'java/util/Set'(no method) (0x00000008000189f8) [0.260s][info][class,init] 21 Initializing 'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x000000080008d018) [0.260s][info][class,init] 22 Initializing 'java/util/ImmutableCollections$Set12'(no method) (0x000000080008ba18) [0.369s][info][class,init] 23 Initializing 'jdk/internal/misc/UnsafeConstants' (0x00000008000b4ea0) [0.369s][info][class,init] 24 Initializing 'java/lang/reflect/AccessibleObject' (0x000000080005b4d8) [0.370s][info][class,init] 25 Initializing 'java/lang/reflect/ReflectAccess'(no method) (0x0000000800013610) [0.370s][info][class,init] 26 Initializing 'jdk/internal/access/SharedSecrets' (0x0000000800013408) [0.370s][info][class,init] 27 Initializing 'java/lang/invoke/MethodHandles' (0x0000000800131720) [0.371s][info][class,init] 28 Initializing 'java/lang/invoke/MemberName' (0x00000008000de230) [0.371s][info][class,init] 29 Initializing 'java/lang/invoke/MemberName$Factory' (0x0000000800023468) [0.372s][info][class,init] 30 Initializing 'java/security/Permission'(no method) (0x0000000800023020) [0.372s][info][class,init] 31 Initializing 'java/security/BasicPermission'(no method) (0x0000000800025de8) [0.372s][info][class,init] 32 Initializing 'java/lang/reflect/ReflectPermission'(no method) (0x0000000800025b98) [0.372s][info][class,init] 33 Initializing 'java/lang/StringLatin1' (0x0000000800022e18) [0.373s][info][class,init] 34 Initializing 'java/lang/invoke/MethodHandles$Lookup' (0x00000008000e3708) [0.373s][info][class,init] 35 Initializing 'java/util/Objects'(no method) (0x000000080008b810) [0.374s][info][class,init] 36 Initializing 'jdk/internal/reflect/Reflection' (0x000000080000fb28) [0.374s][info][class,init] 37 Initializing 'java/util/ImmutableCollections' (0x000000080008d420) [0.374s][info][class,init] 38 Initializing 'java/util/List'(no method) (0x000000080008e460) [0.374s][info][class,init] 39 Initializing 'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x000000080008c670) [0.374s][info][class,init] 40 Initializing 'java/util/ImmutableCollections$ListN'(no method) (0x00000008001d2ad0) [0.374s][info][class,init] 41 Initializing 'java/util/ImmutableCollections$SetN'(no method) (0x000000080018fd58) [0.375s][info][class,init] 42 Initializing 'java/util/Map'(no method) (0x0000000800018368) [0.375s][info][class,init] 43 Initializing 'java/util/AbstractMap'(no method) (0x0000000800057d08) [0.375s][info][class,init] 44 Initializing 'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x000000080011aef8) [0.375s][info][class,init] 45 Initializing 'java/util/ImmutableCollections$MapN'(no method) (0x000000080018a888) [0.487s][info][class,init] 46 Initializing 'java/lang/Math' (0x0000000800027918) [0.488s][info][class,init] 47 Initializing 'java/lang/Number'(no method) (0x000000080003fd18) [0.488s][info][class,init] 48 Initializing 'java/lang/Float' (0x0000000800048978) [0.488s][info][class,init] 49 Initializing 'java/lang/Double' (0x000000080004a478) [0.488s][info][class,init] 50 Initializing 'java/util/HashMap'(no method) (0x000000080011a6a0) [0.489s][info][class,init] 51 Initializing 'java/lang/Integer' (0x000000080004bb58) [0.489s][info][class,init] 52 Initializing 'java/util/AbstractSet'(no method) (0x000000080011ced8) [0.489s][info][class,init] 53 Initializing 'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001e0f10) [0.489s][info][class,init] 54 Initializing 'java/util/Iterator'(no method) (0x00000008000047d8) [0.489s][info][class,init] 55 Initializing 'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000192c0) [0.490s][info][class,init] 56 Initializing 'java/util/KeyValueHolder'(no method) (0x000000080016d540) [0.490s][info][class,init] 57 Initializing 'java/util/HashMap$Node'(no method) (0x000000080016c8f8) [0.491s][info][class,init] 58 Initializing 'java/util/concurrent/ConcurrentMap'(no method) (0x00000008001872d8) [0.491s][info][class,init] 59 Initializing 'java/util/concurrent/ConcurrentHashMap' (0x000000080000e3d0) [0.491s][info][class,init] 60 Initializing 'java/lang/Runtime' (0x000000080016c650) [0.491s][info][class,init] 61 Initializing 'java/io/ObjectStreamField'(no method) (0x00000008000fd960) [0.492s][info][class,init] 62 Initializing 'jdk/internal/misc/Unsafe' (0x0000000800010140) [0.493s][info][class,init] 63 Initializing 'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x0000000800146b08) [0.494s][info][class,init] 64 Initializing 'jdk/internal/reflect/ReflectionFactory' (0x000000080005a630) [0.494s][info][class,init] 65 Initializing 'java/lang/ref/Reference' (0x00000008000533f8) [0.494s][info][class,init] 66 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x0000000800054af8) [0.495s][info][class,init] 67 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800053640) [0.495s][info][class,init] 68 Initializing 'jdk/internal/ref/Cleaner' (0x00000008000548a0) [0.495s][info][class,init] 69 Initializing 'java/lang/ref/ReferenceQueue' (0x000000080005a1a8) [0.495s][info][class,init] 70 Initializing 'java/lang/ref/ReferenceQueue$Null'(no method) (0x000000080005a3e8) [0.495s][info][class,init] 71 Initializing 'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001f3cd8) [0.496s][info][class,init] 72 Initializing 'java/lang/ref/Reference$1'(no method) (0x000000080005aab0) [0.496s][info][class,init] 73 Initializing 'java/lang/reflect/Executable'(no method) (0x000000080005b798) [0.496s][info][class,init] 74 Initializing 'java/lang/reflect/Method'(no method) (0x000000080005c430) [0.496s][info][class,init] 75 Initializing 'java/lang/ref/FinalReference'(no method) (0x00000008000553d8) [0.496s][info][class,init] 76 Initializing 'java/lang/ref/Finalizer' (0x0000000800055620) [0.496s][info][class,init] 77 Initializing 'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x000000080017e790) [0.497s][info][class,init] 78 Initializing 'java/lang/System$2'(no method) (0x0000000800015b68) [0.498s][info][class,init] 79 Initializing 'jdk/internal/util/SystemProps' (0x0000000800015960) [0.498s][info][class,init] 80 Initializing 'jdk/internal/util/SystemProps$Raw'(no method) (0x000000080009e300) [0.499s][info][class,init] 81 Initializing 'jdk/internal/misc/VM' (0x000000080000fd30) [0.500s][info][class,init] 82 Initializing 'java/lang/StringConcatHelper' (0x0000000800016308) [0.500s][info][class,init] 83 Initializing 'java/lang/Byte' (0x0000000800040330) [0.500s][info][class,init] 84 Initializing 'java/lang/VersionProps' (0x0000000800016100) [0.502s][info][class,init] 85 Initializing 'java/util/Arrays' (0x0000000800027b20) [0.502s][info][class,init] 86 Initializing 'java/lang/Character' (0x000000080003e1c8) [0.502s][info][class,init] 87 Initializing 'java/lang/CharacterData'(no method) (0x00000008000449a8) [0.503s][info][class,init] 88 Initializing 'java/lang/CharacterDataLatin1' (0x0000000800044638) [0.503s][info][class,init] 89 Initializing 'java/lang/Integer$IntegerCache' (0x000000080003fb10) [0.624s][info][class,init] 90 Initializing 'java/util/Dictionary'(no method) (0x0000000800016970) [0.624s][info][class,init] 91 Initializing 'java/util/Hashtable'(no method) (0x0000000800016bb0) [0.624s][info][class,init] 92 Initializing 'java/util/Properties' (0x0000000800016510) [0.624s][info][class,init] 93 Initializing 'java/util/HashMap$EntrySet'(no method) (0x00000008001f0b48) [0.624s][info][class,init] 94 Initializing 'java/util/HashMap$HashIterator'(no method) (0x00000008000199f0) [0.624s][info][class,init] 95 Initializing 'java/util/HashMap$EntryIterator'(no method) (0x0000000800019c00) [0.625s][info][class,init] 96 Initializing 'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001be7b8) [0.626s][info][class,init] 97 Initializing 'jdk/internal/util/StaticProperty' (0x00000008000197e8) [0.626s][info][class,init] 98 Initializing 'java/io/InputStream'(no method) (0x000000080001a100) [0.626s][info][class,init] 99 Initializing 'java/io/FileInputStream' (0x0000000800019e48) [0.627s][info][class,init] 100 Initializing 'java/io/FileDescriptor' (0x000000080001ac70) [0.627s][info][class,init] 101 Initializing 'java/io/FileDescriptor$1'(no method) (0x00000008001fe1d8) [0.627s][info][class,init] 102 Initializing 'java/io/OutputStream'(no method) (0x0000000800013cf8) [0.628s][info][class,init] 103 Initializing 'java/io/FileOutputStream' (0x000000080001ae80) [0.628s][info][class,init] 104 Initializing 'java/io/FilterInputStream'(no method) (0x000000080001b630) [0.628s][info][class,init] 105 Initializing 'java/io/BufferedInputStream' (0x000000080001b378) [0.628s][info][class,init] 106 Initializing 'java/io/FilterOutputStream'(no method) (0x0000000800013f70) [0.629s][info][class,init] 107 Initializing 'java/io/PrintStream'(no method) (0x0000000800013948) [0.629s][info][class,init] 108 Initializing 'java/io/BufferedOutputStream'(no method) (0x0000000800018568) [0.629s][info][class,init] 109 Initializing 'java/nio/charset/Charset' (0x000000080009e0a0) [0.629s][info][class,init] 110 Initializing 'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001f45c8) [0.629s][info][class,init] 111 Initializing 'sun/nio/cs/StandardCharsets' (0x00000008001f47e0) [0.629s][info][class,init] 112 Initializing 'java/lang/ThreadLocal' (0x0000000800027d28) [0.630s][info][class,init] 113 Initializing 'java/util/concurrent/atomic/AtomicInteger' (0x0000000800027f70) [0.630s][info][class,init] 114 Initializing 'sun/nio/cs/Unicode'(no method) (0x000000080009eba8) [0.630s][info][class,init] 115 Initializing 'sun/nio/cs/UTF_8' (0x000000080009ee28) [0.631s][info][class,init] 116 Initializing 'java/io/Writer'(no method) (0x00000008000fa5e0) [0.631s][info][class,init] 117 Initializing 'java/io/OutputStreamWriter'(no method) (0x00000008000fb258) [0.631s][info][class,init] 118 Initializing 'sun/nio/cs/StreamEncoder' (0x00000008000fc1e0) [0.632s][info][class,init] 119 Initializing 'java/nio/charset/CharsetEncoder' (0x00000008000f98c0) [0.632s][info][class,init] 120 Initializing 'sun/nio/cs/UTF_8$Encoder'(no method) (0x00000008010403e0) [0.632s][info][class,init] 121 Initializing 'java/nio/charset/CodingErrorAction' (0x00000008000b6120) [0.633s][info][class,init] 122 Initializing 'java/nio/Buffer' (0x000000080007e418) [0.635s][info][class,init] 123 Initializing 'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000b52a8) [0.636s][info][class,init] 124 Initializing 'java/nio/Buffer$1'(no method) (0x00000008001d5338) [0.636s][info][class,init] 125 Initializing 'java/nio/ByteBuffer' (0x0000000800084418) [0.637s][info][class,init] 126 Initializing 'java/nio/HeapByteBuffer' (0x0000000800207160) [0.637s][info][class,init] 127 Initializing 'java/nio/ByteOrder' (0x000000080001bf60) [0.638s][info][class,init] 128 Initializing 'java/io/BufferedWriter' (0x000000080001c170) [0.638s][info][class,init] 129 Initializing 'java/lang/Terminator' (0x000000080001bd58) [0.638s][info][class,init] 130 Initializing 'java/lang/Terminator$1'(no method) (0x0000000800091328) [0.638s][info][class,init] 131 Initializing 'jdk/internal/misc/Signal' (0x0000000800091118) [0.639s][info][class,init] 132 Initializing 'java/util/Hashtable$Entry'(no method) (0x0000000800188278) [0.639s][info][class,init] 133 Initializing 'jdk/internal/misc/Signal$Handler' (0x0000000800091550) [0.639s][info][class,init] 134 Initializing 'jdk/internal/misc/Signal$NativeHandler'(no method) (0x000000080020dd80) [0.639s][info][class,init] 135 Initializing 'jdk/internal/misc/OSEnvironment'(no method) (0x0000000800037dc8) [0.640s][info][class,init] 136 Initializing 'java/lang/Throwable' (0x00000008000339d8) [0.640s][info][class,init] 137 Initializing 'java/util/Collections' (0x0000000800037bc0) [0.640s][info][class,init] 138 Initializing 'java/util/Collections$EmptySet'(no method) (0x000000080011d2e0) [0.640s][info][class,init] 139 Initializing 'java/util/AbstractList'(no method) (0x000000080008e660) [0.640s][info][class,init] 140 Initializing 'java/util/Collections$EmptyList'(no method) (0x00000008001c97d0) [0.641s][info][class,init] 141 Initializing 'java/util/Collections$EmptyMap'(no method) (0x0000000800058498) [0.641s][info][class,init] 142 Initializing 'java/lang/Error'(no method) (0x0000000800035558) [0.641s][info][class,init] 143 Initializing 'java/lang/VirtualMachineError'(no method) (0x00000008000357b8) [0.641s][info][class,init] 144 Initializing 'java/lang/OutOfMemoryError'(no method) (0x0000000800099da8) [0.641s][info][class,init] 145 Initializing 'java/lang/Exception'(no method) (0x0000000800033c38) [0.641s][info][class,init] 146 Initializing 'java/lang/RuntimeException'(no method) (0x0000000800034e08) [0.641s][info][class,init] 147 Initializing 'java/lang/NullPointerException'(no method) (0x0000000800099950) [0.641s][info][class,init] 148 Initializing 'java/lang/ClassCastException'(no method) (0x000000080009a5f8) [0.641s][info][class,init] 149 Initializing 'java/lang/ArrayStoreException'(no method) (0x0000000800035ed8) [0.641s][info][class,init] 150 Initializing 'java/lang/ArithmeticException'(no method) (0x00000008000996f0) [0.641s][info][class,init] 151 Initializing 'java/lang/StackOverflowError'(no method) (0x0000000800035a18) [0.641s][info][class,init] 152 Initializing 'java/lang/IllegalMonitorStateException'(no method) (0x00000008000570e0) [0.641s][info][class,init] 153 Initializing 'java/lang/IllegalArgumentException'(no method) (0x0000000800035068) [0.643s][info][class,init] 154 Initializing 'java/lang/invoke/MethodHandle' (0x00000008000c8200) [0.644s][info][class,init] 155 Initializing 'java/lang/invoke/MethodHandleStatics' (0x000000080001e260) [0.644s][info][class,init] 156 Initializing 'sun/security/action/GetPropertyAction'(no method) (0x00000008000fa3a8) [0.644s][info][class,init] 157 Initializing 'java/lang/Boolean' (0x0000000800038f10) [0.645s][info][class,init] 158 Initializing 'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000e1fc0) [0.645s][info][class,init] 159 Initializing 'java/lang/invoke/MethodHandleNatives' (0x00000008000e22b0) [0.645s][info][class,init] 160 Initializing 'jdk/internal/module/ModuleBootstrap' (0x000000080001e058) [0.646s][info][class,init] 161 Initializing 'sun/invoke/util/VerifyAccess' (0x000000080007a938) [0.646s][info][class,init] 162 Initializing 'java/lang/reflect/Modifier'(no method) (0x000000080007a730) [0.647s][info][class,init] 163 Initializing 'java/lang/module/ModuleDescriptor' (0x000000080013a608) [0.647s][info][class,init] 164 Initializing 'java/lang/module/ModuleDescriptor$1'(no method) (0x000000080007a258) [0.647s][info][class,init] 165 Initializing 'java/io/File' (0x0000000800079ec0) [0.648s][info][class,init] 166 Initializing 'java/io/DefaultFileSystem'(no method) (0x00000008000afa80) [0.648s][info][class,init] 167 Initializing 'java/io/FileSystem' (0x00000008000adb08) [0.648s][info][class,init] 168 Initializing 'java/io/UnixFileSystem' (0x00000008000addf0) [0.649s][info][class,init] 169 Initializing 'java/lang/AbstractStringBuilder' (0x000000080006c268) [0.649s][info][class,init] 170 Initializing 'java/lang/StringBuilder'(no method) (0x000000080000f478) [0.650s][info][class,init] 171 Initializing 'jdk/internal/util/ArraysSupport' (0x00000008000ad900) [0.650s][info][class,init] 172 Initializing 'jdk/internal/module/ModulePatcher' (0x00000008001945b0) [0.651s][info][class,init] 173 Initializing 'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800192aa8) [0.651s][info][class,init] 174 Initializing 'jdk/internal/module/ArchivedBootLayer' (0x0000000800192890) [0.651s][info][class,init] 175 Initializing 'java/lang/ModuleLayer' (0x0000000800175c40) [0.651s][info][class,init] 176 Initializing 'java/lang/module/Configuration' (0x000000080018e820) [0.918s][info][class,init] 177 Initializing 'jdk/internal/loader/AbstractClassLoaderValue' (0x000000080018eeb0) [0.918s][info][class,init] 178 Initializing 'jdk/internal/loader/ClassLoaderValue'(no method) (0x000000080018f0f8) [0.918s][info][class,init] 179 Initializing 'java/util/ImmutableCollections$List12'(no method) (0x000000080008cb40) [0.918s][info][class,init] 180 Initializing 'java/lang/module/ResolvedModule'(no method) (0x00000008001917c8) [0.918s][info][class,init] 181 Initializing 'java/lang/module/ModuleReference'(no method) (0x00000008000d1f40) [0.918s][info][class,init] 182 Initializing 'jdk/internal/module/ModuleReferenceImpl'(no method) (0x000000080018bf00) [0.918s][info][class,init] 183 Initializing 'java/lang/module/ModuleDescriptor$Version'(no method) (0x000000080018ceb8) [0.918s][info][class,init] 184 Initializing 'java/util/ArrayList' (0x000000080000dea8) [0.919s][info][class,init] 185 Initializing 'java/lang/module/ModuleDescriptor$Requires' (0x0000000800178b80) [0.919s][info][class,init] 186 Initializing 'java/lang/Enum'(no method) (0x0000000800007880) [0.919s][info][class,init] 187 Initializing 'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x0000000800094980) [0.919s][info][class,init] 188 Initializing 'java/lang/module/ModuleDescriptor$Exports'(no method) (0x0000000800178958) [0.919s][info][class,init] 189 Initializing 'java/lang/module/ModuleDescriptor$Provides'(no method) (0x000000080018d0e0) [0.919s][info][class,init] 190 Initializing 'java/net/URI' (0x0000000800192228) [0.920s][info][class,init] 191 Initializing 'java/net/URI$1'(no method) (0x000000080022bb10) [0.920s][info][class,init] 192 Initializing 'jdk/internal/module/SystemModuleFinders$2'(no method) (0x000000080018bcc8) [0.920s][info][class,init] 193 Initializing 'jdk/internal/module/SystemModuleFinders$3'(no method) (0x00000008001947c0) [0.920s][info][class,init] 194 Initializing 'jdk/internal/module/ModuleTarget'(no method) (0x0000000800225ca0) [0.920s][info][class,init] 195 Initializing 'jdk/internal/module/ModuleHashes'(no method) (0x00000008001941a0) [0.920s][info][class,init] 196 Initializing 'java/util/Collections$UnmodifiableMap'(no method) (0x0000000800213c70) [0.920s][info][class,init] 197 Initializing 'java/lang/module/ModuleDescriptor$Opens'(no method) (0x0000000800178730) [0.920s][info][class,init] 198 Initializing 'java/util/HashSet' (0x000000080011cac8) [0.920s][info][class,init] 199 Initializing 'java/lang/ClassLoader' (0x0000000800008e70) [0.921s][info][class,init] 200 Initializing 'java/security/SecureClassLoader' (0x0000000800009450) [0.921s][info][class,init] 201 Initializing 'java/lang/ClassLoader$ParallelLoaders' (0x000000080000f270) [0.921s][info][class,init] 202 Initializing 'java/util/WeakHashMap' (0x0000000800057948) [0.922s][info][class,init] 203 Initializing 'java/util/Collections$SetFromMap'(no method) (0x000000080021a8c8) [0.922s][info][class,init] 204 Initializing 'java/util/WeakHashMap$KeySet'(no method) (0x000000080017b698) [0.922s][info][class,init] 205 Initializing 'java/lang/ref/WeakReference'(no method) (0x0000000800055a20) [0.922s][info][class,init] 206 Initializing 'java/util/WeakHashMap$Entry'(no method) (0x00000008000576a8) [0.923s][info][class,init] 207 Initializing 'jdk/internal/loader/BuiltinClassLoader' (0x0000000800009748) [0.923s][info][class,init] 208 Initializing 'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001bda48) [0.923s][info][class,init] 209 Initializing 'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001be2c8) [0.923s][info][class,init] 210 Initializing 'java/security/ProtectionDomain' (0x000000080000ec18) [0.923s][info][class,init] 211 Initializing 'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x000000080017b240) [0.923s][info][class,init] 212 Initializing 'java/security/CodeSource'(no method) (0x000000080000ee38) [0.923s][info][class,init] 213 Initializing 'java/security/Principal'(no method) (0x000000080017be08) [0.923s][info][class,init] 214 Initializing 'java/security/ProtectionDomain$Key'(no method) (0x000000080017b038) [0.923s][info][class,init] 215 Initializing 'jdk/internal/loader/NativeLibraries' (0x000000080000f060) [0.924s][info][class,init] 216 Initializing 'java/util/ArrayDeque'(no method) (0x0000000800169620) [0.924s][info][class,init] 217 Initializing 'jdk/internal/module/ServicesCatalog' (0x000000080013cb28) [0.924s][info][class,init] 218 Initializing 'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x0000000800231220) [0.924s][info][class,init] 219 Initializing 'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x0000000800231730) [0.924s][info][class,init] 220 Initializing 'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x00000008000990b8) [0.924s][info][class,init] 221 Initializing 'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x000000080018ec80) [1.051s][info][class,init] 222 Initializing 'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x0000000800096cc0) [1.176s][info][class,init] 223 Initializing 'jdk/internal/loader/BootLoader' (0x000000080013c1d8) [1.176s][info][class,init] 224 Initializing 'jdk/internal/loader/ClassLoaders' (0x000000080000ff38) [1.177s][info][class,init] 225 Initializing 'jdk/internal/loader/URLClassPath' (0x00000008001b60c8) [1.178s][info][class,init] 226 Initializing 'java/net/URL' (0x0000000800075b88) [1.178s][info][class,init] 227 Initializing 'java/net/URL$DefaultFactory' (0x0000000800094250) [1.178s][info][class,init] 228 Initializing 'java/net/URL$3'(no method) (0x0000000800093e28) [1.179s][info][class,init] 229 Initializing 'java/io/File$PathStatus' (0x0000000800094738) [1.180s][info][class,init] 230 Initializing 'sun/net/www/ParseUtil' (0x0000000800093c20) [1.180s][info][class,init] 231 Initializing 'java/util/HexFormat' (0x0000000800096088) [1.181s][info][class,init] 232 Initializing 'java/net/URLStreamHandler'(no method) (0x00000008001b3148) [1.181s][info][class,init] 233 Initializing 'sun/net/www/protocol/file/Handler'(no method) (0x00000008001b38f8) [1.182s][info][class,init] 234 Initializing 'sun/net/util/IPAddressUtil' (0x0000000800090688) [1.183s][info][class,init] 235 Initializing 'jdk/internal/util/Preconditions'(no method) (0x0000000800090480) [1.184s][info][class,init] 236 Initializing 'java/lang/invoke/StringConcatFactory' (0x000000080001e468) [1.185s][info][class,init] 237 Initializing 'java/util/function/Function'(no method) (0x00000008001151e8) [1.185s][info][class,init] 238 Initializing 'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800235200) [1.185s][info][class,init] 239 Initializing 'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800235770) [1.185s][info][class,init] 240 Initializing 'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800043b98) [1.187s][info][class,init] 241 Initializing 'java/nio/CharBuffer' (0x0000000800081918) [1.187s][info][class,init] 242 Initializing 'java/nio/HeapCharBuffer' (0x0000000800081f90) [1.188s][info][class,init] 243 Initializing 'java/nio/charset/CoderResult' (0x00000008000b5a90) openjdk version "18-internal" 2022-03-15 OpenJDK Runtime Environment (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip) OpenJDK 64-Bit Server VM (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing) [1.192s][info][class,init] 244 Initializing 'java/lang/Shutdown' (0x0000000800050c98) [1.192s][info][class,init] 245 Initializing 'java/lang/Shutdown$Lock'(no method) (0x00000008000264d8) $./java -Xlog:class+init -version [0.020s][info][class,init] 0 Initializing java/lang/Object'java/lang/Object'(no method) (0x0000000800000d68) [0.020s][info][class,init] 1 Initializing java/lang/CharSequence'java/lang/CharSequence'(no method) (0x0000000800065478) [0.020s][info][class,init] 2 Initializing java/lang/String'java/lang/String' (0x000000080000e4a0) [0.020s][info][class,init] 3 Initializing java/util/Comparator'java/util/Comparator'(no method) (0x00000008000ea748) [0.020s][info][class,init] 4 Initializing java/lang/String$CaseInsensitiveComparator'java/lang/String$CaseInsensitiveComparator'(no method) (0x000000080011ba70) [0.020s][info][class,init] 5 Initializing java/lang/System'java/lang/System' (0x00000008000088f8) [0.020s][info][class,init] 6 Initializing java/lang/reflect/AnnotatedElement'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001eb0) [0.020s][info][class,init] 7 Initializing java/lang/reflect/Type'java/lang/reflect/Type'(no method) (0x00000008000027e0) [0.020s][info][class,init] 8 Initializing java/lang/Class'java/lang/Class' (0x0000000800001750) [0.020s][info][class,init] 9 Initializing java/lang/ThreadGroup'java/lang/ThreadGroup'(no method) (0x000000080001c1e8) [0.020s][info][class,init] 10 Initializing java/lang/Thread'java/lang/Thread' (0x000000080001b3d0) [0.020s][info][class,init] 11 Initializing java/security/AccessController'java/security/AccessController' (0x0000000800009738) [0.020s][info][class,init] 12 Initializing java/security/AccessControlContext'java/security/AccessControlContext' (0x000000080006d2c8) [0.020s][info][class,init] 13 Initializing java/lang/Module'java/lang/Module' (0x000000080000b5c0) [0.021s][info][class,init] 14 Initializing java/lang/Module$ArchivedData'java/lang/Module$ArchivedData' (0x0000000800186270) [0.021s][info][class,init] 15 Initializing jdk/internal/misc/CDS'jdk/internal/misc/CDS' (0x0000000800017d08) [0.021s][info][class,init] 16 Initializing java/lang/Iterable'java/lang/Iterable'(no method) (0x0000000800082f10) [0.021s][info][class,init] 17 Initializing java/util/Collection'java/util/Collection'(no method) (0x0000000800083118) [0.021s][info][class,init] 18 Initializing java/util/AbstractCollection'java/util/AbstractCollection'(no method) (0x00000008000357c8) [0.021s][info][class,init] 19 Initializing java/util/ImmutableCollections$AbstractImmutableCollection'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x00000008000833d0) [0.021s][info][class,init] 20 Initializing java/util/Set'java/util/Set'(no method) (0x0000000800017b00) [0.021s][info][class,init] 21 Initializing java/util/ImmutableCollections$AbstractImmutableSet'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x0000000800084108) [0.021s][info][class,init] 22 Initializing java/util/ImmutableCollections$Set12'java/util/ImmutableCollections$Set12'(no method) (0x0000000800082af8) [0.021s][info][class,init] 23 Initializing jdk/internal/misc/UnsafeConstants'jdk/internal/misc/UnsafeConstants' (0x00000008000a7ff0) [0.021s][info][class,init] 24 Initializing java/lang/reflect/AccessibleObject'java/lang/reflect/AccessibleObject' (0x0000000800056450) [0.021s][info][class,init] 25 Initializing java/lang/reflect/ReflectAccess'java/lang/reflect/ReflectAccess'(no method) (0x0000000800012c50) [0.021s][info][class,init] 26 Initializing jdk/internal/access/SharedSecrets'jdk/internal/access/SharedSecrets' (0x0000000800012a40) [0.021s][info][class,init] 27 Initializing java/lang/invoke/MethodHandles'java/lang/invoke/MethodHandles' (0x000000080011c780) [0.021s][info][class,init] 28 Initializing java/lang/invoke/MemberName'java/lang/invoke/MemberName' (0x00000008000cdbb8) [0.021s][info][class,init] 29 Initializing java/lang/invoke/MemberName$Factory'java/lang/invoke/MemberName$Factory' (0x0000000800021bb0) [0.021s][info][class,init] 30 Initializing java/security/Permission'java/security/Permission'(no method) (0x0000000800021758) [0.021s][info][class,init] 31 Initializing java/security/BasicPermission'java/security/BasicPermission'(no method) (0x0000000800024338) [0.021s][info][class,init] 32 Initializing java/lang/reflect/ReflectPermission'java/lang/reflect/ReflectPermission'(no method) (0x00000008000240e0) [0.021s][info][class,init] 33 Initializing java/lang/StringLatin1'java/lang/StringLatin1' (0x0000000800021548) [0.022s][info][class,init] 34 Initializing java/lang/invoke/MethodHandles$Lookup'java/lang/invoke/MethodHandles$Lookup' (0x00000008000d2af8) [0.022s][info][class,init] 35 Initializing java/util/Objects'java/util/Objects'(no method) (0x00000008000828e8) [0.022s][info][class,init] 36 Initializing jdk/internal/reflect/Reflection'jdk/internal/reflect/Reflection' (0x000000080000f688) [0.022s][info][class,init] 37 Initializing java/util/ImmutableCollections'java/util/ImmutableCollections' (0x0000000800084518) [0.022s][info][class,init] 38 Initializing java/util/List'java/util/List'(no method) (0x0000000800085330) [0.022s][info][class,init] 39 Initializing java/util/ImmutableCollections$AbstractImmutableList'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x0000000800083750) [0.022s][info][class,init] 40 Initializing java/util/ImmutableCollections$ListN'java/util/ImmutableCollections$ListN'(no method) (0x0000000800170ea0) [0.022s][info][class,init] 41 Initializing java/util/ImmutableCollections$SetN'java/util/ImmutableCollections$SetN'(no method) (0x0000000800170a88) [0.022s][info][class,init] 42 Initializing java/util/Map'java/util/Map'(no method) (0x00000008000174b0) [0.022s][info][class,init] 43 Initializing java/util/AbstractMap'java/util/AbstractMap'(no method) (0x0000000800052fb8) [0.022s][info][class,init] 44 Initializing java/util/ImmutableCollections$AbstractImmutableMap'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x00000008001706e0) [0.022s][info][class,init] 45 Initializing java/util/ImmutableCollections$MapN'java/util/ImmutableCollections$MapN'(no method) (0x0000000800172340) [0.022s][info][class,init] 46 Initializing java/lang/Math'java/lang/Math' (0x0000000800025dc8) [0.022s][info][class,init] 47 Initializing java/lang/Number'java/lang/Number'(no method) (0x000000080003cc38) [0.022s][info][class,init] 48 Initializing java/lang/Float'java/lang/Float' (0x0000000800044c98) [0.022s][info][class,init] 49 Initializing java/lang/Double'java/lang/Double' (0x0000000800046560) [0.022s][info][class,init] 50 Initializing java/util/HashMap'java/util/HashMap'(no method) (0x00000008000efe78) [0.022s][info][class,init] 51 Initializing java/lang/Integer'java/lang/Integer' (0x0000000800047a18) [0.022s][info][class,init] 52 Initializing java/util/AbstractSet'java/util/AbstractSet'(no method) (0x0000000800109688) [0.022s][info][class,init] 53 Initializing java/util/ImmutableCollections$MapN$1'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001c28d8) [0.022s][info][class,init] 54 Initializing java/util/Iterator'java/util/Iterator'(no method) (0x0000000800004680) [0.022s][info][class,init] 55 Initializing java/util/ImmutableCollections$MapN$MapNIterator'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000183c8) [0.022s][info][class,init] 56 Initializing java/util/KeyValueHolder'java/util/KeyValueHolder'(no method) (0x0000000800155370) [0.022s][info][class,init] 57 Initializing java/util/HashMap$Node'java/util/HashMap$Node'(no method) (0x0000000800154778) [0.023s][info][class,init] 58 Initializing java/util/concurrent/ConcurrentMap'java/util/concurrent/ConcurrentMap'(no method) (0x000000080016d3b0) [0.023s][info][class,init] 59 Initializing java/util/concurrent/ConcurrentHashMap'java/util/concurrent/ConcurrentHashMap' (0x000000080000def0) [0.023s][info][class,init] 60 Initializing java/lang/Runtime'java/lang/Runtime' (0x00000008001544c8) [0.023s][info][class,init] 61 Initializing java/io/ObjectStreamField'java/io/ObjectStreamField'(no method) (0x00000008000ea950) [0.023s][info][class,init] 62 Initializing jdk/internal/misc/Unsafe'jdk/internal/misc/Unsafe' (0x000000080000fcb8) [0.023s][info][class,init] 63 Initializing jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x00000008001308b8) [0.023s][info][class,init] 64 Initializing jdk/internal/reflect/ReflectionFactory'jdk/internal/reflect/ReflectionFactory' (0x00000008000556c0) [0.023s][info][class,init] 65 Initializing java/lang/ref/Reference'java/lang/ref/Reference' (0x000000080004e880) [0.023s][info][class,init] 66 Initializing java/lang/ref/Reference$ReferenceHandler'java/lang/ref/Reference$ReferenceHandler' (0x000000080004ff10) [0.023s][info][class,init] 67 Initializing java/lang/ref/PhantomReference'java/lang/ref/PhantomReference'(no method) (0x000000080004ead0) [0.023s][info][class,init] 68 Initializing jdk/internal/ref/Cleaner'jdk/internal/ref/Cleaner' (0x000000080004fcb0) [0.023s][info][class,init] 69 Initializing java/lang/ref/ReferenceQueue'java/lang/ref/ReferenceQueue' (0x0000000800055228) [0.023s][info][class,init] 70 Initializing java/lang/ref/ReferenceQueue$Null'java/lang/ref/ReferenceQueue$Null'(no method) (0x0000000800055470) [0.023s][info][class,init] 71 Initializing java/lang/ref/ReferenceQueue$Lock'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001d49d8) [0.023s][info][class,init] 72 Initializing java/lang/ref/Reference$1'java/lang/ref/Reference$1'(no method) (0x0000000800055af8) [0.023s][info][class,init] 73 Initializing java/lang/reflect/Executable'java/lang/reflect/Executable'(no method) (0x0000000800056718) [0.023s][info][class,init] 74 Initializing java/lang/reflect/Method'java/lang/reflect/Method'(no method) (0x00000008000573d0) [0.023s][info][class,init] 75 Initializing java/lang/ref/FinalReference'java/lang/ref/FinalReference'(no method) (0x0000000800050768) [0.023s][info][class,init] 76 Initializing java/lang/ref/Finalizer'java/lang/ref/Finalizer' (0x00000008000509b8) [0.023s][info][class,init] 77 Initializing java/lang/ref/Finalizer$FinalizerThread'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x00000008000d2f70) [0.024s][info][class,init] 78 Initializing java/lang/System$2'java/lang/System$2'(no method) (0x0000000800014f90) [0.024s][info][class,init] 79 Initializing jdk/internal/util/SystemProps'jdk/internal/util/SystemProps' (0x0000000800014d80) [0.024s][info][class,init] 80 Initializing jdk/internal/misc/VM'jdk/internal/misc/VM' (0x000000080000f898) [0.024s][info][class,init] 81 Initializing jdk/internal/util/SystemProps$Raw'jdk/internal/util/SystemProps$Raw'(no method) (0x0000000800094718) [0.024s][info][class,init] 82 Initializing java/lang/StringConcatHelper'java/lang/StringConcatHelper' (0x0000000800015740) [0.024s][info][class,init] 83 Initializing java/lang/Byte'java/lang/Byte' (0x000000080003d268) [0.024s][info][class,init] 84 Initializing java/lang/VersionProps'java/lang/VersionProps' (0x0000000800015530) [0.024s][info][class,init] 85 Initializing java/util/Arrays'java/util/Arrays' (0x0000000800025fd8) [0.025s][info][class,init] 86 Initializing java/lang/Character'java/lang/Character' (0x000000080003b0f0) [0.025s][info][class,init] 87 Initializing java/lang/CharacterData'java/lang/CharacterData'(no method) (0x0000000800041218) [0.025s][info][class,init] 88 Initializing java/lang/CharacterDataLatin1'java/lang/CharacterDataLatin1' (0x0000000800040ea0) [0.025s][info][class,init] 89 Initializing java/lang/Integer$IntegerCache'java/lang/Integer$IntegerCache' (0x000000080003ca28) [0.025s][info][class,init] 90 Initializing java/util/Dictionary'java/util/Dictionary'(no method) (0x0000000800015db8) [0.025s][info][class,init] 91 Initializing java/util/Hashtable'java/util/Hashtable'(no method) (0x0000000800016000) [0.025s][info][class,init] 92 Initializing java/util/Properties'java/util/Properties' (0x0000000800015950) [0.025s][info][class,init] 93 Initializing java/util/HashMap$EntrySet'java/util/HashMap$EntrySet'(no method) (0x00000008001d1a30) [0.025s][info][class,init] 94 Initializing java/util/HashMap$HashIterator'java/util/HashMap$HashIterator'(no method) (0x0000000800018af0) [0.025s][info][class,init] 95 Initializing java/util/HashMap$EntryIterator'java/util/HashMap$EntryIterator'(no method) (0x0000000800018d08) [0.025s][info][class,init] 96 Initializing java/util/concurrent/ConcurrentHashMap$Node'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001a2628) [0.025s][info][class,init] 97 Initializing jdk/internal/util/StaticProperty'jdk/internal/util/StaticProperty' (0x00000008000188e0) [0.025s][info][class,init] 98 Initializing java/io/InputStream'java/io/InputStream'(no method) (0x0000000800019218) [0.025s][info][class,init] 99 Initializing java/io/FileInputStream'java/io/FileInputStream' (0x0000000800018f58) [0.025s][info][class,init] 100 Initializing java/io/FileDescriptor'java/io/FileDescriptor' (0x0000000800019ca8) [0.025s][info][class,init] 101 Initializing java/io/FileDescriptor$1'java/io/FileDescriptor$1'(no method) (0x00000008001ddf68) [0.025s][info][class,init] 102 Initializing java/io/OutputStream'java/io/OutputStream'(no method) (0x0000000800013348) [0.025s][info][class,init] 103 Initializing java/io/FileOutputStream'java/io/FileOutputStream' (0x0000000800019ec0) [0.025s][info][class,init] 104 Initializing java/io/FilterInputStream'java/io/FilterInputStream'(no method) (0x000000080001a620) [0.025s][info][class,init] 105 Initializing java/io/BufferedInputStream'java/io/BufferedInputStream' (0x000000080001a360) [0.025s][info][class,init] 106 Initializing java/io/FilterOutputStream'java/io/FilterOutputStream'(no method) (0x00000008000135c8) [0.025s][info][class,init] 107 Initializing java/io/PrintStream'java/io/PrintStream'(no method) (0x0000000800012f90) [0.025s][info][class,init] 108 Initializing java/io/BufferedOutputStream'java/io/BufferedOutputStream'(no method) (0x00000008000176b8) [0.026s][info][class,init] 109 Initializing java/nio/charset/Charset'java/nio/charset/Charset' (0x00000008000944b0) [0.026s][info][class,init] 110 Initializing java/nio/charset/spi/CharsetProvider'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001d5290) [0.026s][info][class,init] 111 Initializing sun/nio/cs/StandardCharsets'sun/nio/cs/StandardCharsets' (0x00000008001d54b0) [0.026s][info][class,init] 112 Initializing java/lang/ThreadLocal'java/lang/ThreadLocal' (0x00000008000261e8) [0.026s][info][class,init] 113 Initializing java/util/concurrent/atomic/AtomicInteger'java/util/concurrent/atomic/AtomicInteger' (0x0000000800026438) [0.026s][info][class,init] 114 Initializing sun/nio/cs/Unicode'sun/nio/cs/Unicode'(no method) (0x0000000800094f30) [0.026s][info][class,init] 115 Initializing sun/nio/cs/UTF_8'sun/nio/cs/UTF_8' (0x00000008000951b8) [0.026s][info][class,init] 116 Initializing java/io/Writer'java/io/Writer'(no method) (0x00000008000e7ae0) [0.026s][info][class,init] 117 Initializing java/io/OutputStreamWriter'java/io/OutputStreamWriter'(no method) (0x00000008000e8660) [0.026s][info][class,init] 118 Initializing sun/nio/cs/StreamEncoder'sun/nio/cs/StreamEncoder' (0x00000008000e9490) [0.026s][info][class,init] 119 Initializing java/nio/charset/CharsetEncoder'java/nio/charset/CharsetEncoder' (0x00000008000e6e98) [0.026s][info][class,init] 120 Initializing sun/nio/cs/UTF_8$Encoder'sun/nio/cs/UTF_8$Encoder'(no method) (0x0000000800c403f0) [0.026s][info][class,init] 121 Initializing java/nio/charset/CodingErrorAction'java/nio/charset/CodingErrorAction' (0x00000008000a9278) [0.026s][info][class,init] 122 Initializing java/nio/Buffer'java/nio/Buffer' (0x00000008000767a8) [0.027s][info][class,init] 123 Initializing jdk/internal/misc/ScopedMemoryAccess'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000a83e0) [0.027s][info][class,init] 124 Initializing java/nio/Buffer$1'java/nio/Buffer$1'(no method) (0x00000008001b7460) [0.027s][info][class,init] 125 Initializing java/nio/ByteBuffer'java/nio/ByteBuffer' (0x000000080007c050) [0.027s][info][class,init] 126 Initializing java/nio/HeapByteBuffer'java/nio/HeapByteBuffer' (0x00000008001e5660) [0.027s][info][class,init] 127 Initializing java/nio/ByteOrder'java/nio/ByteOrder' (0x000000080001aeb0) [0.027s][info][class,init] 128 Initializing java/io/BufferedWriter'java/io/BufferedWriter' (0x000000080001b0c8) [0.027s][info][class,init] 129 Initializing java/lang/Terminator'java/lang/Terminator' (0x000000080001aca0) [0.027s][info][class,init] 130 Initializing java/lang/Terminator$1'java/lang/Terminator$1'(no method) (0x0000000800087e58) [0.027s][info][class,init] 131 Initializing jdk/internal/misc/Signal'jdk/internal/misc/Signal' (0x0000000800087c40) [0.027s][info][class,init] 132 Initializing java/util/Hashtable$Entry'java/util/Hashtable$Entry'(no method) (0x000000080016e1d8) [0.027s][info][class,init] 133 Initializing jdk/internal/misc/Signal$Handler'jdk/internal/misc/Signal$Handler' (0x0000000800088088) [0.027s][info][class,init] 134 Initializing jdk/internal/misc/Signal$NativeHandler'jdk/internal/misc/Signal$NativeHandler'(no method) (0x00000008001eb878) [0.027s][info][class,init] 135 Initializing jdk/internal/misc/OSEnvironment'jdk/internal/misc/OSEnvironment'(no method) (0x00000008000353a0) [0.027s][info][class,init] 136 Initializing java/lang/Throwable'java/lang/Throwable' (0x00000008000310c0) [0.027s][info][class,init] 137 Initializing java/util/Collections'java/util/Collections' (0x0000000800035190) [0.027s][info][class,init] 138 Initializing java/util/Collections$EmptySet'java/util/Collections$EmptySet'(no method) (0x0000000800109a98) [0.027s][info][class,init] 139 Initializing java/util/AbstractList'java/util/AbstractList'(no method) (0x0000000800085538) [0.027s][info][class,init] 140 Initializing java/util/Collections$EmptyList'java/util/Collections$EmptyList'(no method) (0x00000008001acf38) [0.027s][info][class,init] 141 Initializing java/util/Collections$EmptyMap'java/util/Collections$EmptyMap'(no method) (0x0000000800053758) [0.027s][info][class,init] 142 Initializing java/lang/Error'java/lang/Error'(no method) (0x0000000800032b90) [0.027s][info][class,init] 143 Initializing java/lang/VirtualMachineError'java/lang/VirtualMachineError'(no method) (0x0000000800032df8) [0.027s][info][class,init] 144 Initializing java/lang/OutOfMemoryError'java/lang/OutOfMemoryError'(no method) (0x0000000800090428) [0.027s][info][class,init] 145 Initializing java/lang/Exception'java/lang/Exception'(no method) (0x0000000800031328) [0.027s][info][class,init] 146 Initializing java/lang/RuntimeException'java/lang/RuntimeException'(no method) (0x0000000800032470) [0.027s][info][class,init] 147 Initializing java/lang/NullPointerException'java/lang/NullPointerException'(no method) (0x000000080008ffc0) [0.027s][info][class,init] 148 Initializing java/lang/ClassCastException'java/lang/ClassCastException'(no method) (0x0000000800090c18) [0.027s][info][class,init] 149 Initializing java/lang/ArrayStoreException'java/lang/ArrayStoreException'(no method) (0x0000000800033530) [0.027s][info][class,init] 150 Initializing java/lang/ArithmeticException'java/lang/ArithmeticException'(no method) (0x000000080008fd58) [0.027s][info][class,init] 151 Initializing java/lang/StackOverflowError'java/lang/StackOverflowError'(no method) (0x0000000800033060) [0.027s][info][class,init] 152 Initializing java/lang/IllegalMonitorStateException'java/lang/IllegalMonitorStateException'(no method) (0x0000000800052390) [0.027s][info][class,init] 153 Initializing java/lang/IllegalArgumentException'java/lang/IllegalArgumentException'(no method) (0x00000008000326d8) [0.028s][info][class,init] 154 Initializing java/lang/invoke/MethodHandle'java/lang/invoke/MethodHandle' (0x00000008000b93d0) [0.028s][info][class,init] 155 Initializing java/lang/invoke/MethodHandleStatics'java/lang/invoke/MethodHandleStatics' (0x000000080001d020) [0.028s][info][class,init] 156 Initializing sun/security/action/GetPropertyAction'sun/security/action/GetPropertyAction'(no method) (0x00000008000e78a0) [0.028s][info][class,init] 157 Initializing java/lang/Boolean'java/lang/Boolean' (0x00000008000363d8) [0.028s][info][class,init] 158 Initializing java/lang/invoke/ResolvedMethodName'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000d13b0) [0.028s][info][class,init] 159 Initializing java/lang/invoke/MethodHandleNatives'java/lang/invoke/MethodHandleNatives' (0x00000008000d1698) [0.028s][info][class,init] 160 Initializing jdk/internal/module/ModuleBootstrap'jdk/internal/module/ModuleBootstrap' (0x000000080001ce10) [0.029s][info][class,init] 161 Initializing sun/invoke/util/VerifyAccess'sun/invoke/util/VerifyAccess' (0x0000000800073250) [0.029s][info][class,init] 162 Initializing java/lang/reflect/Modifier'java/lang/reflect/Modifier'(no method) (0x0000000800073040) [0.029s][info][class,init] 163 Initializing java/lang/module/ModuleDescriptor'java/lang/module/ModuleDescriptor' (0x0000000800124e20) [0.029s][info][class,init] 164 Initializing java/lang/module/ModuleDescriptor$1'java/lang/module/ModuleDescriptor$1'(no method) (0x0000000800072b58) [0.029s][info][class,init] 165 Initializing java/io/File'java/io/File' (0x00000008000727b8) [0.029s][info][class,init] 166 Initializing java/io/DefaultFileSystem'java/io/DefaultFileSystem'(no method) (0x00000008000a4818) [0.029s][info][class,init] 167 Initializing java/io/FileSystem'java/io/FileSystem' (0x00000008000a2b00) [0.029s][info][class,init] 168 Initializing java/io/UnixFileSystem'java/io/UnixFileSystem' (0x00000008000a2df0) [0.029s][info][class,init] 169 Initializing java/lang/AbstractStringBuilder'java/lang/AbstractStringBuilder' (0x0000000800065f28) [0.029s][info][class,init] 170 Initializing java/lang/StringBuilder'java/lang/StringBuilder'(no method) (0x000000080000efc8) [0.029s][info][class,init] 171 Initializing jdk/internal/util/ArraysSupport'jdk/internal/util/ArraysSupport' (0x00000008000a28f0) [0.029s][info][class,init] 172 Initializing jdk/internal/module/ModulePatcher'jdk/internal/module/ModulePatcher' (0x000000080017b118) [0.029s][info][class,init] 173 Initializing jdk/internal/module/ModuleBootstrap$Counters'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800179690) [0.029s][info][class,init] 174 Initializing jdk/internal/module/ArchivedBootLayer'jdk/internal/module/ArchivedBootLayer' (0x0000000800179470) [0.029s][info][class,init] 175 Initializing java/lang/ModuleLayer'java/lang/ModuleLayer' (0x000000080015d020) [0.029s][info][class,init] 176 Initializing java/lang/module/Configuration'java/lang/module/Configuration' (0x0000000800175a90) [0.029s][info][class,init] 177 Initializing jdk/internal/loader/AbstractClassLoaderValue'jdk/internal/loader/AbstractClassLoaderValue' (0x0000000800176138) [0.029s][info][class,init] 178 Initializing jdk/internal/loader/ClassLoaderValue'jdk/internal/loader/ClassLoaderValue'(no method) (0x0000000800176388) [0.029s][info][class,init] 179 Initializing java/util/ImmutableCollections$List12'java/util/ImmutableCollections$List12'(no method) (0x0000000800083c28) [0.029s][info][class,init] 180 Initializing java/lang/module/ResolvedModule'java/lang/module/ResolvedModule'(no method) (0x0000000800178410) [0.029s][info][class,init] 181 Initializing java/lang/module/ModuleReference'java/lang/module/ModuleReference'(no method) (0x00000008000c26a0) [0.029s][info][class,init] 182 Initializing jdk/internal/module/ModuleReferenceImpl'jdk/internal/module/ModuleReferenceImpl'(no method) (0x0000000800173380) [0.030s][info][class,init] 183 Initializing java/lang/module/ModuleDescriptor$Version'java/lang/module/ModuleDescriptor$Version'(no method) (0x0000000800174260) [0.030s][info][class,init] 184 Initializing java/util/ArrayList'java/util/ArrayList' (0x000000080000d9c0) [0.030s][info][class,init] 185 Initializing java/lang/module/ModuleDescriptor$Requires'java/lang/module/ModuleDescriptor$Requires' (0x000000080015fd68) [0.030s][info][class,init] 186 Initializing java/lang/Enum'java/lang/Enum'(no method) (0x0000000800007540) [0.030s][info][class,init] 187 Initializing java/lang/module/ModuleDescriptor$Requires$Modifier'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x000000080008b318) [0.030s][info][class,init] 188 Initializing java/lang/module/ModuleDescriptor$Provides'java/lang/module/ModuleDescriptor$Provides'(no method) (0x0000000800174490) [0.030s][info][class,init] 189 Initializing java/net/URI'java/net/URI' (0x0000000800178df0) [0.030s][info][class,init] 190 Initializing java/net/URI$1'java/net/URI$1'(no method) (0x00000008002076e8) [0.030s][info][class,init] 191 Initializing jdk/internal/module/SystemModuleFinders$2'jdk/internal/module/SystemModuleFinders$2'(no method) (0x0000000800173140) [0.030s][info][class,init] 192 Initializing jdk/internal/module/SystemModuleFinders$3'jdk/internal/module/SystemModuleFinders$3'(no method) (0x000000080017b330) [0.030s][info][class,init] 193 Initializing java/lang/module/ModuleDescriptor$Exports'java/lang/module/ModuleDescriptor$Exports'(no method) (0x000000080015fb38) [0.030s][info][class,init] 194 Initializing jdk/internal/module/ModuleTarget'jdk/internal/module/ModuleTarget'(no method) (0x0000000800201e38) [0.030s][info][class,init] 195 Initializing jdk/internal/module/ModuleHashes'jdk/internal/module/ModuleHashes'(no method) (0x000000080017acf8) [0.030s][info][class,init] 196 Initializing java/util/Collections$UnmodifiableMap'java/util/Collections$UnmodifiableMap'(no method) (0x00000008001f1118) [0.030s][info][class,init] 197 Initializing java/lang/module/ModuleDescriptor$Opens'java/lang/module/ModuleDescriptor$Opens'(no method) (0x000000080015f908) [0.030s][info][class,init] 198 Initializing java/util/HashSet'java/util/HashSet' (0x0000000800109270) [0.030s][info][class,init] 199 Initializing java/lang/ClassLoader'java/lang/ClassLoader' (0x0000000800008b08) [0.030s][info][class,init] 200 Initializing java/security/SecureClassLoader'java/security/SecureClassLoader' (0x00000008000090f8) [0.030s][info][class,init] 201 Initializing java/lang/ClassLoader$ParallelLoaders'java/lang/ClassLoader$ParallelLoaders' (0x000000080000edb8) [0.030s][info][class,init] 202 Initializing java/util/WeakHashMap'java/util/WeakHashMap' (0x0000000800052bf0) [0.030s][info][class,init] 203 Initializing java/util/Collections$SetFromMap'java/util/Collections$SetFromMap'(no method) (0x00000008001f7808) [0.030s][info][class,init] 204 Initializing java/util/WeakHashMap$KeySet'java/util/WeakHashMap$KeySet'(no method) (0x00000008001626b0) [0.030s][info][class,init] 205 Initializing java/lang/ref/WeakReference'java/lang/ref/WeakReference'(no method) (0x0000000800050d80) [0.030s][info][class,init] 206 Initializing java/util/WeakHashMap$Entry'java/util/WeakHashMap$Entry'(no method) (0x0000000800052948) [0.030s][info][class,init] 207 Initializing jdk/internal/loader/BuiltinClassLoader'jdk/internal/loader/BuiltinClassLoader' (0x00000008000093f8) [0.030s][info][class,init] 208 Initializing jdk/internal/loader/ArchivedClassLoaders'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001a1958) [0.030s][info][class,init] 209 Initializing jdk/internal/loader/ClassLoaders$BootClassLoader'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001a2150) [0.030s][info][class,init] 210 Initializing java/security/ProtectionDomain'java/security/ProtectionDomain' (0x000000080000e748) [0.030s][info][class,init] 211 Initializing java/security/ProtectionDomain$JavaSecurityAccessImpl'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x0000000800162248) [0.030s][info][class,init] 212 Initializing java/security/CodeSource'java/security/CodeSource'(no method) (0x000000080000e970) [0.030s][info][class,init] 213 Initializing java/security/Principal'java/security/Principal'(no method) (0x0000000800162db8) [0.030s][info][class,init] 214 Initializing java/security/ProtectionDomain$Key'java/security/ProtectionDomain$Key'(no method) (0x0000000800162038) [0.030s][info][class,init] 215 Initializing jdk/internal/loader/NativeLibraries'jdk/internal/loader/NativeLibraries' (0x000000080000eba0) [0.030s][info][class,init] 216 Initializing java/util/ArrayDeque'java/util/ArrayDeque'(no method) (0x00000008001518f0) [0.030s][info][class,init] 217 Initializing jdk/internal/module/ServicesCatalog'jdk/internal/module/ServicesCatalog' (0x0000000800127108) [0.031s][info][class,init] 218 Initializing java/util/concurrent/CopyOnWriteArrayList'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x000000080020c928) [0.031s][info][class,init] 219 Initializing jdk/internal/module/ServicesCatalog$ServiceProvider'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x000000080020ce40) [0.031s][info][class,init] 220 Initializing jdk/internal/loader/ClassLoaders$PlatformClassLoader'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x000000080008f768) [0.031s][info][class,init] 221 Initializing jdk/internal/loader/BuiltinClassLoader$LoadedModule'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x0000000800175f00) [0.031s][info][class,init] 222 Initializing jdk/internal/loader/ClassLoaders$AppClassLoader'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x000000080008d498) [0.031s][info][class,init] 223 Initializing jdk/internal/loader/BootLoader'jdk/internal/loader/BootLoader' (0x00000008001267b0) [0.031s][info][class,init] 224 Initializing jdk/internal/loader/ClassLoaders'jdk/internal/loader/ClassLoaders' (0x000000080000faa8) [0.031s][info][class,init] 225 Initializing jdk/internal/loader/URLClassPath'jdk/internal/loader/URLClassPath' (0x000000080019a988) [0.031s][info][class,init] 226 Initializing java/net/URL'java/net/URL' (0x000000080006e8e0) [0.031s][info][class,init] 227 Initializing java/net/URL$DefaultFactory'java/net/URL$DefaultFactory' (0x000000080008abf0) [0.031s][info][class,init] 228 Initializing java/net/URL$3'java/net/URL$3'(no method) (0x000000080008a7b8) [0.031s][info][class,init] 229 Initializing java/io/File$PathStatus'java/io/File$PathStatus' (0x000000080008b0c8) [0.031s][info][class,init] 230 Initializing sun/net/www/ParseUtil'sun/net/www/ParseUtil' (0x000000080008a5a8) [0.031s][info][class,init] 231 Initializing java/util/HexFormat'java/util/HexFormat' (0x000000080008c9e8) [0.031s][info][class,init] 232 Initializing java/net/URLStreamHandler'java/net/URLStreamHandler'(no method) (0x0000000800197d98) [0.031s][info][class,init] 233 Initializing sun/net/www/protocol/file/Handler'sun/net/www/protocol/file/Handler'(no method) (0x0000000800198480) [0.031s][info][class,init] 234 Initializing sun/net/util/IPAddressUtil'sun/net/util/IPAddressUtil' (0x00000008000872f8) [0.032s][info][class,init] 235 Initializing jdk/internal/util/Preconditions'jdk/internal/util/Preconditions'(no method) (0x00000008000870e8) [0.032s][info][class,init] 236 Initializing java/lang/invoke/StringConcatFactory'java/lang/invoke/StringConcatFactory' (0x000000080001d230) [0.032s][info][class,init] 237 Initializing java/util/function/Function'java/util/function/Function'(no method) (0x00000008001034f8) [0.032s][info][class,init] 238 Initializing java/lang/invoke/StringConcatFactory$1'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800210430) [0.032s][info][class,init] 239 Initializing java/lang/invoke/StringConcatFactory$2'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800210978) [0.032s][info][class,init] 240 Initializing java/lang/invoke/StringConcatFactory$3'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800040450) [0.032s][info][class,init] 241 Initializing java/nio/CharBuffer'java/nio/CharBuffer' (0x00000008000798f8) [0.032s][info][class,init] 242 Initializing java/nio/HeapCharBuffer'java/nio/HeapCharBuffer' (0x0000000800079f80) [0.032s][info][class,init] 243 Initializing java/nio/charset/CoderResult'java/nio/charset/CoderResult' (0x00000008000a8bd0) openjdk version "18-internal" 2022-03-15 OpenJDK Runtime Environment (build 18-internal+0-adhoc.qingfengyy.jdktip) OpenJDK 64-Bit Server VM (build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing) [0.033s][info][class,init] 244 Initializing java/lang/Shutdown'java/lang/Shutdown' (0x000000080004c3a0) [0.033s][info][class,init] 245 Initializing java/lang/Shutdown$Lock'java/lang/Shutdown$Lock'(no method) (0x0000000800024a40) It looks this patch will not affect the initialization order. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From xuelei at openjdk.java.net Tue Jul 6 00:17:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 6 Jul 2021 00:17:50 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote: > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed Could I have more details about the problem? For example, the thread stacks for the socket reset or the thread stacks of the call to close() method. The test case does not call close() method of the socket or the I/O stream. Will the reset happen if the socket and I/O call the close() methods properly? ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From abakhtin at openjdk.java.net Tue Jul 6 11:13:48 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 6 Jul 2021 11:13:48 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote: > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed Hi Xuelei, Thank you for your interest in this issue. In this particular test case, a simple socket connects to the SSL server with a dummy message and waiting for the server's response. SSL server fails to verify the message header and aborts the connection. The stack trace to socket close on the server side is: java.lang.Throwable at java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1785) at java.base/sun.security.ssl.SSLSocketImpl.shutdown(SSLSocketImpl.java:1756) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:431) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:145) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1500) 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 java.base/java.io.DataInputStream.readUnsignedShort(DataInputStream.java:343) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:595) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:570) at SSLSocketReset$ServerThread.run(SSLSocketReset.java:97) On the client side application waiting for response from the server but fails due to socket close by the server. Current JDK code causes the client fails with: java.net.SocketException: Connection reset at java.base/java.net.SocketInputStream.read(SocketInputStream.java:183) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:137) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) at java.base/java.io.DataInputStream.readFully(DataInputStream.java:201) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:614) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:570) at SSLSocketReset.main(SSLSocketReset.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) In case of proposed patch applied, the client fails with java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:203) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:614) at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:570) at SSLSocketReset.main(SSLSocketReset.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) SSL server closes the socket during the handshake, so no changes if we try to close the socket from the application ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From weijun at openjdk.java.net Tue Jul 6 15:44:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 6 Jul 2021 15:44:49 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: References: Message-ID: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> On Fri, 2 Jul 2021 23:30:17 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > merge AESGCMByteArray with existing AESGCMBench test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 46: > 44: private int keyLength; > 45: > 46: @Param({"" + 1024, "" + 1500, "" + 4096, "" + 16384}) Now that you don't calculate anymore, how about just string literals like `"1024"` etc? test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 58: > 56: SecretKeySpec ks; > 57: GCMParameterSpec gcm_spec; > 58: byte[] aad; Not an expert on this, but why no more AAD? test/micro/org/openjdk/bench/javax/crypto/full/AESGCMByteBuffer.java line 44: > 42: * benchmark operation > 43: */ > 44: Do you want to create a "small" version? ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From xuelei at openjdk.java.net Tue Jul 6 16:08:51 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 6 Jul 2021 16:08:51 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote: > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed Hi Alexey, Thank you for the details thread stacks. The basic idea of the fix looks good to me. But I did have a concern about the racing. If there is a read thread and a close/shutdown thread, there might be weird behaviors because each thread may only be able to read some of the information and make it impossible to decode the record. What do you think If placing the cleanup synchronized with readLock? For example, using the AppInputStream.deplete() method or a similar one that synch the reading. Best, Xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From ascarpino at openjdk.java.net Tue Jul 6 18:35:54 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Jul 2021 18:35:54 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> References: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> Message-ID: On Tue, 6 Jul 2021 15:41:27 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> merge AESGCMByteArray with existing AESGCMBench > > test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 58: > >> 56: SecretKeySpec ks; >> 57: GCMParameterSpec gcm_spec; >> 58: byte[] aad; > > Not an expert on this, but why no more AAD? For a performance test there isn't any value in adding an AAD. It's data sitting in a buffer that an be easily replicated with a multipart operation ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Tue Jul 6 18:47:53 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Jul 2021 18:47:53 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> References: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> Message-ID: On Tue, 6 Jul 2021 15:38:20 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> merge AESGCMByteArray with existing AESGCMBench > > test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java line 46: > >> 44: private int keyLength; >> 45: >> 46: @Param({"" + 1024, "" + 1500, "" + 4096, "" + 16384}) > > Now that you don't calculate anymore, how about just string literals like `"1024"` etc? Funny.. I didn't even notice that ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Tue Jul 6 19:10:50 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Jul 2021 19:10:50 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> References: <1bGxc2_IRj3cEoEDk5-pc4SfFXJLxdp7nBsuUtDPdbU=.afdec6be-6aaa-4f44-b749-62a8abcf3a92@github.com> Message-ID: On Tue, 6 Jul 2021 15:40:09 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> merge AESGCMByteArray with existing AESGCMBench > > test/micro/org/openjdk/bench/javax/crypto/full/AESGCMByteBuffer.java line 44: > >> 42: * benchmark operation >> 43: */ >> 44: > > Do you want to create a "small" version? I debated it.. I'm still not sure, but I guess I could. ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From mchung at openjdk.java.net Tue Jul 6 19:20:54 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 6 Jul 2021 19:20:54 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes wrote: >> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks. > > @kelthuzadx I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not. > > Cheers, > David > @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks. Alan and Paul are currently on vacation. I'm reviewing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From mchung at openjdk.java.net Tue Jul 6 19:20:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 6 Jul 2021 19:20:53 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > tests rely on IOOBE exception message I suggest to separate the client changes (both src and test) in a separate PR for the client review. I review the rest of the files, which looks okay to me. I will take another pass carefully. src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project. test/jdk/java/lang/StringBuffer/Exceptions.java line 73: > 71: new StringBuffer(); > 72: } > 73: }); Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting. test/jdk/java/lang/StringBuilder/Exceptions.java line 73: > 71: new StringBuilder(); > 72: } > 73: }); Nit: it'd be good to make the formatting of all calls to tryCatch method consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From ecaspole at openjdk.java.net Tue Jul 6 19:39:53 2021 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Tue, 6 Jul 2021 19:39:53 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 23:30:17 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > merge AESGCMByteArray with existing AESGCMBench >From the JMH point of view, looks good to me. >From the JMH point of view, looks good to me. ------------- Marked as reviewed by ecaspole (Committer). PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Tue Jul 6 23:06:39 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Jul 2021 23:06:39 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v3] In-Reply-To: References: Message-ID: > Hi, > > I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: Add small.AESGCMByteBuffer and fix dataSize ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4672/files - new: https://git.openjdk.java.net/jdk/pull/4672/files/0c7113ef..2a7d1df6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=01-02 Stats: 37 lines in 2 files changed: 36 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4672/head:pull/4672 PR: https://git.openjdk.java.net/jdk/pull/4672 From yyang at openjdk.java.net Wed Jul 7 02:18:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Jul 2021 02:18:13 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8] In-Reply-To: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> Message-ID: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com> On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> tests rely on IOOBE exception message > > test/jdk/java/lang/StringBuffer/Exceptions.java line 73: > >> 71: new StringBuffer(); >> 72: } >> 73: }); > > Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting. Hi Mandy, thanks for reviewing this. > I suggest to separate the client changes (both src and test) in a separate PR for the client review. Does "client changes" means changes involving src/java.desktop and test/java/awt? > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project. Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo.. > Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting. Restored. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Wed Jul 7 02:18:12 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Jul 2021 02:18:12 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v9] In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Yi Yang has updated the pull request incrementally with four additional commits since the last revision: - restore code format - restore code format - restore code format - restore code format ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4507/files - new: https://git.openjdk.java.net/jdk/pull/4507/files/ab1b509d..f43ffc3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=07-08 Stats: 58 lines in 2 files changed: 0 ins; 10 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Wed Jul 7 02:23:19 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Jul 2021 02:23:19 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v10] In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - restore code format - restore code format ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4507/files - new: https://git.openjdk.java.net/jdk/pull/4507/files/f43ffc3a..903f0305 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=08-09 Stats: 36 lines in 2 files changed: 0 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507 From abakhtin at openjdk.java.net Wed Jul 7 10:15:19 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 7 Jul 2021 10:15:19 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v2] In-Reply-To: References: Message-ID: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Add read lock for inputRecord.deplete ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4520/files - new: https://git.openjdk.java.net/jdk/pull/4520/files/cebf52aa..198d0d96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4520&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4520&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4520/head:pull/4520 PR: https://git.openjdk.java.net/jdk/pull/4520 From abakhtin at openjdk.java.net Wed Jul 7 10:22:54 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 7 Jul 2021 10:22:54 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v2] In-Reply-To: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> References: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> Message-ID: On Wed, 7 Jul 2021 10:15:19 GMT, Alexey Bakhtin wrote: >> Please review the fix for JDK-8268965. >> >> The new jtreg test is added for the described issue. >> sun/security/ssl and javax/net/ssl tests are passed > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Add read lock for inputRecord.deplete Hi Xuelei, Thank you for review. You are right. It is better to add readLock to exclude concurrent reading. Unfortunately I can not use appInput.deplete() here because of input stream already marked as closed (called from TransportContext.fatal(TransportContext.java:376)). So, I've added appInput.readLock around deplete() ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From fguallini at openjdk.java.net Wed Jul 7 15:30:11 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 7 Jul 2021 15:30:11 GMT Subject: RFR: 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support Message-ID: test/jdk/javax/net/ssl/compatibility/JdkInfo is a helper class for the compatibility tests. It is verifying whether a protocol or cipher suite is supported/enabled by setting all the allowed values as a string, and then invoking String contains() to return whether a specific version is supported. This approach is problematic when, for instance, supportedProtocols is equal to 'TLSv1.3,TLSv1.2', then supportedProtocols.contains("TLSv1") will return true, given that 'TLSv1' is effectively a substring of 'TLSv1.3'. Proposed fix: Set the supported/enabled protocols and ciphers as elements in lists, and use List contains() to find matches ------------- Commit messages: - refactored JdkInfo Changes: https://git.openjdk.java.net/jdk/pull/4710/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4710&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269933 Stats: 27 lines in 1 file changed: 15 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4710.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4710/head:pull/4710 PR: https://git.openjdk.java.net/jdk/pull/4710 From mchung at openjdk.java.net Wed Jul 7 16:25:49 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 7 Jul 2021 16:25:49 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8] In-Reply-To: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com> Message-ID: On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang wrote: > Does "client changes" means changes involving src/java.desktop and test/java/awt? src/java.desktop, test/java/awt, and test/javax/imageio ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From mchung at openjdk.java.net Wed Jul 7 17:10:56 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 7 Jul 2021 17:10:56 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com> Message-ID: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com> On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung wrote: >> Hi Mandy, thanks for reviewing this. >> >>> I suggest to separate the client changes (both src and test) in a separate PR for the client review. >> >> Does "client changes" means changes involving src/java.desktop and test/java/awt? >> >>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project. >> >> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo.. >> >>> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting. >> >> Restored. > >> Does "client changes" means changes involving src/java.desktop and test/java/awt? > > src/java.desktop, test/java/awt, and test/javax/imageio > > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project. > > Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo.. What I meant is to file a JBS issue for this change and revert the change in this patch. That can be fixed when the next JSR 166 changes are imported to JDK. I wasn't sure if this is the right repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/ ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From xuelei at openjdk.java.net Wed Jul 7 17:24:51 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 7 Jul 2021 17:24:51 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v2] In-Reply-To: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> References: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> Message-ID: On Wed, 7 Jul 2021 10:15:19 GMT, Alexey Bakhtin wrote: >> Please review the fix for JDK-8268965. >> >> The new jtreg test is added for the described issue. >> sun/security/ssl and javax/net/ssl tests are passed > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Add read lock for inputRecord.deplete src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1789: > 1787: appInput.readLock.unlock(); > 1788: } > 1789: } The blocking on close() may be not good in practice. I would use tryLock() rather than lock() so as to avoid closure blocking. tryLock() is not perfect, but it may be better than blocking the close(). BTW, you could use the intanceof pattern matching so as to avoid the cast (See https://openjdk.java.net/jeps/394). if (conContext.inputRecord instanceof SSLSocketInputRecord inputRecord && isConnected) { if (appInput.readLock.tryLock()) { try { inputRecord.deplete(false); } finally { appInput.readLock.unlock(); } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From xuelei at openjdk.java.net Wed Jul 7 17:32:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 7 Jul 2021 17:32:50 GMT Subject: RFR: 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 15:23:09 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/compatibility/JdkInfo is a helper class for the compatibility tests. It is verifying whether a protocol or cipher suite is supported/enabled by setting all the allowed values as a string, and then invoking String contains() to return whether a specific version is supported. This approach is problematic when, for instance, supportedProtocols is equal to 'TLSv1.3,TLSv1.2', then supportedProtocols.contains("TLSv1") will return true, given that 'TLSv1' is effectively a substring of 'TLSv1.3'. > > Proposed fix: Set the supported/enabled protocols and ciphers as elements in lists, and use List contains() to find matches Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4710 From rhalade at openjdk.java.net Wed Jul 7 19:41:50 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 7 Jul 2021 19:41:50 GMT Subject: RFR: 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 15:23:09 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/compatibility/JdkInfo is a helper class for the compatibility tests. It is verifying whether a protocol or cipher suite is supported/enabled by setting all the allowed values as a string, and then invoking String contains() to return whether a specific version is supported. This approach is problematic when, for instance, supportedProtocols is equal to 'TLSv1.3,TLSv1.2', then supportedProtocols.contains("TLSv1") will return true, given that 'TLSv1' is effectively a substring of 'TLSv1.3'. > > Proposed fix: Set the supported/enabled protocols and ciphers as elements in lists, and use List contains() to find matches Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4710 From abakhtin at openjdk.java.net Wed Jul 7 20:44:25 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 7 Jul 2021 20:44:25 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v3] In-Reply-To: References: Message-ID: > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Use tryLock ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4520/files - new: https://git.openjdk.java.net/jdk/pull/4520/files/198d0d96..dc51d9ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4520&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4520&range=01-02 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4520/head:pull/4520 PR: https://git.openjdk.java.net/jdk/pull/4520 From abakhtin at openjdk.java.net Wed Jul 7 20:44:28 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 7 Jul 2021 20:44:28 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v2] In-Reply-To: References: <7bdHqLPGrHRchT8YBv8DOBhb3Rb9RLv-KVaoinALSlg=.e543112e-3d7c-4a9d-8d5f-83cb670947c4@github.com> Message-ID: On Wed, 7 Jul 2021 17:22:07 GMT, Xue-Lei Andrew Fan wrote: >> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: >> >> Add read lock for inputRecord.deplete > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1789: > >> 1787: appInput.readLock.unlock(); >> 1788: } >> 1789: } > > The blocking on close() may be not good in practice. I would use tryLock() rather than lock() so as to avoid closure blocking. tryLock() is not perfect, but it may be better than blocking the close(). > > BTW, you could use the intanceof pattern matching so as to avoid the cast (See https://openjdk.java.net/jeps/394). > > > if (conContext.inputRecord instanceof > SSLSocketInputRecord inputRecord && isConnected) { > if (appInput.readLock.tryLock()) { > try { > inputRecord.deplete(false); > } finally { > appInput.readLock.unlock(); > } > } > } Hi Xuelei, Thank you a lot again. Replaced lock with tryLock as you suggested ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From yyang at openjdk.java.net Thu Jul 8 03:12:26 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Jul 2021 03:12:26 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v8] In-Reply-To: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com> <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com> <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com> Message-ID: On Wed, 7 Jul 2021 17:08:19 GMT, Mandy Chung wrote: >>> Does "client changes" means changes involving src/java.desktop and test/java/awt? >> >> src/java.desktop, test/java/awt, and test/javax/imageio > >> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project. >> >> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo.. > > What I meant is to file a JBS issue for this change and revert the change in this patch. That can be fixed when the next JSR 166 changes are imported to JDK. > > I wasn't sure if this is the right repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/ Okay. I've filed https://bugs.openjdk.java.net/browse/JDK-8270057 and https://bugs.openjdk.java.net/browse/JDK-8270058 for JSR 166 and client code respectively. These codes have been restored. (Sorry for force-pushing, my mistake..) ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Thu Jul 8 03:12:24 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Jul 2021 03:12:24 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Yi Yang 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: restore JSR166; restore java.desktop ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4507/files - new: https://git.openjdk.java.net/jdk/pull/4507/files/903f0305..a9e7dbc8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=09-10 Stats: 49 lines in 7 files changed: 24 ins; 7 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507 From weijun at openjdk.java.net Thu Jul 8 14:46:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Jul 2021 14:46:55 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 23:06:39 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > Add small.AESGCMByteBuffer and fix dataSize Marked as reviewed by weijun (Reviewer). test/micro/org/openjdk/bench/javax/crypto/full/AESGCMByteBuffer.java line 50: > 48: private int keyLength; > 49: > 50: @Param({"" + 1024, "" + 1500, "" + 4096, "" + 16384}) You can update the line above as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Thu Jul 8 15:07:38 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 8 Jul 2021 15:07:38 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v4] In-Reply-To: References: Message-ID: > Hi, > > I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: full.AESGCMByteBuffer dataSize ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4672/files - new: https://git.openjdk.java.net/jdk/pull/4672/files/2a7d1df6..4d43cff6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4672&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4672/head:pull/4672 PR: https://git.openjdk.java.net/jdk/pull/4672 From ascarpino at openjdk.java.net Thu Jul 8 15:07:41 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 8 Jul 2021 15:07:41 GMT Subject: RFR: 8269827: JMH tests for AES/GCM byte[] and bytebuffers [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 14:39:20 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Add small.AESGCMByteBuffer and fix dataSize > > test/micro/org/openjdk/bench/javax/crypto/full/AESGCMByteBuffer.java line 50: > >> 48: private int keyLength; >> 49: >> 50: @Param({"" + 1024, "" + 1500, "" + 4096, "" + 16384}) > > You can update the line above as well. Grr.. I'm not sure how I missed that one ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From xuelei at openjdk.java.net Thu Jul 8 16:18:51 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 8 Jul 2021 16:18:51 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server [v3] In-Reply-To: References: Message-ID: <6mPomLTifEND_T4HiuklxYfjzlNLV5a9_Edz7NqrfQs=.09a5abbd-be00-457b-a9e4-a714fa8f1ec8@github.com> On Wed, 7 Jul 2021 20:44:25 GMT, Alexey Bakhtin wrote: >> Please review the fix for JDK-8268965. >> >> The new jtreg test is added for the described issue. >> sun/security/ssl and javax/net/ssl tests are passed > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Use tryLock Looks good to me. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4520 From abakhtin at openjdk.java.net Thu Jul 8 16:48:01 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 8 Jul 2021 16:48:01 GMT Subject: Integrated: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: <0UNrwyZSr_f4A1sHq-MKsm5ehscpFRvY1m4eOIQb9do=.26740ff1-6f82-48a4-92e5-c33fa671ab6d@github.com> On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote: > Please review the fix for JDK-8268965. > > The new jtreg test is added for the described issue. > sun/security/ssl and javax/net/ssl tests are passed This pull request has now been integrated. Changeset: 6f171b9f Author: Alexey Bakhtin Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/6f171b9f0d28ad17b31a54bad894f38d19df6f73 Stats: 120 lines in 2 files changed: 120 ins; 0 del; 0 mod 8268965: TCP Connection Reset when connecting simple socket to SSL server Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4520 From ascarpino at openjdk.java.net Thu Jul 8 17:23:02 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 8 Jul 2021 17:23:02 GMT Subject: Integrated: 8269827: JMH tests for AES/GCM byte[] and bytebuffers In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 19:13:48 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of these new jmh tests that run AES/GCM encryption and decryption using byte[], heap bytebuffers, and direct bytebuffers as input and output buffers for single and multi-part testing. > > thanks > > Tony This pull request has now been integrated. Changeset: 58328824 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/58328824927292927a2c6329400cde816c383ecd Stats: 273 lines in 4 files changed: 237 ins; 17 del; 19 mod 8269827: JMH tests for AES/GCM byte[] and bytebuffers Reviewed-by: ecaspole, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/4672 From mullan at openjdk.java.net Thu Jul 8 18:28:12 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 8 Jul 2021 18:28:12 GMT Subject: [jdk17] RFR: 8266345: (fs) Custom DefaultFileSystemProvider security related loops Message-ID: Please review this fix to use the platform's default file system to avoid recursive policy initialization issues when a SecurityManager is enabled and the VM is configured to use a custom file system provider. ------------- Commit messages: - 8266345: (fs) Custom DefaultFileSystemProvider security related loops Changes: https://git.openjdk.java.net/jdk17/pull/232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266345 Stats: 30 lines in 3 files changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/232.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/232/head:pull/232 PR: https://git.openjdk.java.net/jdk17/pull/232 From bpb at openjdk.java.net Thu Jul 8 18:39:54 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 8 Jul 2021 18:39:54 GMT Subject: [jdk17] RFR: 8266345: (fs) Custom DefaultFileSystemProvider security related loops In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:21:31 GMT, Sean Mullan wrote: > Please review this fix to use the platform's default file system to avoid recursive policy initialization > issues when a SecurityManager is enabled and the VM is configured to use a custom file system provider. Looks good. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/232 From mchung at openjdk.java.net Thu Jul 8 19:49:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 8 Jul 2021 19:49:59 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Yi Yang 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: > > restore JSR166; restore java.desktop Looks good. Thanks for separating the other files from this patch. I also did a test run on tier1-3 that looks clean. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4507 From abakhtin at openjdk.java.net Thu Jul 8 21:22:13 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 8 Jul 2021 21:22:13 GMT Subject: [jdk17] RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server Message-ID: The original patch applies clean. Test passed. ------------- Commit messages: - Backport 6f171b9f0d28ad17b31a54bad894f38d19df6f73 Changes: https://git.openjdk.java.net/jdk17/pull/236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268965 Stats: 120 lines in 2 files changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/236.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/236/head:pull/236 PR: https://git.openjdk.java.net/jdk17/pull/236 From xuelei at openjdk.java.net Thu Jul 8 21:35:58 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 8 Jul 2021 21:35:58 GMT Subject: [jdk17] RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: <5FxtwPOPtvTCcjhsHV3WZuP--cjjS6skQuXVMllaMU0=.1fc290e7-3338-4e97-8c0f-22ee9a6a796b@github.com> On Thu, 8 Jul 2021 21:11:54 GMT, Alexey Bakhtin wrote: > The original patch applies clean. > Test passed. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/236 From verghese at amazon.com Fri Jul 9 17:52:37 2021 From: verghese at amazon.com (Verghese, Clive) Date: Fri, 9 Jul 2021 17:52:37 +0000 Subject: Large allocation in CipherSuites. Message-ID: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> Hi We have identified large number of allocations in CipherSuites[1]. The root cause for the allocations is that in the `CipherSuite.values` call in `nameof` and `valueof` functions. These functions are called by the SSLAlgorithmDecomposer and in SSLEngineImpl. The enumeration values functions clones the array before returning. A previous discussion on the compiler-dev channel[2] describes why the values function returns a clone. We would like to propose that the CipherSuite.values be stored in a `private static final` field [3]. This would prevent the need to clone the array for each lookup across the enum. The proposed change stores the ciphers as an array itself. The other alternative would be to store the values as a HashMap. However, I feel that this would not be optimal due to the ordering of the Enumeration. Looking for your feedback and recommendations. If the proposal look good, I can go ahead and create a JBS issue and submit a PR for the same. Regards, Clive Verghese 1 : https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CipherSuite.java 2 : http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012242.html 3 : https://github.com/cliveverghese/jdk/commit/8b34c06d8305ef9cb6a790e4cc8ca169c2fc9d79 From xuelei.fan at oracle.com Fri Jul 9 18:21:01 2021 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Jul 2021 18:21:01 +0000 Subject: Large allocation in CipherSuites. In-Reply-To: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> References: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> Message-ID: Hi Clive, It?s a good point to me! Did you have the numbers about the performance impact? Considering the size of CipherSuites, I think it is good to make an improvement. As we are already here, may be we could consider if we could make further performance improvement for searching as well. Thanks, Xuelei > On Jul 9, 2021, at 10:52 AM, Verghese, Clive wrote: > > Hi > > We have identified large number of allocations in CipherSuites[1]. The root cause for the allocations is that in the `CipherSuite.values` call in `nameof` and `valueof` functions. These functions are called by the SSLAlgorithmDecomposer and in SSLEngineImpl. The enumeration values functions clones the array before returning. A previous discussion on the compiler-dev channel[2] describes why the values function returns a clone. We would like to propose that the CipherSuite.values be stored in a `private static final` field [3]. This would prevent the need to clone the array for each lookup across the enum. > > The proposed change stores the ciphers as an array itself. The other alternative would be to store the values as a HashMap. However, I feel that this would not be optimal due to the ordering of the Enumeration. > > Looking for your feedback and recommendations. If the proposal look good, I can go ahead and create a JBS issue and submit a PR for the same. > > Regards, > Clive Verghese > > 1 : https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CipherSuite.java > 2 : http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012242.html > 3 : https://github.com/cliveverghese/jdk/commit/8b34c06d8305ef9cb6a790e4cc8ca169c2fc9d79 > > From xuelei.fan at oracle.com Fri Jul 9 18:41:22 2021 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Jul 2021 18:41:22 +0000 Subject: Large allocation in CipherSuites. In-Reply-To: References: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> Message-ID: BTW, it may worthy to track the development of the Frozen Arrays JEP: https://openjdk.java.net/jeps/8261007 Xuelei On Jul 9, 2021, at 11:21 AM, Xuelei Fan > wrote: Hi Clive, It?s a good point to me! Did you have the numbers about the performance impact? Considering the size of CipherSuites, I think it is good to make an improvement. As we are already here, may be we could consider if we could make further performance improvement for searching as well. Thanks, Xuelei On Jul 9, 2021, at 10:52 AM, Verghese, Clive > wrote: Hi We have identified large number of allocations in CipherSuites[1]. The root cause for the allocations is that in the `CipherSuite.values` call in `nameof` and `valueof` functions. These functions are called by the SSLAlgorithmDecomposer and in SSLEngineImpl. The enumeration values functions clones the array before returning. A previous discussion on the compiler-dev channel[2] describes why the values function returns a clone. We would like to propose that the CipherSuite.values be stored in a `private static final` field [3]. This would prevent the need to clone the array for each lookup across the enum. The proposed change stores the ciphers as an array itself. The other alternative would be to store the values as a HashMap. However, I feel that this would not be optimal due to the ordering of the Enumeration. Looking for your feedback and recommendations. If the proposal look good, I can go ahead and create a JBS issue and submit a PR for the same. Regards, Clive Verghese 1 : https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CipherSuite.java 2 : http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012242.html 3 : https://github.com/cliveverghese/jdk/commit/8b34c06d8305ef9cb6a790e4cc8ca169c2fc9d79 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Fri Jul 9 20:07:53 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 9 Jul 2021 20:07:53 GMT Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE [v4] In-Reply-To: <5QWKeJcqM8Xe2-IIWY1XULXvcp_y-1TTWTcUZIZmCOI=.2509e392-f2ff-49ad-ab64-35b137c288fc@github.com> References: <5QWKeJcqM8Xe2-IIWY1XULXvcp_y-1TTWTcUZIZmCOI=.2509e392-f2ff-49ad-ab64-35b137c288fc@github.com> Message-ID: On Wed, 23 Jun 2021 22:08:55 GMT, Jack Hartstein wrote: >> 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE > > Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision: > > import cleanup in SupportedGroupsExtension src/java.base/share/classes/sun/security/ssl/AlpnExtension.java line 112: > 110: } > 111: > 112: Stream.Builder alpnNames = Stream.builder(); Did you have some benchmark numbers in this context about the performance improvement by replacing LinkedList with Stream.builder? ------------- PR: https://git.openjdk.java.net/jdk/pull/4577 From github.com+44308314+jackh2000 at openjdk.java.net Fri Jul 9 20:45:57 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Fri, 9 Jul 2021 20:45:57 GMT Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE [v4] In-Reply-To: References: <5QWKeJcqM8Xe2-IIWY1XULXvcp_y-1TTWTcUZIZmCOI=.2509e392-f2ff-49ad-ab64-35b137c288fc@github.com> Message-ID: On Fri, 9 Jul 2021 20:04:40 GMT, Xue-Lei Andrew Fan wrote: >> Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision: >> >> import cleanup in SupportedGroupsExtension > > src/java.base/share/classes/sun/security/ssl/AlpnExtension.java line 112: > >> 110: } >> 111: >> 112: Stream.Builder alpnNames = Stream.builder(); > > Did you have some benchmark numbers in this context about the performance improvement by replacing LinkedList with Stream.builder? Not at the moment but I'm working on setting up some JMH benchmarks now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4577 From verghese at amazon.com Fri Jul 9 20:53:30 2021 From: verghese at amazon.com (Verghese, Clive) Date: Fri, 9 Jul 2021 20:53:30 +0000 Subject: Large allocation in CipherSuites. In-Reply-To: References: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> Message-ID: <44176E4E-C41F-4596-93B4-5D3C366138CE@amazon.com> Thank you for pointing out the JEP. We could still consider this enhancement while we wait for this JEP to land in JDK. With regards to performance, I was unable to benchmark the functions alone as the CipherSuite is not part of the public API. I was able to benchmark SSLHandshakes and the results were as below. Benchmark Mode Cnt Score Error Units CipherSuiteBench.initiateHandshake avgt 25 4.532 ? 0.134 ms/op [Current version using CipherSuite.values] CipherSuiteBench.initiateHandshake avgt 25 4.366 ? 0.037 ms/op [Proposed change Static Array] I will proceed to create the JBS issue and work on getting additional benchmarks and numbers. Regards, Clive Verghese From: Xuelei Fan Date: Friday, July 9, 2021 at 11:43 AM To: "Verghese, Clive" Cc: "security-dev at openjdk.java.net" Subject: RE: Large allocation in CipherSuites. BTW, it may worthy to track the development of the Frozen Arrays JEP: ? ??https://openjdk.java.net/jeps/8261007 Xuelei On Jul 9, 2021, at 11:21 AM, Xuelei Fan wrote: Hi Clive, It?s a good point to me! ?Did you have the numbers about the performance impact? Considering the size of CipherSuites, I think it is good to make an improvement. ?As we are already here, may be we could consider if we could make further performance improvement for searching as well. Thanks, Xuelei On Jul 9, 2021, at 10:52 AM, Verghese, Clive wrote: Hi We have identified large number of allocations in CipherSuites[1]. The root cause for the allocations is that in the `CipherSuite.values` call in `nameof` and `valueof` functions. These functions are called by the SSLAlgorithmDecomposer and in SSLEngineImpl. The enumeration values functions clones the array before returning. A previous discussion on the compiler-dev channel[2] describes why the values function returns a clone. We would like to propose that the CipherSuite.values be stored in a `private static final` field [3]. This would prevent the need to clone the array for each lookup across the enum. The proposed change stores the ciphers as an array itself. The other alternative would be to store the values as a HashMap. However, I feel that this would not be optimal due to the ordering of the Enumeration. Looking for your feedback and recommendations. If the proposal look good, I can go ahead and create a JBS issue and submit a PR for the same. Regards, Clive Verghese 1 : https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CipherSuite.java 2 : http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012242.html 3 : https://github.com/cliveverghese/jdk/commit/8b34c06d8305ef9cb6a790e4cc8ca169c2fc9d79 From xuelei.fan at oracle.com Fri Jul 9 21:04:20 2021 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Jul 2021 21:04:20 +0000 Subject: [External] : Re: Large allocation in CipherSuites. In-Reply-To: <44176E4E-C41F-4596-93B4-5D3C366138CE@amazon.com> References: <04189D53-6FA6-4FBF-AF74-FA47D6AEE769@amazon.com> <44176E4E-C41F-4596-93B4-5D3C366138CE@amazon.com> Message-ID: <077461E4-F492-4885-BE13-104E6741E8BF@oracle.com> Thank you! Xuelei > On Jul 9, 2021, at 1:53 PM, Verghese, Clive wrote: > > Thank you for pointing out the JEP. We could still consider this enhancement while we wait for this JEP to land in JDK. > > With regards to performance, I was unable to benchmark the functions alone as the CipherSuite is not part of the public API. I was able to benchmark SSLHandshakes and the results were as below. > > Benchmark Mode Cnt Score Error Units > CipherSuiteBench.initiateHandshake avgt 25 4.532 ? 0.134 ms/op [Current version using CipherSuite.values] > CipherSuiteBench.initiateHandshake avgt 25 4.366 ? 0.037 ms/op [Proposed change Static Array] > > I will proceed to create the JBS issue and work on getting additional benchmarks and numbers. > > Regards, > Clive Verghese > > > From: Xuelei Fan > Date: Friday, July 9, 2021 at 11:43 AM > To: "Verghese, Clive" > Cc: "security-dev at openjdk.java.net" > Subject: RE: Large allocation in CipherSuites. > > BTW, it may worthy to track the development of the Frozen Arrays JEP: > https://openjdk.java.net/jeps/8261007 > > Xuelei > > > On Jul 9, 2021, at 11:21 AM, Xuelei Fan wrote: > > Hi Clive, > > It?s a good point to me! Did you have the numbers about the performance impact? > > Considering the size of CipherSuites, I think it is good to make an improvement. As we are already here, may be we could consider if we could make further performance improvement for searching as well. > > Thanks, > Xuelei > > > On Jul 9, 2021, at 10:52 AM, Verghese, Clive wrote: > > Hi > > We have identified large number of allocations in CipherSuites[1]. The root cause for the allocations is that in the `CipherSuite.values` call in `nameof` and `valueof` functions. These functions are called by the SSLAlgorithmDecomposer and in SSLEngineImpl. The enumeration values functions clones the array before returning. A previous discussion on the compiler-dev channel[2] describes why the values function returns a clone. We would like to propose that the CipherSuite.values be stored in a `private static final` field [3]. This would prevent the need to clone the array for each lookup across the enum. > > The proposed change stores the ciphers as an array itself. The other alternative would be to store the values as a HashMap. However, I feel that this would not be optimal due to the ordering of the Enumeration. > > Looking for your feedback and recommendations. If the proposal look good, I can go ahead and create a JBS issue and submit a PR for the same. > > Regards, > Clive Verghese > > 1 : https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CipherSuite.java__;!!ACWV5N9M2RV99hQ!c5q6Xvm78wjyt6nXSP7VgXH0HQ2fpiAcTuHRkn8pcTH5aOixqThhw_QfcC3rRhBd$ > 2 : http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012242.html > 3 : https://urldefense.com/v3/__https://github.com/cliveverghese/jdk/commit/8b34c06d8305ef9cb6a790e4cc8ca169c2fc9d79__;!!ACWV5N9M2RV99hQ!c5q6Xvm78wjyt6nXSP7VgXH0HQ2fpiAcTuHRkn8pcTH5aOixqThhw_QfcCmEpVan$ > > > > From jwilhelm at openjdk.java.net Sat Jul 10 00:26:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 10 Jul 2021 00:26:17 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268826: Cleanup Override in Context-Specific Deserialization Filters - 8261147: C2: Node is wrongly marked as reduction resulting in a wrong execution due to wrong vector instructions - 8270151: IncompatibleClassChangeError on empty pattern switch statement case - 8269146: Missing unreported constraints on pattern and other case label combination - 8269952: compiler/vectorapi/VectorCastShape*Test.java tests failed on avx2 machines - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4748/files Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/4748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4748/head:pull/4748 PR: https://git.openjdk.java.net/jdk/pull/4748 From jwilhelm at openjdk.java.net Sat Jul 10 01:26:52 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 10 Jul 2021 01:26:52 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Sat, 10 Jul 2021 00:17:07 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: ec975c6a Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/ec975c6a055688c014e709917dcfc340037e684f Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4748 From peter.firmstone at zeus.net.au Sat Jul 10 07:35:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 10 Jul 2021 17:35:32 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <974bd92d-4a7b-a454-af54-8b395e411abc@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com> <974bd92d-4a7b-a454-af54-8b395e411abc@zeus.net.au> Message-ID: <53634dab-3669-7a41-9095-7e5ac2e4422f@zeus.net.au> Updated authorization layer prototype: https://github.com/pfirmstone/HighPerformanceSecurity On 30/06/2021 9:38 pm, Peter Firmstone wrote: > A draft Authorization implementation, untested. > -- Regards, Peter Firmstone From yyang at openjdk.java.net Mon Jul 12 05:24:57 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 12 Jul 2021 05:24:57 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Yi Yang 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. I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From abakhtin at openjdk.java.net Mon Jul 12 10:28:02 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 12 Jul 2021 10:28:02 GMT Subject: [jdk17] Integrated: 8268965: TCP Connection Reset when connecting simple socket to SSL server In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 21:11:54 GMT, Alexey Bakhtin wrote: > The original patch applies clean. > Test passed. This pull request has now been integrated. Changeset: e1d3e73d Author: Alexey Bakhtin Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk17/commit/e1d3e73d4ee32fac7e5b6b2666221717270d4814 Stats: 120 lines in 2 files changed: 120 ins; 0 del; 0 mod 8268965: TCP Connection Reset when connecting simple socket to SSL server Reviewed-by: xuelei Backport-of: 6f171b9f0d28ad17b31a54bad894f38d19df6f73 ------------- PR: https://git.openjdk.java.net/jdk17/pull/236 From chegar at openjdk.java.net Mon Jul 12 14:42:52 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 12 Jul 2021 14:42:52 GMT Subject: [jdk17] RFR: 8266345: (fs) Custom DefaultFileSystemProvider security related loops In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:21:31 GMT, Sean Mullan wrote: > Please review this fix to use the platform's default file system to avoid recursive policy initialization > issues when a SecurityManager is enabled and the VM is configured to use a custom file system provider. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/232 From mullan at openjdk.java.net Mon Jul 12 14:57:58 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 12 Jul 2021 14:57:58 GMT Subject: [jdk17] Integrated: 8266345: (fs) Custom DefaultFileSystemProvider security related loops In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:21:31 GMT, Sean Mullan wrote: > Please review this fix to use the platform's default file system to avoid recursive policy initialization > issues when a SecurityManager is enabled and the VM is configured to use a custom file system provider. This pull request has now been integrated. Changeset: 4fc3180f Author: Sean Mullan URL: https://git.openjdk.java.net/jdk17/commit/4fc3180f75e1cea4ebd613f8253be205d95f830c Stats: 30 lines in 3 files changed: 28 ins; 0 del; 2 mod 8266345: (fs) Custom DefaultFileSystemProvider security related loops Co-authored-by: Brian Burkhalter Reviewed-by: bpb, chegar ------------- PR: https://git.openjdk.java.net/jdk17/pull/232 From mchung at openjdk.java.net Mon Jul 12 16:56:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 12 Jul 2021 16:56:58 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang wrote: > I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ?? It depends on the change. For this patch, it's good to get another reviewer to look through it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From duke at openjdk.java.net Mon Jul 12 17:35:01 2021 From: duke at openjdk.java.net (duke) Date: Mon, 12 Jul 2021 17:35:01 GMT Subject: Withdrawn: 8267086: Fix ArrayIndexOutOfBoundsException in DerIndefLenConverter In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:33:53 GMT, Fabian Meumertzheim wrote: > `sun.security.util.DerIndefLenConverter#convertBytes` does not perform sufficient checks after calling `#parseValue`, which can overflow `dataPos` or make it exceed `dataSize`. This can lead to an `ArrayIndexOutOfBoundsException`. > > The fix is to ensure `dataPos` is in the valid range `[0,dataSize]` after the call to `parseValue`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4058 From xuelei at openjdk.java.net Mon Jul 12 17:56:02 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 12 Jul 2021 17:56:02 GMT Subject: RFR: 8267086: Fix ArrayIndexOutOfBoundsException in DerIndefLenConverter In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:46:31 GMT, Fabian Meumertzheim wrote: >> `sun.security.util.DerIndefLenConverter#convertBytes` does not perform sufficient checks after calling `#parseValue`, which can overflow `dataPos` or make it exceed `dataSize`. This can lead to an `ArrayIndexOutOfBoundsException`. >> >> The fix is to ensure `dataPos` is in the valid range `[0,dataSize]` after the call to `parseValue`. > > The referenced bug is https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8267086, but for some reason the reference is shown as not valid. @fmeum Did you want to re-open this PR request? I will have a look at the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4058 From github.com+4312191+fmeum at openjdk.java.net Mon Jul 12 18:01:52 2021 From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim) Date: Mon, 12 Jul 2021 18:01:52 GMT Subject: RFR: 8267086: Fix ArrayIndexOutOfBoundsException in DerIndefLenConverter In-Reply-To: References: Message-ID: On Mon, 12 Jul 2021 17:52:58 GMT, Xue-Lei Andrew Fan wrote: >> The referenced bug is https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8267086, but for some reason the reference is shown as not valid. > > @fmeum Did you want to re-open this PR request? I will have a look at the PR. @XueleiFan Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4058 From rriggs at openjdk.java.net Mon Jul 12 19:49:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 12 Jul 2021 19:49:53 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Yi Yang 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: > > restore JSR166; restore java.desktop Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4507 From jwilhelm at openjdk.java.net Mon Jul 12 23:21:35 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 12 Jul 2021 23:21:35 GMT Subject: RFR: Merge jdk17 Message-ID: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8266345: (fs) Custom DefaultFileSystemProvider security related loops - 8269873: serviceability/sa/Clhsdb tests are using a C2 specific VMStruct field - 8268965: TCP Connection Reset when connecting simple socket to SSL server - 8269558: fix of JDK-8252657 missed to update history at the end of JVM TI spec - 8270216: [macOS] Update named used for Java run loop mode The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4760&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4760&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4760/files Stats: 39 lines in 7 files changed: 33 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4760/head:pull/4760 PR: https://git.openjdk.java.net/jdk/pull/4760 From yyang at openjdk.java.net Tue Jul 13 02:38:00 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 13 Jul 2021 02:38:00 GMT Subject: Integrated: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <4Gub7lCLaidzVMPjzkZNJD2kC9X_F7RMtYuNY0c80S4=.5f60cd93-799c-4cd2-8ad9-eb549b0bf281@github.com> On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. This pull request has now been integrated. Changeset: afe957cd Author: Yi Yang URL: https://git.openjdk.java.net/jdk/commit/afe957cd9741810a113ea165a635a117c0ea556f Stats: 357 lines in 40 files changed: 73 ins; 171 del; 113 mod 8268698: Use Objects.check{Index,FromToIndex,FromIndexSize} for java.base Reviewed-by: mchung, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Tue Jul 13 02:37:59 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 13 Jul 2021 02:37:59 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11] In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > Yi Yang 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. Thanks Mandy and Roger for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From jwilhelm at openjdk.java.net Tue Jul 13 10:54:07 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 13 Jul 2021 10:54:07 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com> References: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com> Message-ID: On Mon, 12 Jul 2021 23:12:29 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 6b123b05 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/6b123b059136b0c1efa62a23824b9aa253e6a519 Stats: 39 lines in 7 files changed: 33 ins; 2 del; 4 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4760 From svkamath at openjdk.java.net Tue Jul 13 23:46:40 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Tue, 13 Jul 2021 23:46:40 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v3] In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: > I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - merge master - 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl - Merge master - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions ------------- Changes: https://git.openjdk.java.net/jdk/pull/4019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=02 Stats: 935 lines in 21 files changed: 926 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019 From ssahoo at openjdk.java.net Wed Jul 14 10:12:22 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 14 Jul 2021 10:12:22 GMT Subject: [jdk17] RFR: 8269276: Additional tests for MessageDigest with different providers Message-ID: Few more Test cases added to verify MessageDigest instance generated through different providers. ------------- Commit messages: - 8269276: Additional tests for MessageDigest with different providers Changes: https://git.openjdk.java.net/jdk17/pull/250/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=250&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269276 Stats: 29 lines in 1 file changed: 14 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jdk17/pull/250.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/250/head:pull/250 PR: https://git.openjdk.java.net/jdk17/pull/250 From cverghese at openjdk.java.net Wed Jul 14 17:13:32 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 14 Jul 2021 17:13:32 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite Message-ID: ### Benchmark results I have benchmarked 3 cases. 1. The current situation. Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op 2. Use `static final array` instead of calling `CipherSuite.values` each time. Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. ------------- Commit messages: - 8270317: Large Allocation in CipherSuite Changes: https://git.openjdk.java.net/jdk/pull/4783/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270317 Stats: 100 lines in 2 files changed: 72 ins; 19 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From valeriep at openjdk.java.net Wed Jul 14 17:21:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 14 Jul 2021 17:21:17 GMT Subject: [jdk17] RFR: 8269276: Additional tests for MessageDigest with different providers In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 10:06:59 GMT, Sibabrata Sahoo wrote: > Few more Test cases added to verify MessageDigest instance generated through different providers. Marked as reviewed by valeriep (Reviewer). test/jdk/sun/security/pkcs11/MessageDigest/ReinitDigest.java line 105: > 103: throw new RuntimeException("Algorithm name should equal"); > 104: } > 105: if (md1.getProvider().equals(md2.getProvider())) { nit: calls getName() since the error message says that the comparison is based on provider name. ------------- PR: https://git.openjdk.java.net/jdk17/pull/250 From wetmore at openjdk.java.net Wed Jul 14 17:43:14 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 14 Jul 2021 17:43:14 GMT Subject: [jdk17] RFR: 8269276: Additional tests for MessageDigest with different providers In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 10:06:59 GMT, Sibabrata Sahoo wrote: > Few more Test cases added to verify MessageDigest instance generated through different providers. Marked as reviewed by wetmore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/250 From xuelei at openjdk.java.net Wed Jul 14 19:33:13 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 14 Jul 2021 19:33:13 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Hi Clive Verghese, The performance improve is impressive to me. Would you mind have an additional benchmark for the throughput (@BenchmarkMode(Mode.Throughput))? I guess the throughput should be good as well. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From github.com+30433125+djelinski at openjdk.java.net Wed Jul 14 20:29:14 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Wed, 14 Jul 2021 20:29:14 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. The benchmark you provided looks a bit odd... In variant 1 best and worst cases differ by 3 ns, and in variant 2 they differ by 45 ns. The algorithm is supposed to be the same, so... Where does the difference come from? src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 916: > 914: static String nameOf(int id) { > 915: if (maps_id.containsKey(id)) { > 916: return maps_id.get(id).name; Would it make sense to skip `containsKey` and null-check the value returned by `get` instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From svkamath at openjdk.java.net Wed Jul 14 21:02:01 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 14 Jul 2021 21:02:01 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: > I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Updated AES-GCM intrinsic to match latest Java Code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4019/files - new: https://git.openjdk.java.net/jdk/pull/4019/files/4b6e881e..4a36816f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=02-03 Stats: 469 lines in 11 files changed: 226 ins; 128 del; 115 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019 From xliu at openjdk.java.net Wed Jul 14 21:21:11 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 21:21:11 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: <-KE-AkIC4Nn_m97mPVUCyeVhzYmmllen0vXgv0FyqjU=.af024f8f-858f-46dc-99bb-d5d2ce194de8@github.com> On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 865: > 863: maps_name.put(cs.name, cs); > 864: for (String alias : cs.aliases) { > 865: maps_name.put(alias, cs); A minor concern here. HashMap can't have duplicate keys. what if there are duplicated names/aliases? Even it's not the case now, CipherSuite is subject to change in the future and I think it is a good opportunity to detect key duplication here. Currently, it's silently overwritten. This may introduce inconsistent behavior for nameOf. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From kvn at openjdk.java.net Thu Jul 15 00:22:14 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Jul 2021 00:22:14 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code Looks like you have some issues: wrong file property. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From kvn at openjdk.java.net Thu Jul 15 00:44:15 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Jul 2021 00:44:15 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code First, you need review from Tony for Java side changes. Second, you need to extend tests in `test/hotspot/jtreg/compiler/codegen/aes/` to cover this implementation. And, third, I think we need to put this on hold until the issue of big intrinsics stubs generation effect on startup is solved. See discussion in https://bugs.openjdk.java.net/browse/JDK-8270323 - code_size1 = 20000 LP64_ONLY(+10000), // simply increase if too small (assembler will crash if too small) - code_size2 = 35300 LP64_ONLY(+25000) // simply increase if too small (assembler will crash if too small) + code_size1 = 20000 LP64_ONLY(+12000), // simply increase if too small (assembler will crash if too small) + code_size2 = 35300 LP64_ONLY(+37000) // simply increase if too small (assembler will crash if too small) @sviswa7 please, note these changes too for our discussion. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7644: > 7642: } > 7643: if (UseAESIntrinsics) { > 7644: if (VM_Version::supports_avx512_vaes() && VM_Version::supports_avx512vl() && VM_Version::supports_avx512dq()) { Why duplicate already existing checks? Move code there and add comment for which intrinsic code is generated. src/hotspot/cpu/x86/stubRoutines_x86.hpp line 36: > 34: enum platform_dependent_constants { > 35: code_size1 = 20000 LP64_ONLY(+12000), // simply increase if too small (assembler will crash if too small) > 36: code_size2 = 35300 LP64_ONLY(+37000) // simply increase if too small (assembler will crash if too small) This is almost 50% increase !!! src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 333: > 331: static_field(StubRoutines, _bigIntegerRightShiftWorker, address) \ > 332: static_field(StubRoutines, _bigIntegerLeftShiftWorker, address) \ > 333: static_field(StubRoutines, _galoisCounterMode_AESCrypt, address) \ Move up to other AESCrypt lines. src/hotspot/share/opto/escape.cpp line 1111: > 1109: strcmp(call->as_CallLeaf()->_name, "bigIntegerLeftShiftWorker") == 0 || > 1110: strcmp(call->as_CallLeaf()->_name, "vectorizedMismatch") == 0 || > 1111: strcmp(call->as_CallLeaf()->_name, "galoisCounterMode_AESCrypt") == 0 || Please, move new line where other AEScrypt methods listed. src/hotspot/share/runtime/stubRoutines.cpp line 130: > 128: address StubRoutines::_base64_encodeBlock = NULL; > 129: address StubRoutines::_base64_decodeBlock = NULL; > 130: address StubRoutines::_galoisCounterMode_AESCrypt = NULL; Move up few lines src/hotspot/share/runtime/stubRoutines.hpp line 212: > 210: static address _base64_encodeBlock; > 211: static address _base64_decodeBlock; > 212: static address _galoisCounterMode_AESCrypt; Move up few lines src/hotspot/share/runtime/vmStructs.cpp line 592: > 590: static_field(StubRoutines, _unsafe_arraycopy, address) \ > 591: static_field(StubRoutines, _generic_arraycopy, address) \ > 592: static_field(StubRoutines, _galoisCounterMode_AESCrypt, address) \ Move up to other AESCrypt declarations. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4019 From ssahoo at openjdk.java.net Thu Jul 15 05:46:45 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 15 Jul 2021 05:46:45 GMT Subject: [jdk17] RFR: 8269276: Additional tests for MessageDigest with different providers [v2] In-Reply-To: References: Message-ID: > Few more Test cases added to verify MessageDigest instance generated through different providers. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Create ReinitDigest.java Provider name verification required. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/250/files - new: https://git.openjdk.java.net/jdk17/pull/250/files/fb37a6fd..427bb38f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=250&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=250&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/250.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/250/head:pull/250 PR: https://git.openjdk.java.net/jdk17/pull/250 From ssahoo at openjdk.java.net Thu Jul 15 05:46:48 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 15 Jul 2021 05:46:48 GMT Subject: [jdk17] RFR: 8269276: Additional tests for MessageDigest with different providers [v2] In-Reply-To: References: Message-ID: <-XnwMCn8t5r0hZdN7ASW_UFbbJAXSSpK-AEeZJp7vAw=.b42aa599-d6a4-4533-911b-793cc4572d51@github.com> On Wed, 14 Jul 2021 17:15:14 GMT, Valerie Peng wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> Create ReinitDigest.java >> >> Provider name verification required. > > test/jdk/sun/security/pkcs11/MessageDigest/ReinitDigest.java line 105: > >> 103: throw new RuntimeException("Algorithm name should equal"); >> 104: } >> 105: if (md1.getProvider().equals(md2.getProvider())) { > > nit: calls getName() since the error message says that the comparison is based on provider name. Updated. It was meant to be provider name check. Thanks.. ------------- PR: https://git.openjdk.java.net/jdk17/pull/250 From ssahoo at openjdk.java.net Thu Jul 15 05:46:49 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 15 Jul 2021 05:46:49 GMT Subject: [jdk17] Integrated: 8269276: Additional tests for MessageDigest with different providers In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 10:06:59 GMT, Sibabrata Sahoo wrote: > Few more Test cases added to verify MessageDigest instance generated through different providers. This pull request has now been integrated. Changeset: a32d2eef Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk17/commit/a32d2eefea12771522b942b32985df0fe50119e8 Stats: 29 lines in 1 file changed: 14 ins; 2 del; 13 mod 8269276: Additional tests for MessageDigest with different providers Reviewed-by: valeriep, wetmore ------------- PR: https://git.openjdk.java.net/jdk17/pull/250 From fguallini at openjdk.java.net Thu Jul 15 11:13:37 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 15 Jul 2021 11:13:37 GMT Subject: RFR: 8209776: Refactor jdk/security/JavaDotSecurity/ifdefs.sh to plain java test Message-ID: This change converts security/JavaDotSecurity/ifdefs.sh to java equivalent ------------- Commit messages: - refactored to java Changes: https://git.openjdk.java.net/jdk/pull/4791/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4791&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209776 Stats: 159 lines in 2 files changed: 101 ins; 58 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4791/head:pull/4791 PR: https://git.openjdk.java.net/jdk/pull/4791 From clanger at openjdk.java.net Thu Jul 15 15:20:25 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 15 Jul 2021 15:20:25 GMT Subject: [jdk17] RFR: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA Message-ID: The test is failing since 8th of July. Let's exclude it for now. ------------- Commit messages: - 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA Changes: https://git.openjdk.java.net/jdk17/pull/251/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=251&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270556 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/251.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/251/head:pull/251 PR: https://git.openjdk.java.net/jdk17/pull/251 From ascarpino at openjdk.java.net Thu Jul 15 16:42:11 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 15 Jul 2021 16:42:11 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 20:21:58 GMT, djelinski wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 916: > >> 914: static String nameOf(int id) { >> 915: if (maps_id.containsKey(id)) { >> 916: return maps_id.get(id).name; > > Would it make sense to skip `containsKey` and null-check the value returned by `get` instead? That's what containsKey() does, returning false of the value is null. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Thu Jul 15 17:55:11 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 15 Jul 2021 17:55:11 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 19:30:23 GMT, Xue-Lei Andrew Fan wrote: > Hi Clive Verghese, > > The performance improve is impressive to me. Would you mind have an additional benchmark for the throughput (@BenchmarkMode(Mode.Throughput))? I guess the throughput should be good as well. > > Thanks! Sure, I'll add the Throughput mode and run the benchmarks. > The benchmark you provided looks a bit odd... In variant 1 best and worst cases differ by 3 ns, and in variant 2 they differ by 45 ns. The algorithm is supposed to be the same, so... Where does the difference come from? I'll rerun the benchmarks with larger iterations and investigate a bit further to understand this difference. Thank you for point it out. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From github.com+30433125+djelinski at openjdk.java.net Thu Jul 15 17:55:11 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Thu, 15 Jul 2021 17:55:11 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 16:39:14 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 916: >> >>> 914: static String nameOf(int id) { >>> 915: if (maps_id.containsKey(id)) { >>> 916: return maps_id.get(id).name; >> >> Would it make sense to skip `containsKey` and null-check the value returned by `get` instead? > > That's what containsKey() does, returning false of the value is null. Right. But calling `containsKey` and then `get` results in two hash map lookups. If we cache the result of `get`, we only need one lookup, which should be a tiny bit faster. See https://stackoverflow.com/q/14601016 ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Thu Jul 15 17:55:12 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 15 Jul 2021 17:55:12 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:51:36 GMT, djelinski wrote: >> That's what containsKey() does, returning false of the value is null. > > Right. But calling `containsKey` and then `get` results in two hash map lookups. If we cache the result of `get`, we only need one lookup, which should be a tiny bit faster. See https://stackoverflow.com/q/14601016 I feel that by checking for null, we can reduce one lookup at the Hashtable. Will update the pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From kcr at openjdk.java.net Thu Jul 15 20:49:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Jul 2021 20:49:16 GMT Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 15:21:06 GMT, Sean Mullan wrote: > Please review this fix to backout the change to Disable SHA-1 Signed JARs from JDK 17 due to a startup performance regression (see https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address the performance issue in JDK 18, which will also allow for more bake time. @seanjmullan Since the fix for this bug was integrated via PR #113 can you close this PR to withdraw it? ------------- PR: https://git.openjdk.java.net/jdk17/pull/100 From valeriep at openjdk.java.net Thu Jul 15 22:47:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Jul 2021 22:47:13 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 170: > 168: > 169: // always encrypt mode for embedded cipher > 170: blockCipher.init(false, key.getAlgorithm(), keyValue); Is this change intentional? Looks like we are reverting to older version of source and undo newer changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Thu Jul 15 22:50:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Jul 2021 22:50:17 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 472: > 470: engine = null; > 471: if (encodedKey != null) { > 472: Arrays.fill(encodedKey, (byte)0); Looks like another unintentional newer->older change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Thu Jul 15 22:55:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Jul 2021 22:55:13 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 992: > 990: */ > 991: byte[] overlapDetection(byte[] in, int inOfs, byte[] out, int outOfs) { > 992: if (in == out && (!encryption || inOfs < outOfs)) { So, we will always allocate an output buffer for decryption if in==out? Why just decryption? Update the javadoc for this method with the reason? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From jwilhelm at openjdk.java.net Thu Jul 15 23:50:19 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 15 Jul 2021 23:50:19 GMT Subject: RFR: Merge jdk17 Message-ID: <9HutOH9K_gt9-5fovCfrOvxSSYugRXRgWMPhjRN4F4k=.24169b09-6db0-4551-b104-9528dda354fc@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268635: Corrupt oop in ClassLoaderData - 8269276: Additional tests for MessageDigest with different providers The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/4802/files Stats: 29 lines in 1 file changed: 14 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4802/head:pull/4802 PR: https://git.openjdk.java.net/jdk/pull/4802 From valeriep at openjdk.java.net Thu Jul 15 23:53:10 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Jul 2021 23:53:10 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: <2Et7eUIahoDViqp0MhD_mMse1n0tW7fxWgMjea9yyQU=.09d1eeac-a7be-4da5-8ac6-5405a7c0e45f@github.com> On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 589: > 587: * Requires 768 bytes (48 AES blocks) to efficiently use the intrinsic > 588: * @param in input buffer > 589: * @param inOfs input offset missed @param inLen src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 594: > 592: * @param out output buffer > 593: * @param outOfs output offset > 594: * @param gctr object for the CTR operation typo: CTR->GCTR? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Fri Jul 16 00:14:14 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 16 Jul 2021 00:14:14 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> On Thu, 15 Jul 2021 22:44:05 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 170: > >> 168: >> 169: // always encrypt mode for embedded cipher >> 170: blockCipher.init(false, key.getAlgorithm(), keyValue); > > Is this change intentional? Looks like we are reverting to older version of source and undo newer changes. Nope.. unintentional > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 472: > >> 470: engine = null; >> 471: if (encodedKey != null) { >> 472: Arrays.fill(encodedKey, (byte)0); > > Looks like another unintentional newer->older change. I don't remember an old comment about that, dunno if that was reverted > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 992: > >> 990: */ >> 991: byte[] overlapDetection(byte[] in, int inOfs, byte[] out, int outOfs) { >> 992: if (in == out && (!encryption || inOfs < outOfs)) { > > So, we will always allocate an output buffer for decryption if in==out? Why just decryption? Update the javadoc for this method with the reason? If the crypto is decryption in-place, an internal output buffer is needed in case the auth tag fails, otherwise the input buffer would be zero'ed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 16 00:14:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 16 Jul 2021 00:14:16 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: <3X43XyHHzWOWHvKNMoblGEQpvOBIB5cudVpXZl2yIH8=.4e382ef3-90c8-4749-8768-12470d98e9ab@github.com> On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 611: > 609: outOfs + len); > 610: ghash.update(ct, ctOfs, segments); > 611: ctOfs = len; This does not look right when the initial value of ctOfs != 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From jwilhelm at openjdk.java.net Fri Jul 16 00:55:12 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 16 Jul 2021 00:55:12 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <9HutOH9K_gt9-5fovCfrOvxSSYugRXRgWMPhjRN4F4k=.24169b09-6db0-4551-b104-9528dda354fc@github.com> References: <9HutOH9K_gt9-5fovCfrOvxSSYugRXRgWMPhjRN4F4k=.24169b09-6db0-4551-b104-9528dda354fc@github.com> Message-ID: On Thu, 15 Jul 2021 23:42:37 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 7240d678 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/7240d67868add94c97ca1d7ba372548cd76b8ffc Stats: 29 lines in 1 file changed: 14 ins; 2 del; 13 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4802 From peter.firmstone at zeus.net.au Fri Jul 16 04:20:21 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Jul 2021 14:20:21 +1000 Subject: Authorization layer - threads and privileged calls Message-ID: <70930b67-e03c-3421-bb7e-f5e70c2667b8@zeus.net.au> I'm currently experimenting with a new authorization layer for java, post JEP 411. I would like your thoughts around threads. This is intended to be simpler than Java's existing authorization layer, support user Subjects and code based authorization. Concepts: 1. Application code has no privileges, unless a privileged call is made (implements Callable), the privileges are only in force during execution of the Callable and are not transferable to other threads. 2. A Thread with a stack that only contains code visible to the platform ClassLoader is considered privileged. 3. Privileged means it has defined privileges, it doesn't mean AllPermission. Agents will be used to instrument the Java API for guard checks (would be nice if OpenJDK can annotate these methods or do something to help us identify these locations). Clearly, this will break a lot of existing code, many applications simply won't run, because they don't utilise the API.? It would work fine for new applications. In Java's existing authorization layer implementation (designed prior to the introduction of Executor frameworks), a thread inherits the stack context of the thread which created it, with executors, tasks don't inherit the context of the thread which places the task.? The new framework isn't able to capture the creating threads context, so it makes more sense to treat anything outside a privileged call, or system thread as unprivileged, it does however capture the caller when creating a privileged task, this is a Task that has privileged access, so it's important that it is not allowed to escape. I am thinking about allowing privileged domains, such that if a library (which doesn't implement privileged calls), may be thought of as a system domain, should it create threads, then provided those threads only have privileged domains on the stack, guard checks may proceed.?? For unprivileged application code, all guard checks fail. Any thoughts or questions? -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+114367+mbien at openjdk.java.net Fri Jul 16 04:33:09 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Fri, 16 Jul 2021 04:33:09 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: <-KE-AkIC4Nn_m97mPVUCyeVhzYmmllen0vXgv0FyqjU=.af024f8f-858f-46dc-99bb-d5d2ce194de8@github.com> References: <-KE-AkIC4Nn_m97mPVUCyeVhzYmmllen0vXgv0FyqjU=.af024f8f-858f-46dc-99bb-d5d2ce194de8@github.com> Message-ID: On Wed, 14 Jul 2021 21:18:23 GMT, Xin Liu wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 865: > >> 863: maps_name.put(cs.name, cs); >> 864: for (String alias : cs.aliases) { >> 865: maps_name.put(alias, cs); > > A minor concern here. HashMap can't have duplicate keys. what if there are duplicated names/aliases? > > Even it's not the case now, CipherSuite is subject to change in the future and I think it is a good opportunity to detect key duplication here. Currently, it's silently overwritten. This may introduce inconsistent behavior for nameOf. this could be potentially stored in immutable collections which might be slightly more compact + they throw when they encounter duplicate keys 1) change base type to Map 2) copy ciphers array into Map.Entry array 3) maps_id = Map.ofEntries(entries) // + handle IAE similar for the name map but with a list in between. there might be a JDK internal shortcut to get to new ImmutableCollections.MapN<>(flatArray) right away without the Map.Entry step - I am sure a reviewer will chime in if there is. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From mbaesken at openjdk.java.net Fri Jul 16 05:29:11 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 16 Jul 2021 05:29:11 GMT Subject: [jdk17] RFR: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 15:04:04 GMT, Christoph Langer wrote: > The test is failing since 8th of July. Let's exclude it for now. Marked as reviewed by mbaesken (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/251 From mullan at openjdk.java.net Fri Jul 16 12:42:08 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 16 Jul 2021 12:42:08 GMT Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 20:46:44 GMT, Kevin Rushforth wrote: >> Please review this fix to backout the change to Disable SHA-1 Signed JARs from JDK 17 due to a startup performance regression (see https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address the performance issue in JDK 18, which will also allow for more bake time. > > @seanjmullan Since the fix for this bug was integrated via PR #113 can you close this PR to withdraw it? @kevinrushforth Done. ------------- PR: https://git.openjdk.java.net/jdk17/pull/100 From mullan at openjdk.java.net Fri Jul 16 12:42:08 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 16 Jul 2021 12:42:08 GMT Subject: [jdk17] Withdrawn: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 15:21:06 GMT, Sean Mullan wrote: > Please review this fix to backout the change to Disable SHA-1 Signed JARs from JDK 17 due to a startup performance regression (see https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address the performance issue in JDK 18, which will also allow for more bake time. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/100 From sean.mullan at oracle.com Fri Jul 16 13:44:15 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Jul 2021 09:44:15 -0400 Subject: A few updates to JEP 411: Deprecate the Security Manager for Removal Message-ID: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> JEP 411 has been updated with a few changes: 1. The "Description" section [1] has been updated with more details on our plans for phasing out the Security Manager in Java 18 and later. 2. The "Issue warnings" section [2] has been updated with the warning messages that are emitted at startup and run time when a Security Manager has been enabled. 3. JEP 411 has been moved to the Completed state as all required tasks have been completed. Thanks, Sean [1] https://openjdk.java.net/jeps/411#Description [2] https://openjdk.java.net/jeps/411#Issue-warnings From clanger at openjdk.java.net Fri Jul 16 19:05:55 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 16 Jul 2021 19:05:55 GMT Subject: [jdk17] Integrated: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 15:04:04 GMT, Christoph Langer wrote: > The test is failing since 8th of July. Let's exclude it for now. This pull request has now been integrated. Changeset: 1350e2bd Author: Christoph Langer URL: https://git.openjdk.java.net/jdk17/commit/1350e2bd225b2032b929f9c68ba297833ad6b2bf Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA Reviewed-by: mbaesken ------------- PR: https://git.openjdk.java.net/jdk17/pull/251 From valeriep at openjdk.java.net Fri Jul 16 19:44:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 16 Jul 2021 19:44:53 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 629: > 627: GCTR gctr; > 628: GHASH ghash; > 629: GCMOperation op; It seems clearer to initialize "op" in GCMEngine ctor since it's declared here. There is already logic in its method checking whether we are doing encryption or decryption. src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 650: > 648: int originalOutOfs = 0; > 649: byte[] in; > 650: byte[] out; The name "in", "out" are almost used in all calls, it's hard to tell when these two are actually used. Can we rename them to make them more unique? src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 724: > 722: } else { > 723: ct = in; > 724: } This can just be: byte[] ct = (encryption? out : in); Since you only use this 'ct' variable inside the else block on line 746, move this down to that block. src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 743: > 741: dst.array(), dst.arrayOffset() + dst.position(), > 742: gctr, ghash); > 743: } Can we use another ByteBuffer variable to avoid almost-duplicate calls? ByteBuffer ct = (encryption? dst : src); rlen -= GaloisCounterMode.implGCMCrypt(src.array(), src.arrayOffset() + src.position(), src.remaining(), ct.array(), ct.arrayOffset() + ct.position(), dst.array(), dst.arrayOffset() + dst.position(), gctr, ghash); ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 16 19:44:54 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 16 Jul 2021 19:44:54 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 16 Jul 2021 00:32:16 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 629: > >> 627: GCTR gctr; >> 628: GHASH ghash; >> 629: GCMOperation op; > > It seems clearer to initialize "op" in GCMEngine ctor since it's declared here. There is already logic in its method checking whether we are doing encryption or decryption. Now that you have GCMOperation op, but there is still if-else blocks checking whether it's encryption/decryption and uses gctr and ghash instead of op. Looks like a bit adhoc? Can GaloisCounterMode.implGCMCrypt(...) just take GCMOperation op instead, no need for ct, ctOfs, gctr and ghash? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 16 20:51:52 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 16 Jul 2021 20:51:52 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated AES-GCM intrinsic to match latest Java Code src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 146: > 144: } > 145: state = new long[2]; > 146: subkeyHtbl = new long[2*57]; // 48 keys for the interleaved implementation, 8 for avx-ghash implementation and one for the original key nit: the comment is too long, i.e. > 80 ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Sat Jul 17 03:33:54 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sat, 17 Jul 2021 03:33:54 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> Message-ID: On Fri, 16 Jul 2021 00:10:52 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 992: >> >>> 990: */ >>> 991: byte[] overlapDetection(byte[] in, int inOfs, byte[] out, int outOfs) { >>> 992: if (in == out && (!encryption || inOfs < outOfs)) { >> >> So, we will always allocate an output buffer for decryption if in==out? Why just decryption? Update the javadoc for this method with the reason? > > If the crypto is decryption in-place, an internal output buffer is needed in case the auth tag fails, otherwise the input buffer would be zero'ed. If decryption fails with a bad auth tag, the in is not overwritten because it's in-place. Encryption is not needed because there is nothing to check. I can add a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Sat Jul 17 04:04:56 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sat, 17 Jul 2021 04:04:56 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 16 Jul 2021 20:49:20 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 146: > >> 144: } >> 145: state = new long[2]; >> 146: subkeyHtbl = new long[2*57]; // 48 keys for the interleaved implementation, 8 for avx-ghash implementation and one for the original key > > nit: the comment is too long, i.e. > 80 Ah.. I forgot I didn't change GHASH with my changes.. but I'll fix that thanks > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 743: > >> 741: dst.array(), dst.arrayOffset() + dst.position(), >> 742: gctr, ghash); >> 743: } > > Can we use another ByteBuffer variable to avoid almost-duplicate calls? > > ByteBuffer ct = (encryption? dst : src); > rlen -= GaloisCounterMode.implGCMCrypt(src.array(), > src.arrayOffset() + src.position(), src.remaining(), > ct.array(), ct.arrayOffset() + ct.position(), > dst.array(), dst.arrayOffset() + dst.position(), > gctr, ghash); That maybe a better choice ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From peter.firmstone at zeus.net.au Sat Jul 17 04:53:55 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 17 Jul 2021 14:53:55 +1000 Subject: A few updates to JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> References: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> Message-ID: <4ed180cc-d479-fba6-b493-e7a1c0353ac8@zeus.net.au> Thanks Sean, Has there been any progress with JDK-8264713? https://bugs.openjdk.java.net/browse/JDK-8264713 Regards, Peter. On 16/07/2021 11:44 pm, Sean Mullan wrote: > JEP 411 has been updated with a few changes: > > 1. The "Description" section [1] has been updated with more details on > our plans for phasing out the Security Manager in Java 18 and later. > > 2. The "Issue warnings" section [2] has been updated with the warning > messages that are emitted at startup and run time when a Security > Manager has been enabled. > > 3. JEP 411 has been moved to the Completed state as all required tasks > have been completed. > > Thanks, > Sean > > [1] https://openjdk.java.net/jeps/411#Description > [2] https://openjdk.java.net/jeps/411#Issue-warnings From peter.firmstone at zeus.net.au Sat Jul 17 07:40:54 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 17 Jul 2021 17:40:54 +1000 Subject: Authorization layer - threads and privileged calls In-Reply-To: <70930b67-e03c-3421-bb7e-f5e70c2667b8@zeus.net.au> References: <70930b67-e03c-3421-bb7e-f5e70c2667b8@zeus.net.au> Message-ID: <28577056-1e00-dc37-d45b-c0c48a9304fa@zeus.net.au> I've added the following method to the Authorization class: /** ???? * This method allows a developer to register the domain of a ???? * dependency which doesn't utilize this Authorization layer, to be ???? * considered as a trusted platform layer, in doing so however, ???? * the dependency should be audited for vulnerabilities and instrumented ???? * with guards if necessary. ???? * ???? * The intent of this method, is to allow guards to check the domains ???? * on a thread call stack which hasn't originated from a privileged call, ???? * the privileges of the domain are still checked, however it is preferable ???? * for privileged calls to wrap and encapsulate dependency code if possible. ???? * In the event that dependency code creates its own worker threads internally ???? * which require privileges, this method allows those privileges to be checked, ???? * rather than immediately rejected. ???? * ???? * However dependency code is unlikely to discriminate between calling code ???? * and as such may allow other code to call it also, which may open ???? * authorization security vulnerabilities.? In this case, the developer ???? * may request the dependency code developers to add support, or may instrument the ???? * dependency code with guard checks using the Attach API. ???? * Alternatively a developer may wish to use module or ClassLoader visibility, ???? * to isolate the dependency code. ???? * ???? * @param cl a class belonging to the privileged domain. ???? */ ??? public static void registerPrivileged(Class cl){ ??????? GUARD_PRIVILEGED_CHECK.checkGuard(cl); ??????? Authorization authorization = INHERITED_CONTEXT.get(); ??????? try { ??????????? INHERITED_CONTEXT.set(PRIVILEGED); ??????????? PRIVILEGED_DOMAINS.add(cl.getProtectionDomain()); ??????? } finally { ??????????? INHERITED_CONTEXT.set(authorization); ??????? } ??? } On 16/07/2021 2:20 pm, Peter Firmstone wrote: > > I'm currently experimenting with a new authorization layer for java, > post JEP 411. > > I would like your thoughts around threads. > > This is intended to be simpler than Java's existing authorization > layer, support user Subjects and code based authorization. > > Concepts: > > 1. Application code has no privileges, unless a privileged call is > made (implements Callable), the privileges are only in force > during execution of the Callable and are not transferable to other > threads. > 2. A Thread with a stack that only contains code visible to the > platform ClassLoader is considered privileged. > 3. Privileged means it has defined privileges, it doesn't mean > AllPermission. > > Agents will be used to instrument the Java API for guard checks (would > be nice if OpenJDK can annotate these methods or do something to help > us identify these locations). > > Clearly, this will break a lot of existing code, many applications > simply won't run, because they don't utilise the API.? It would work > fine for new applications. > > In Java's existing authorization layer implementation (designed prior > to the introduction of Executor frameworks), a thread inherits the > stack context of the thread which created it, with executors, tasks > don't inherit the context of the thread which places the task.? The > new framework isn't able to capture the creating threads context, so > it makes more sense to treat anything outside a privileged call, or > system thread as unprivileged, it does however capture the caller when > creating a privileged task, this is a Task that has privileged access, > so it's important that it is not allowed to escape. > > I am thinking about allowing privileged domains, such that if a > library (which doesn't implement privileged calls), may be thought of > as a system domain, should it create threads, then provided those > threads only have privileged domains on the stack, guard checks may > proceed.?? For unprivileged application code, all guard checks fail. > > Any thoughts or questions? > > -- > Regards, > > Peter Firmstone > 0498 286 363 > Zeus Project Services Pty Ltd. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ascarpino at openjdk.java.net Sat Jul 17 16:53:52 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sat, 17 Jul 2021 16:53:52 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 16 Jul 2021 19:41:53 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 629: >> >>> 627: GCTR gctr; >>> 628: GHASH ghash; >>> 629: GCMOperation op; >> >> It seems clearer to initialize "op" in GCMEngine ctor since it's declared here. There is already logic in its method checking whether we are doing encryption or decryption. > > Now that you have GCMOperation op, but there is still if-else blocks checking whether it's encryption/decryption and uses gctr and ghash instead of op. Looks like a bit adhoc? Can GaloisCounterMode.implGCMCrypt(...) just take GCMOperation op instead, no need for ct, ctOfs, gctr and ghash? Initializing op in abstract GCMEngine would mean another 'if(encryption)', when that would not be needed in the GCMEncrypt() or GCMDecrypt(). I don't see why that is clearer. GaloisCounterMode.implGCMCrypt(...) is the intrinsic, so I have to use what is used by hotspot. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From peter.firmstone at zeus.net.au Sun Jul 18 01:13:07 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 18 Jul 2021 11:13:07 +1000 Subject: A few updates to JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <4ed180cc-d479-fba6-b493-e7a1c0353ac8@zeus.net.au> References: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> <4ed180cc-d479-fba6-b493-e7a1c0353ac8@zeus.net.au> Message-ID: <830d38e1-2085-b2b8-ffaf-5d8245440289@zeus.net.au> My mistake copied wrong bug: Has there been any progress with the new Subject API? https://bugs.openjdk.java.net/browse/JDK-8267108 On 17/07/2021 2:53 pm, Peter Firmstone wrote: > Thanks Sean, > > Has there been any progress with JDK-8264713? > > https://bugs.openjdk.java.net/browse/JDK-8264713 > > Regards, > > Peter. > > > On 16/07/2021 11:44 pm, Sean Mullan wrote: >> JEP 411 has been updated with a few changes: >> >> 1. The "Description" section [1] has been updated with more details >> on our plans for phasing out the Security Manager in Java 18 and later. >> >> 2. The "Issue warnings" section [2] has been updated with the warning >> messages that are emitted at startup and run time when a Security >> Manager has been enabled. >> >> 3. JEP 411 has been moved to the Completed state as all required >> tasks have been completed. >> >> Thanks, >> Sean >> >> [1] https://openjdk.java.net/jeps/411#Description >> [2] https://openjdk.java.net/jeps/411#Issue-warnings > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sun Jul 18 06:06:03 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 18 Jul 2021 16:06:03 +1000 Subject: Authorization layer - threads and privileged calls In-Reply-To: <28577056-1e00-dc37-d45b-c0c48a9304fa@zeus.net.au> References: <70930b67-e03c-3421-bb7e-f5e70c2667b8@zeus.net.au> <28577056-1e00-dc37-d45b-c0c48a9304fa@zeus.net.au> Message-ID: <875c8680-d176-9b4f-120f-c747cec077b6@zeus.net.au> Note that the new authorization layer avoids "viral permissions" by requiring a privileged call before privileges will be enabled. Apart from privileged calls, only if a thread call stack contains all privileged domains, will it proceed with a Guard check. The authorization layer doesn't define the granularity of Guard checks, that is up to the implementations. This isn't working code yet, presently it's intended to communicate authorization concepts.? Hopefully OpenJDK will assist by providing some hooks in OpenJDK code for guard checks. Latest update, more documentation: https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java Note this authorization layer also provides a way to preserve a user Subject across threads for authentication of TLS and Kerberos connections. Peter. On 17/07/2021 5:40 pm, Peter Firmstone wrote: > > I've added the following method to the Authorization class: > > /** > ???? * This method allows a developer to register the domain of a > ???? * dependency which doesn't utilize this Authorization layer, to be > ???? * considered as a trusted platform layer, in doing so however, > ???? * the dependency should be audited for vulnerabilities and > instrumented > ???? * with guards if necessary. > ???? * > ???? * The intent of this method, is to allow guards to check the domains > ???? * on a thread call stack which hasn't originated from a > privileged call, > ???? * the privileges of the domain are still checked, however it is > preferable > ???? * for privileged calls to wrap and encapsulate dependency code if > possible. > ???? * In the event that dependency code creates its own worker > threads internally > ???? * which require privileges, this method allows those privileges > to be checked, > ???? * rather than immediately rejected. > ???? * > ???? * However dependency code is unlikely to discriminate between > calling code > ???? * and as such may allow other code to call it also, which may open > ???? * authorization security vulnerabilities.? In this case, the > developer > ???? * may request the dependency code developers to add support, or > may instrument the > ???? * dependency code with guard checks using the Attach API. > ???? * Alternatively a developer may wish to use module or ClassLoader > visibility, > ???? * to isolate the dependency code. > ???? * > ???? * @param cl a class belonging to the privileged domain. > ???? */ > ??? public static void registerPrivileged(Class cl){ > ??????? GUARD_PRIVILEGED_CHECK.checkGuard(cl); > ??????? Authorization authorization = INHERITED_CONTEXT.get(); > ??????? try { > ??????????? INHERITED_CONTEXT.set(PRIVILEGED); > ??????????? PRIVILEGED_DOMAINS.add(cl.getProtectionDomain()); > ??????? } finally { > ??????????? INHERITED_CONTEXT.set(authorization); > ??????? } > ??? } > > On 16/07/2021 2:20 pm, Peter Firmstone wrote: >> >> I'm currently experimenting with a new authorization layer for java, >> post JEP 411. >> >> I would like your thoughts around threads. >> >> This is intended to be simpler than Java's existing authorization >> layer, support user Subjects and code based authorization. >> >> Concepts: >> >> 1. Application code has no privileges, unless a privileged call is >> made (implements Callable), the privileges are only in force >> during execution of the Callable and are not transferable to >> other threads. >> 2. A Thread with a stack that only contains code visible to the >> platform ClassLoader is considered privileged. >> 3. Privileged means it has defined privileges, it doesn't mean >> AllPermission. >> >> Agents will be used to instrument the Java API for guard checks >> (would be nice if OpenJDK can annotate these methods or do something >> to help us identify these locations). >> >> Clearly, this will break a lot of existing code, many applications >> simply won't run, because they don't utilise the API.? It would work >> fine for new applications. >> >> In Java's existing authorization layer implementation (designed prior >> to the introduction of Executor frameworks), a thread inherits the >> stack context of the thread which created it, with executors, tasks >> don't inherit the context of the thread which places the task.? The >> new framework isn't able to capture the creating threads context, so >> it makes more sense to treat anything outside a privileged call, or >> system thread as unprivileged, it does however capture the caller >> when creating a privileged task, this is a Task that has privileged >> access, so it's important that it is not allowed to escape. >> >> I am thinking about allowing privileged domains, such that if a >> library (which doesn't implement privileged calls), may be thought of >> as a system domain, should it create threads, then provided those >> threads only have privileged domains on the stack, guard checks may >> proceed.?? For unprivileged application code, all guard checks fail. >> >> Any thoughts or questions? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jul 19 12:29:56 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Jul 2021 08:29:56 -0400 Subject: A few updates to JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <830d38e1-2085-b2b8-ffaf-5d8245440289@zeus.net.au> References: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> <4ed180cc-d479-fba6-b493-e7a1c0353ac8@zeus.net.au> <830d38e1-2085-b2b8-ffaf-5d8245440289@zeus.net.au> Message-ID: <3ef84d92-720d-8123-4098-d5367856bb2d@oracle.com> On 7/17/21 9:13 PM, Peter Firmstone wrote: > My mistake copied wrong bug: > > Has there been any progress with the new Subject API? > > https://bugs.openjdk.java.net/browse/JDK-8267108 Not yet, but I would like to see that done for JDK 18, so expect to see some progress on that in the next few months. Thanks, Sean > > On 17/07/2021 2:53 pm, Peter Firmstone wrote: >> Thanks Sean, >> >> Has there been any progress with JDK-8264713? >> >> https://bugs.openjdk.java.net/browse/JDK-8264713 >> >> Regards, >> >> Peter. >> >> >> On 16/07/2021 11:44 pm, Sean Mullan wrote: >>> JEP 411 has been updated with a few changes: >>> >>> 1. The "Description" section [1] has been updated with more details >>> on our plans for phasing out the Security Manager in Java 18 and later. >>> >>> 2. The "Issue warnings" section [2] has been updated with the warning >>> messages that are emitted at startup and run time when a Security >>> Manager has been enabled. >>> >>> 3. JEP 411 has been moved to the Completed state as all required >>> tasks have been completed. >>> >>> Thanks, >>> Sean >>> >>> [1] https://openjdk.java.net/jeps/411#Description >>> [2] https://openjdk.java.net/jeps/411#Issue-warnings >> From peter.firmstone at zeus.net.au Wed Jul 21 11:37:53 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 21 Jul 2021 21:37:53 +1000 Subject: A few updates to JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <3ef84d92-720d-8123-4098-d5367856bb2d@oracle.com> References: <74bc1acd-408f-6989-34cd-1c184da8329f@oracle.com> <4ed180cc-d479-fba6-b493-e7a1c0353ac8@zeus.net.au> <830d38e1-2085-b2b8-ffaf-5d8245440289@zeus.net.au> <3ef84d92-720d-8123-4098-d5367856bb2d@oracle.com> Message-ID: <0979b981-35d2-842b-c8b6-c01af79491b7@zeus.net.au> Thanks Sean, Be nice if it can be implemented in a way that allows it to be decorated. Regards, Peter. On 19/07/2021 10:29 pm, Sean Mullan wrote: > > > On 7/17/21 9:13 PM, Peter Firmstone wrote: >> My mistake copied wrong bug: >> >> Has there been any progress with the new Subject API? >> >> https://bugs.openjdk.java.net/browse/JDK-8267108 > > Not yet, but I would like to see that done for JDK 18, so expect to > see some progress on that in the next few months. > > Thanks, > Sean > >> >> On 17/07/2021 2:53 pm, Peter Firmstone wrote: >>> Thanks Sean, >>> >>> Has there been any progress with JDK-8264713? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8264713 >>> >>> Regards, >>> >>> Peter. >>> >>> >>> On 16/07/2021 11:44 pm, Sean Mullan wrote: >>>> JEP 411 has been updated with a few changes: >>>> >>>> 1. The "Description" section [1] has been updated with more details >>>> on our plans for phasing out the Security Manager in Java 18 and >>>> later. >>>> >>>> 2. The "Issue warnings" section [2] has been updated with the warning >>>> messages that are emitted at startup and run time when a Security >>>> Manager has been enabled. >>>> >>>> 3. JEP 411 has been moved to the Completed state as all required >>>> tasks have been completed. >>>> >>>> Thanks, >>>> Sean >>>> >>>> [1] https://openjdk.java.net/jeps/411#Description >>>> [2] https://openjdk.java.net/jeps/411#Issue-warnings >>> From alexey.shponarsky at jelastic.com Wed Jul 21 16:35:12 2021 From: alexey.shponarsky at jelastic.com (Alexey Shponarsky) Date: Wed, 21 Jul 2021 19:35:12 +0300 Subject: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223) Message-ID: Hello, At Jelastic PaaS, we are using SecurityManager within Java Scripting (JSR 223). Specifically, Java Scripting allows us and our customers to easily extend the core platform functionality with custom logic. The developers can execute their custom scriptlets inside a Java Scripting runtime environment with pre-injected core platform API methods. For example, //@req(pathFrom, pathTo) var mountFrom = "${nodes.build.first.id}", envName = "${settings.targetEnv}", mountTo = "cp"; var resp = jelastic.env.file.RemoveMountPointByGroup(envName, session, mountTo, pathTo); if (resp.result != 0) return resp; return jelastic.env.file.AddMountPointByGroup(envName, session, mountTo, pathTo, 'nfs', null, pathFrom, mountFrom, '', false); As Java Scripting engine / technology provides quite powerful runtimes, we have to restrict certains actions such as execution of any reflection methods, change of any system environment variables, exit, calling some dangerous static methods, reading files outside of the sandbox folder, etc. The SecurityManager mechanism provided an ability to configure permissions easily. To achieve this we create an instance of AccessControlContext with required permissions and pass it to AccessController.doPrivileged method: //Create list of Permission: Collection perms = new LinkedList(); perms.add(new RuntimePermission("createClassLoader")); perms.add(new RuntimePermission("getClassLoader")); perms.add(new RuntimePermission("accessDeclaredMembers")); perms.add(new RuntimePermission("getProtectionDomain")); perms.add(new PropertyPermission("*", "read")); perms.add(new SocketPermission("*", "connect,accept,resolve")); perms.add(new SocketPermission("localhost:0-", "connect,accept,resolve,listen")); //Create AccessControlContext ProtectionDomain domain = new ProtectionDomain(new CodeSource(null, ( Certificate[]) null), perms); AccessControlContext acc = new AccessControlContext(new ProtectionDomain[]{ domain}); //Run untrusted code using created AccessControlContext @Override public ScriptEvalResponse call() throws Exception { Object obj = AccessController.doPrivileged(new PrivilegedAction() { @Override public Object run() { try { Object response = compiledScript.eval(ctx); ScriptEvalResponse evalResponse = new ScriptEvalResponse( Response.OK); evalResponse.setResponse(response); return evalResponse; } catch (Exception ex) { logger.debug("Error occurred during eval script:", ex); return ex; } } }, acc); if (obj instanceof Exception) { throw (Exception) obj; } return (ScriptEvalResponse) obj; } How can we implement a similar solution after the removal of SecurityManager? Could you help us to find an alternative? -- Alexey Shponarsky Director of R&D Twitter Facebook YouTube LinkedIn Google+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jul 21 19:31:13 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 21 Jul 2021 15:31:13 -0400 Subject: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223) In-Reply-To: References: Message-ID: <9882022f-a1cd-d038-bec8-d11768578569@oracle.com> Hi, I am not an expert in JSR 223. However, some JSR 223 implementations include a mechanism for restricting access to Java classes, for example Nashorn [1] and Rhino [2], which might be sufficient for your needs. (Note, Nashorn was deprecated and removed from JDK 15 [3]). I think most of the permissions you list below can be mapped to a small list of Java classes that check those permissions. Also, with strong encapsulation of JDK internals enforced by default in JDK 17 [4], you get additional protection that is not dependent on the Security Manager. What JSR 223 implementation do you use? --Sean [1] https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction [2] https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/ClassShutter.html [3] https://openjdk.java.net/jeps/372 [4] https://openjdk.java.net/jeps/403 On 7/21/21 12:35 PM, Alexey Shponarsky wrote: > Hello, > > At Jelastic PaaS, we are using SecurityManager within Java Scripting > (JSR 223). Specifically, Java Scripting allows us and our customers to > easily extend the core platform functionality with custom logic. The > developers can execute their custom scriptlets inside a Java Scripting > runtime environment with pre-injected core platform API methods. For > example, > > //@req(pathFrom, pathTo) > > varmountFrom = "${nodes.build.first.id }", > > envName = "${settings.targetEnv}", > > mountTo = "cp"; > > varresp = jelastic.env.file.RemoveMountPointByGroup(envName, session, > mountTo, pathTo); > > if(resp.result != 0) returnresp; > > returnjelastic.env.file.AddMountPointByGroup(envName, session, > mountTo, pathTo, 'nfs', null, pathFrom, mountFrom, '', false); > > As Java Scripting engine / technology provides quite powerful > runtimes, we have to restrict certains actions such as execution of > any reflection methods, change of any system environment variables, > exit, calling some dangerous static methods, reading files outside of > the sandbox folder, etc. The SecurityManager mechanism provided an > ability to configure permissions easily. > > To achieve this we create an instance of AccessControlContext with > required permissions and pass it to AccessController.doPrivileged > method: > > //Create list of Permission: > > Collection perms= new LinkedList(); > > perms.add(new RuntimePermission("createClassLoader")); > > perms.add(new RuntimePermission("getClassLoader")); > > perms.add(new RuntimePermission("accessDeclaredMembers")); > > perms.add(new RuntimePermission("getProtectionDomain")); > > perms.add(new PropertyPermission("*", "read")); > > perms.add(new SocketPermission("*", "connect,accept,resolve")); > > perms.add(new SocketPermission("localhost:0-", > "connect,accept,resolve,listen")); > > //Create AccessControlContext > > ProtectionDomain domain = new ProtectionDomain(new CodeSource(null, > (Certificate[]) null), perms); > > AccessControlContext acc= new AccessControlContext(new > ProtectionDomain[]{domain}); > > //Run untrusted code using created AccessControlContext > > @Override > > public ScriptEvalResponse call() throws Exception { > > Object obj = AccessController.doPrivileged(new > PrivilegedAction() { > > @Override > > public Object run() { > > try { > > Object response = compiledScript.eval(ctx); > > ScriptEvalResponse evalResponse = new ScriptEvalResponse(Response.OK); > > evalResponse.setResponse(response); > > return evalResponse; > > ???????????} catch (Exception ex) { > > logger.debug("Error occurred during eval script:", ex); > > return ex; > > ???????????} > > ???????} > > ???}, acc); > > if (obj instanceof Exception) { > > throw (Exception) obj; > > ???} > > return (ScriptEvalResponse) obj; > > } > > How can we implement a similar solution after the removal of > SecurityManager? Could you help us to find an alternative? > > > > -- > Alexey Shponarsky Director of R&D > Twitter Facebook > YouTube > LinkedIn > Google+ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cverghese at openjdk.java.net Wed Jul 21 23:58:15 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 21 Jul 2021 23:58:15 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v2] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Move to Immutable map and reduce map lookups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/f7814afb..aec4f54c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=00-01 Stats: 16 lines in 2 files changed: 7 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Wed Jul 21 23:58:15 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 21 Jul 2021 23:58:15 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: <4djwVMsduXihrzIr80UhcX2bLbkCe2ofL1gAnyklrr8=.ed759424-c73c-4537-bbf3-b0d75e79f920@github.com> On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Updated Benchmarks in Throughput mode ### Current Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 8050.787 ? 232.335 ops/ms CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 8165.124 ? 283.718 ops/ms CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 7827.758 ? 293.311 ops/ms CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 7768.286 ? 181.399 ops/ms ### ArrayList Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 100.626 ? 0.294 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 32.793 ? 0.804 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 21.162 ? 0.217 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 18.220 ? 0.903 ops/us ### Hashmap Benchmark (cipherSuite) Mode Cnt Score Error Units CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 63.836 ? 4.517 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 69.983 ? 8.965 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 68.091 ? 7.404 ops/us CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 52.831 ? 4.317 ops/us I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Wed Jul 21 23:58:16 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 21 Jul 2021 23:58:16 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v2] In-Reply-To: References: <-KE-AkIC4Nn_m97mPVUCyeVhzYmmllen0vXgv0FyqjU=.af024f8f-858f-46dc-99bb-d5d2ce194de8@github.com> Message-ID: On Fri, 16 Jul 2021 04:29:51 GMT, Michael Bien wrote: >> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 865: >> >>> 863: maps_name.put(cs.name, cs); >>> 864: for (String alias : cs.aliases) { >>> 865: maps_name.put(alias, cs); >> >> A minor concern here. HashMap can't have duplicate keys. what if there are duplicated names/aliases? >> >> Even it's not the case now, CipherSuite is subject to change in the future and I think it is a good opportunity to detect key duplication here. Currently, it's silently overwritten. This may introduce inconsistent behavior for nameOf. > > this could be potentially stored in immutable collections which might be slightly more compact + they throw when they encounter duplicate keys > 1) change base type to Map > 2) copy ciphers array into Map.Entry array > 3) maps_id = Map.ofEntries(entries) // + handle IAE > > similar for the name map but with a list in between. > > there might be a JDK internal shortcut to get to new ImmutableCollections.MapN<>(flatArray) right away without the Map.Entry step - I am sure a reviewer will chime in if there is. Thank you for the feedback. I have updated to use ImmutableMap. However, I had to use `copyOf(Map)` method instead. It would not check for duplicate values. Would it make more sense to add a test case to check for duplicates instead?. If so I can add that, else i'll check for duplicate while creating the map. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Wed Jul 21 23:58:16 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 21 Jul 2021 23:58:16 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:51:58 GMT, Clive Verghese wrote: >> Right. But calling `containsKey` and then `get` results in two hash map lookups. If we cache the result of `get`, we only need one lookup, which should be a tiny bit faster. See https://stackoverflow.com/q/14601016 > > I feel that by checking for null, we can reduce one lookup at the Hashtable. Will update the pull request. Updated in the new revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From jwilhelm at openjdk.java.net Thu Jul 22 00:02:23 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:02:23 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch - 8264066: Enhance compiler validation - 8265201: JarFile.getInputStream not validating invalid signed jars - 8258432: Improve File Transfers - 8264079: Improve abstractions - 8262380: Enhance XML processing passes - 8262967: Improve Zip file support - 8264460: Improve NTLM support - 8256491: Better HTTP transport - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4863/files Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/4863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863 PR: https://git.openjdk.java.net/jdk/pull/4863 From xuelei at openjdk.java.net Thu Jul 22 00:14:48 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 22 Jul 2021 00:14:48 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: <4djwVMsduXihrzIr80UhcX2bLbkCe2ofL1gAnyklrr8=.ed759424-c73c-4537-bbf3-b0d75e79f920@github.com> References: <4djwVMsduXihrzIr80UhcX2bLbkCe2ofL1gAnyklrr8=.ed759424-c73c-4537-bbf3-b0d75e79f920@github.com> Message-ID: On Wed, 21 Jul 2021 23:51:17 GMT, Clive Verghese wrote: > Updated Benchmarks in Throughput mode Thank you very much for the update. > I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. I guess the garbage collection plays a role here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Thu Jul 22 00:46:47 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 22 Jul 2021 00:46:47 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: <4djwVMsduXihrzIr80UhcX2bLbkCe2ofL1gAnyklrr8=.ed759424-c73c-4537-bbf3-b0d75e79f920@github.com> Message-ID: On Thu, 22 Jul 2021 00:11:56 GMT, Xue-Lei Andrew Fan wrote: >> I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. > I guess the garbage collection plays a role here. Yes, from the JFR profiles it looks like this could be from the GC. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From jwilhelm at openjdk.java.net Thu Jul 22 00:51:37 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:51:37 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 282 commits: - Merge - 8271015: Split cds/SharedBaseAddress.java test into smaller parts Reviewed-by: ccheung, minqi - 8271014: Refactor HeapShared::is_archived_object() Reviewed-by: ccheung, minqi - 8270949: Make dynamically generated classes with the class file version of the current release Reviewed-by: alanb - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" Reviewed-by: kbarrett - 8270991: G1 Full GC always performs heap verification after JDK-8269295 Reviewed-by: iwalulya, kbarrett - 8270820: remove unused stiFileTableIndex from SDE.c Reviewed-by: cjplummer, sspitsyn - 8270147: Increase stride size allowing unrolling more loops Reviewed-by: kvn, iveresov - 8270803: Reduce CDS API verbosity Reviewed-by: minqi, ccheung - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support Reviewed-by: xuelei, rhalade - ... and 272 more: https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb ------------- Changes: https://git.openjdk.java.net/jdk/pull/4863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=01 Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod Patch: https://git.openjdk.java.net/jdk/pull/4863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863 PR: https://git.openjdk.java.net/jdk/pull/4863 From jwilhelm at openjdk.java.net Thu Jul 22 00:51:38 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:51:38 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: c36755de Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7 Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4863 From peter.firmstone at zeus.net.au Thu Jul 22 01:01:39 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 22 Jul 2021 11:01:39 +1000 Subject: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223) In-Reply-To: <9882022f-a1cd-d038-bec8-d11768578569@oracle.com> References: <9882022f-a1cd-d038-bec8-d11768578569@oracle.com> Message-ID: <87626679-be51-c418-ae47-7f5ea0cba384@zeus.net.au> JEP 411 is quite a conundrum for downstream developers that depend on SM. SecurityManager has its problems, but it's the only authorization layer we have. If I had a complaint about SM, it's the implementation of: 1. SocketPermission doesn't allow netmask wild cards. 2. Thread inherited AccessControlContext and Executors. My own implementations are not subject to the issues that the JVM's SM and Policy provider implementations suffer documented in JEP 411. I think if authorization was redesigned from the ground up, Java would have a privileged mode, or privileged call (where permissions are checked) and everything else would be unprivileged, so there is no stack walk required for unpriviledged code, only privileged and it would be very short and not persist across threads. Java has a very large API surface, compared to other languages. It's a difficult decision to stick with Java, I keep looking at the other languages with their smaller API's , I keep wondering if I'm better off in the long term changing to another development language.? OpenJDK has quite rightly identified that the cost of maintaining an authorization layer for Java is too high, given it's vast API surface area, it would be simpler to develop an authorization layer for another language with a smaller API. ? For now I'm trying to stick with Java.? But the reality is, I have until 2030 to transition if I revert to Java 8, and Java 11 gets us through to 2029.? Java has some great new features, but they come at a cost.? Everything is a compromise, and one must select the right compromise. I have a lot of code I've developed in Java and have also invested a lot of time into it.?? It is also likely there will be more deprecation for removal JEP's in future, I mean, someone might come up with the argument we don't require dynamic class loading, because that's for applets.? Dynamic class loading allows loading of untrusted code, so we should only allow trusted code to run that was installed statically by an administrator, because Java is only for Servers now. This is the message I'm getting loud and clear, Java is only for servers in future.?? I'm in the server space, but it's not the server model that OpenJDK developers have in mind.?? This reminds me of the Unix workstation, with Unix retreating to servers then being replaced by Linux. When is Java no longer Java??? Rather than continuing to evolve Java, why not use the JVM to create a new language project, or maybe a CVM (Clojure virtual machine?) which learns from the lessons of Java and let Java continue to be Java? For now at least, I am trying to stick with Java, but it's not a clear decision. It would be an easier decision to make if OpenJDK could provide some hooks where permission checks are currently made, so that we can implement our own authorization layer. Anyway, these are just my personal thoughts and opinions, I do realize that they are probably unwelcome here. Regards, Peter. On 22/07/2021 5:31 am, Sean Mullan wrote: > Hi, > > I am not an expert in JSR 223. However, some JSR 223 implementations > include a mechanism for restricting access to Java classes, for > example Nashorn [1] and Rhino [2], which might be sufficient for your > needs. (Note, Nashorn was deprecated and removed from JDK 15 [3]). I > think most of the permissions you list below can be mapped to a small > list of Java classes that check those permissions. Also, with strong > encapsulation of JDK internals enforced by default in JDK 17 [4], you > get additional protection that is not dependent on the Security Manager. > > What JSR 223 implementation do you use? > > --Sean > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction > [2] > https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/ClassShutter.html > [3] https://openjdk.java.net/jeps/372 > [4] https://openjdk.java.net/jeps/403 > > On 7/21/21 12:35 PM, Alexey Shponarsky wrote: >> Hello, >> >> At Jelastic PaaS, we are using SecurityManager within Java Scripting >> (JSR 223). Specifically, Java Scripting allows us and our customers >> to easily extend the core platform functionality with custom logic. >> The developers can execute their custom scriptlets inside a Java >> Scripting runtime environment with pre-injected core platform API >> methods. For example, >> >> //@req(pathFrom, pathTo) >> >> varmountFrom = "${nodes.build.first.id }", >> >> envName = "${settings.targetEnv}", >> >> mountTo = "cp"; >> >> varresp = jelastic.env.file.RemoveMountPointByGroup(envName, session, >> mountTo, pathTo); >> >> if(resp.result != 0) returnresp; >> >> returnjelastic.env.file.AddMountPointByGroup(envName, session, >> mountTo, pathTo, 'nfs', null, pathFrom, mountFrom, '', false); >> >> As Java Scripting engine / technology provides quite powerful >> runtimes, we have to restrict certains actions such as execution of >> any reflection methods, change of any system environment variables, >> exit, calling some dangerous static methods, reading files outside of >> the sandbox folder, etc. The SecurityManager mechanism provided an >> ability to configure permissions easily. >> >> To achieve this we create an instance of AccessControlContext with >> required permissions and pass it to AccessController.doPrivileged >> method: >> >> //Create list of Permission: >> >> Collection perms= new LinkedList(); >> >> perms.add(new RuntimePermission("createClassLoader")); >> >> perms.add(new RuntimePermission("getClassLoader")); >> >> perms.add(new RuntimePermission("accessDeclaredMembers")); >> >> perms.add(new RuntimePermission("getProtectionDomain")); >> >> perms.add(new PropertyPermission("*", "read")); >> >> perms.add(new SocketPermission("*", "connect,accept,resolve")); >> >> perms.add(new SocketPermission("localhost:0-", >> "connect,accept,resolve,listen")); >> >> //Create AccessControlContext >> >> ProtectionDomain domain = new ProtectionDomain(new CodeSource(null, >> (Certificate[]) null), perms); >> >> AccessControlContext acc= new AccessControlContext(new >> ProtectionDomain[]{domain}); >> >> //Run untrusted code using created AccessControlContext >> >> @Override >> >> public ScriptEvalResponse call() throws Exception { >> >> Object obj = AccessController.doPrivileged(new >> PrivilegedAction() { >> >> @Override >> >> public Object run() { >> >> try { >> >> Object response = compiledScript.eval(ctx); >> >> ScriptEvalResponse evalResponse = new ScriptEvalResponse(Response.OK); >> >> evalResponse.setResponse(response); >> >> return evalResponse; >> >> ???????????} catch (Exception ex) { >> >> logger.debug("Error occurred during eval script:", ex); >> >> return ex; >> >> ???????????} >> >> ???????} >> >> ???}, acc); >> >> if (obj instanceof Exception) { >> >> throw (Exception) obj; >> >> ???} >> >> return (ScriptEvalResponse) obj; >> >> } >> >> How can we implement a similar solution after the removal of >> SecurityManager? Could you help us to find an alternative? >> >> >> >> -- >> Alexey Shponarsky Director of R&D >> Twitter Facebook >> YouTube >> LinkedIn >> Google+ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Thu Jul 22 05:22:49 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 22 Jul 2021 05:22:49 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:58:15 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Move to Immutable map and reduce map lookups src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 858: > 856: private static final Map maps_id; > 857: private static final Map maps_name; > 858: private static final CipherSuite[] ciphers = CipherSuite.values(); Generally, Java follows camel-case syntax for names. It would be good to keep the coding style consistent and use instinctive names. I may use names like "cipherSuiteIds", "cipherSuiteNames" and "cipherSuites" for the above three fields. src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 920: > 918: > 919: static String nameOf(int id) { > 920: String name = maps_id.get(id).name; I guess get() may return null. It may be safe to check the return value of get(): CipherSuite cipherSuite = cipherSuiteIds.get(id); if (cipherSuite != null) { return cipherSuite.name; } src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 931: > 929: static Collection allowedCipherSuites() { > 930: Collection cipherSuites = new LinkedList<>(); > 931: for (CipherSuite cs : ciphers) { I may worthy of a static class field for the allowed cipher suites. src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 945: > 943: static Collection defaultCipherSuites() { > 944: Collection cipherSuites = new LinkedList<>(); > 945: for (CipherSuite cs : ciphers) { I may worthy of a static class field for the default cipher suites. src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 977: > 975: > 976: boolean found = false; > 977: for (CipherSuite cs : ciphers) { If there is a static allowed cipher suite list, the logic here could be simplified to use the allowed cipher suite list. Then, the "ciphers" class filed may be not needed any longer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From akolarkunnu at openjdk.java.net Thu Jul 22 13:01:07 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Thu, 22 Jul 2021 13:01:07 GMT Subject: RFR: 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java [v3] In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 13:24:17 GMT, Abdul Kolarkunnu wrote: >> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps. > > Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision: > > 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java I am trying to fully automate this instead of a manual test, because of some other high priority works I had paused that work, will resume it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/4413 From ascarpino at openjdk.java.net Thu Jul 22 17:22:25 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 17:22:25 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 16 Jul 2021 00:31:43 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 650: > >> 648: int originalOutOfs = 0; >> 649: byte[] in; >> 650: byte[] out; > > The name "in", "out" are almost used in all calls, it's hard to tell when these two are actually used. Can we rename them to make them more unique? ok ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Thu Jul 22 17:22:24 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 17:22:24 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Tue, 20 Jul 2021 22:36:28 GMT, Valerie Peng wrote: >> Initializing op in abstract GCMEngine would mean another 'if(encryption)', when that would not be needed in the GCMEncrypt() or GCMDecrypt(). I don't see why that is clearer. >> >> GaloisCounterMode.implGCMCrypt(...) is the intrinsic, so I have to use what is used by hotspot. > > Seems strange to have GCMOperation op defined in GCMEngine but not initialized, nor used. The methods in GCMEngine which use op has an argument named op anyway. Either you just use the "op" field (remove the "op" argument) or the "op" argument (move the op field to GCMEncrypt/GCMDecrypt class). Having both looks confusing. Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From rhalade at openjdk.java.net Thu Jul 22 17:36:50 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 22 Jul 2021 17:36:50 GMT Subject: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Message-ID: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. ------------- Commit messages: - 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Changes: https://git.openjdk.java.net/jdk/pull/4877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4877&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270280 Stats: 29 lines in 2 files changed: 0 ins; 4 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4877/head:pull/4877 PR: https://git.openjdk.java.net/jdk/pull/4877 From ascarpino at openjdk.java.net Thu Jul 22 17:51:07 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 17:51:07 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: <4PCHgWxJmLLQYJvoVAjaRvD97KUwd5z5wE3czxfiKg8=.c1a12cda-bb95-4597-9078-c17cd71edadb@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <4PCHgWxJmLLQYJvoVAjaRvD97KUwd5z5wE3czxfiKg8=.c1a12cda-bb95-4597-9078-c17cd71edadb@github.com> Message-ID: <0WMPRxRKCdPaYY8hsB9VqEXtk41YrUMPhWhxmgJGlno=.e811e3dd-ddf5-4f7f-b8e1-54b22a08d8a1@github.com> On Mon, 19 Jul 2021 19:22:53 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 729: > >> 727: >> 728: if (src.hasArray() && dst.hasArray()) { >> 729: int l = rlen; > > Remove this "l" variable since it's not used? The code needs some reorganizing ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Thu Jul 22 18:00:21 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 18:00:21 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Mon, 19 Jul 2021 19:35:16 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 761: > >> 759: } >> 760: >> 761: dst.put(out, 0, rlen); > > This looks belong to the above if-block? I wonder how this have not affected the operation to fail. Perhaps the existing regression tests did not cover the 'rlen < blockSize' case. If the code in the above if-block is not run, this outsize dst.put(...) call would put extra output bytes into the output buffer. Yes... this one and the ct offset problem earlier I would have expected the regression test it pick the mistake. There should be tests that catch this.. I'm not sure what's up. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From rhalade at openjdk.java.net Thu Jul 22 18:17:25 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 22 Jul 2021 18:17:25 GMT Subject: RFR: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Message-ID: Test certificates are updated for now. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. ------------- Commit messages: - 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Changes: https://git.openjdk.java.net/jdk/pull/4878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4878&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243543 Stats: 246 lines in 2 files changed: 49 ins; 7 del; 190 mod Patch: https://git.openjdk.java.net/jdk/pull/4878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4878/head:pull/4878 PR: https://git.openjdk.java.net/jdk/pull/4878 From ascarpino at openjdk.java.net Thu Jul 22 18:34:11 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 18:34:11 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Tue, 20 Jul 2021 01:35:04 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 762: > >> 760: >> 761: dst.put(out, 0, rlen); >> 762: processed += srcLen; > > It seems that callers of this implGCMCrypt() method such as GCMEngine.doLastBlock() adds the returned value to the "processed" field which looks like double counting? However, some caller such as GCMEncrypt.doUpdate() does not. Seems inconsistent and may lead to wrong value for the "processed" field? All the callers that use GCMOperations, ie op.update(...), have the processed value updated. implGCMCrypt() calls op.update() and updates the value. It cannot double count 'processed' is not updated after implGCMCrypt(). I can see your point, but the other methods do not have access to 'processed' and would mean I copy that line 3 times elsewhere. I'd rather keep it as is ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From cverghese at openjdk.java.net Thu Jul 22 18:37:53 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 22 Jul 2021 18:37:53 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v3] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add allowed and default lists ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/aec4f54c..c0a21c5d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=01-02 Stats: 57 lines in 1 file changed: 12 ins; 26 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Thu Jul 22 18:37:55 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 22 Jul 2021 18:37:55 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite In-Reply-To: References: <4djwVMsduXihrzIr80UhcX2bLbkCe2ofL1gAnyklrr8=.ed759424-c73c-4537-bbf3-b0d75e79f920@github.com> Message-ID: On Thu, 22 Jul 2021 00:11:56 GMT, Xue-Lei Andrew Fan wrote: >> Updated Benchmarks in Throughput mode >> >> ### Current >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 8050.787 ? 232.335 ops/ms >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 8165.124 ? 283.718 ops/ms >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 7827.758 ? 293.311 ops/ms >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 7768.286 ? 181.399 ops/ms >> >> >> ### ArrayList >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 100.626 ? 0.294 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 32.793 ? 0.804 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 21.162 ? 0.217 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 18.220 ? 0.903 ops/us >> >> >> ### Hashmap >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 thrpt 25 63.836 ? 4.517 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 thrpt 25 69.983 ? 8.965 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 thrpt 25 68.091 ? 7.404 ops/us >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA thrpt 25 52.831 ? 4.317 ops/us >> >> >> I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. > >> Updated Benchmarks in Throughput mode > > Thank you very much for the update. > >> I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. > > I guess the garbage collection plays a role here. Hi @XueleiFan, Thank you for the feedback. I have update the pull requests addressing your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From ascarpino at openjdk.java.net Thu Jul 22 18:39:14 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 18:39:14 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> Message-ID: On Mon, 19 Jul 2021 23:41:49 GMT, Valerie Peng wrote: >> If decryption fails with a bad auth tag, the in is not overwritten because it's in-place. Encryption is not needed because there is nothing to check. I can add a comment. > > Hmm ok, so if it's not decryption in-place, then output buffer would still be zero'ed when the auth tag failed, but this is ok? This is able in-place, not about two separate buffers.. zeroing happens somewhere else for all decryption bad buffers ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From cverghese at openjdk.java.net Thu Jul 22 19:01:02 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 22 Jul 2021 19:01:02 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v4] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add blank space before and after the for loop ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/c0a21c5d..158714cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From xuelei at openjdk.java.net Thu Jul 22 19:01:03 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 22 Jul 2021 19:01:03 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 18:37:53 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Add allowed and default lists Looks good to me. Thank you! src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 866: > 864: List allowedCS = new ArrayList<>(); > 865: List defaultCS = new ArrayList<>(); > 866: for(CipherSuite cs : CipherSuite.values()) { I may add blank lines before and after the for-loop block. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Thu Jul 22 19:01:05 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 22 Jul 2021 19:01:05 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 18:50:08 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Add allowed and default lists > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 866: > >> 864: List allowedCS = new ArrayList<>(); >> 865: List defaultCS = new ArrayList<>(); >> 866: for(CipherSuite cs : CipherSuite.values()) { > > I may add blank lines before and after the for-loop block. Than you @XueleiFan for approving the PR. I have added the black lines before and after the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From ascarpino at openjdk.java.net Thu Jul 22 19:18:08 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 19:18:08 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: <3X43XyHHzWOWHvKNMoblGEQpvOBIB5cudVpXZl2yIH8=.4e382ef3-90c8-4749-8768-12470d98e9ab@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <3X43XyHHzWOWHvKNMoblGEQpvOBIB5cudVpXZl2yIH8=.4e382ef3-90c8-4749-8768-12470d98e9ab@github.com> Message-ID: On Fri, 16 Jul 2021 00:09:37 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 611: > >> 609: outOfs + len); >> 610: ghash.update(ct, ctOfs, segments); >> 611: ctOfs = len; > > This does not look right when the initial value of ctOfs != 0. Yeah that doesn't look right ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From alexey.shponarsky at jelastic.com Wed Jul 21 17:54:00 2021 From: alexey.shponarsky at jelastic.com (Alexey Shponarsky) Date: Wed, 21 Jul 2021 20:54:00 +0300 Subject: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223) In-Reply-To: <9882022f-a1cd-d038-bec8-d11768578569@oracle.com> References: <9882022f-a1cd-d038-bec8-d11768578569@oracle.com> Message-ID: Hi Sean, We are using Rhino 1.7.12 On Wed, Jul 21, 2021 at 10:31 PM Sean Mullan wrote: > Hi, > > I am not an expert in JSR 223. However, some JSR 223 implementations > include a mechanism for restricting access to Java classes, for example > Nashorn [1] and Rhino [2], which might be sufficient for your needs. (Note, > Nashorn was deprecated and removed from JDK 15 [3]). I think most of the > permissions you list below can be mapped to a small list of Java classes > that check those permissions. Also, with strong encapsulation of JDK > internals enforced by default in JDK 17 [4], you get additional protection > that is not dependent on the Security Manager. > > What JSR 223 implementation do you use? > > --Sean > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction > [2] > https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/ClassShutter.html > [3] https://openjdk.java.net/jeps/372 > [4] https://openjdk.java.net/jeps/403 > > On 7/21/21 12:35 PM, Alexey Shponarsky wrote: > > Hello, > > At Jelastic PaaS, we are using SecurityManager within Java Scripting (JSR > 223). Specifically, Java Scripting allows us and our customers to easily > extend the core platform functionality with custom logic. The developers > can execute their custom scriptlets inside a Java Scripting runtime > environment with pre-injected core platform API methods. For example, > > > > //@req(pathFrom, pathTo) > > var mountFrom = "${nodes.build.first.id}", > > envName = "${settings.targetEnv}", > > mountTo = "cp"; > > var resp = jelastic.env.file.RemoveMountPointByGroup(envName, session, > mountTo, pathTo); > > if (resp.result != 0) return resp; > > return jelastic.env.file.AddMountPointByGroup(envName, session, mountTo, > pathTo, 'nfs', null, pathFrom, mountFrom, '', false); > > > > As Java Scripting engine / technology provides quite powerful runtimes, we > have to restrict certains actions such as execution of any reflection > methods, change of any system environment variables, exit, calling some > dangerous static methods, reading files outside of the sandbox folder, etc. > The SecurityManager mechanism provided an ability to configure permissions > easily. > > > > To achieve this we create an instance of AccessControlContext with > required permissions and pass it to AccessController.doPrivileged > > method: > > > > //Create list of Permission: > > Collection perms = new LinkedList(); > > perms.add(new RuntimePermission("createClassLoader")); > > perms.add(new RuntimePermission("getClassLoader")); > > perms.add(new RuntimePermission("accessDeclaredMembers")); > > perms.add(new RuntimePermission("getProtectionDomain")); > > perms.add(new PropertyPermission("*", "read")); > > perms.add(new SocketPermission("*", "connect,accept,resolve")); > > perms.add(new SocketPermission("localhost:0-", > "connect,accept,resolve,listen")); > > > > > > //Create AccessControlContext > > ProtectionDomain domain = new ProtectionDomain(new CodeSource(null, ( > Certificate[]) null), perms); > > AccessControlContext acc = new AccessControlContext(new > ProtectionDomain[]{domain}); > > > > //Run untrusted code using created AccessControlContext > > @Override > > public ScriptEvalResponse call() throws Exception { > > Object obj = AccessController.doPrivileged(new PrivilegedAction() > { > > > > @Override > > public Object run() { > > try { > > Object response = compiledScript.eval(ctx); > > ScriptEvalResponse evalResponse = new ScriptEvalResponse( > Response.OK); > > evalResponse.setResponse(response); > > return evalResponse; > > } catch (Exception ex) { > > logger.debug("Error occurred during eval script:", ex); > > return ex; > > } > > } > > }, acc); > > if (obj instanceof Exception) { > > throw (Exception) obj; > > } > > return (ScriptEvalResponse) obj; > > } > > > > > > How can we implement a similar solution after the removal of > SecurityManager? Could you help us to find an alternative? > > > -- > Alexey Shponarsky Director of R&D > Twitter Facebook > YouTube > LinkedIn > Google+ > > > > -- Alexey Shponarsky Director of R&D Twitter Facebook YouTube LinkedIn Google+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Thu Jul 22 22:44:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 22 Jul 2021 22:44:07 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> Message-ID: On Thu, 22 Jul 2021 18:36:16 GMT, Anthony Scarpino wrote: >> Hmm ok, so if it's not decryption in-place, then output buffer would still be zero'ed when the auth tag failed, but this is ok? > > This is able in-place, not about two separate buffers.. zeroing happens somewhere else for all decryption bad buffers Yes, I know. Basically, we are trying to optimize performance by trying to write into the supplied buffers (out) as much as we can. But then when tag verification failed, the "written" bytes are erased w/ 0. Ideal case would be not to touch the output buffer until after the tag verification succeeds. Isn't this the previous approach? Verify the tag first and then write out the plain text afterwards. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From ascarpino at openjdk.java.net Thu Jul 22 22:55:09 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 22 Jul 2021 22:55:09 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> Message-ID: On Thu, 22 Jul 2021 22:41:03 GMT, Valerie Peng wrote: >> This is able in-place, not about two separate buffers.. zeroing happens somewhere else for all decryption bad buffers > > Yes, I know. Basically, we are trying to optimize performance by trying to write into the supplied buffers (out) as much as we can. But then when tag verification failed, the "written" bytes are erased w/ 0. Ideal case would be not to touch the output buffer until after the tag verification succeeds. Isn't this the previous approach? Verify the tag first and then write out the plain text afterwards. With this new intrinsic doing both ghash and gctr at the same time, I cannot do the that ghash check first before the gctr op. I wish I could ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From github.com+30433125+djelinski at openjdk.java.net Fri Jul 23 05:56:04 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Fri, 23 Jul 2021 05:56:04 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:01:02 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Add blank space before and after the for loop Marked as reviewed by djelinski at github.com (no known OpenJDK username). src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 971: > 969: > 970: boolean found = false; > 971: for (CipherSuite cs : allowedCipherSuites) { We can avoid this loop; look up the cipher by name first (`cs = nameOf(name)`), then check for supported protocols. Other than that, LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From peter.firmstone at zeus.net.au Fri Jul 23 08:36:05 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Jul 2021 18:36:05 +1000 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. Message-ID: Post JEP 411, we need to write Agents to replace the current permission checks performed within the JVM by instrumenting it, following advice by OpenJDK developers, however for us this goes against all our previous development practices, no part of our codebase accesses any JDK implementation classes or internal api's. We also don't release anything that depends on deprecated API's. Modules didn't break our code, neither has tightening rules around access in JEP 403. We have been advised that we need to instrument the JDK with Agent's by OpenJDK. I am now ready to write these Agents, so that I can begin testing my new authorization layer for Java: https://github.com/pfirmstone/HighPerformanceSecurity As an example, we need to instrument java.lang.ClassLoader, in this case we need to instrument the following method: private static Void checkCreateClassLoader(String name);?? This check must be performed prior to calling java.lang.Object's constructor, to throw an exception, without making ClassLoader susceptible to a finalizer attack. Accessing private internal methods goes against all our current development practices, these are at risk of breaking in future. We cannot add methods with Agent's only change method contents. I am requesting hooks, in the form of an annotation, such as the following, so that OpenJDK developers know that this method will be instrumented by Agent's and not to change it's signature. @Instrumented private static Void checkCreateClassLoader(String name); If OpenJDK will provide instrumentation hooks, then this is a workable solution for us. Or is OpenJDK encouraging us to start accessing private methods and have to test each Java release for breakages? I'm wondering what the point of JEP 403 is if, our solution to JEP 411, is to start instrumenting private methods??? I don't think this is what OpenJDK developers are proposing. Currently removing SM will allow an attacker to cause our software running on the JVM to parse untrusted data, which previously required an authenticated client?? Permission is only granted to Principal's, of course post JEP 411, these checks will stop working in future, making our software vulnerable to attacks by unauthenticated users. We're still up in the air about how to provide credentials for our TLS and Kerberos connections, for authentication, I've created support for obtaining the Subject from the Authorization context, in my authorization layer software (linked above), but instrumenting private methods in the JDK goes against all previously learned best practices. -- Regards, Peter Firmstone Code snippet from java.lang.ClassLoader: if (name != null && name.isEmpty()) { throw new IllegalArgumentException("name must be non-empty or null"); } @SuppressWarnings("removal") SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkCreateClassLoader(); } return null; } private ClassLoader(Void unused, String name, ClassLoader parent) { this.name = name; this.parent = parent; this.unnamedModule = new Module(this); if (ParallelLoaders.isRegistered(this.getClass())) { parallelLockMap = new ConcurrentHashMap<>(); assertionLock = new Object(); } else { // no finer-grained lock; lock on the classloader instance parallelLockMap = null; assertionLock = this; } this.package2certs = new ConcurrentHashMap<>(); this.nameAndId = nameAndId(this); } /** * If the defining loader has a name explicitly set then * '' @ * If the defining loader has no name then * @ * If it's built-in loader then omit `@` as there is only one instance. */ private static String nameAndId(ClassLoader ld) { String nid = ld.getName() != null ? "\'" + ld.getName() + "\'" : ld.getClass().getName(); if (!(ld instanceof BuiltinClassLoader)) { String id = Integer.toHexString(System.identityHashCode(ld)); nid = nid + " @" + id; } return nid; } /** * Creates a new class loader of the specified name and using the * specified parent class loader for delegation. * * @apiNote If the parent is specified as {@codenull} (for the * bootstrap class loader) then there is no guarantee that all platform * classes are visible. * * @param name class loader name; or {@codenull} if not named * @param parent the parent class loader * * @throws IllegalArgumentException if the given name is empty. * * @throws SecurityException * If a security manager exists and its * {@link SecurityManager#checkCreateClassLoader()} * method doesn't allow creation of a new class loader. * * @since 9 */ protected ClassLoader(String name, ClassLoader parent) { this(checkCreateClassLoader(name), name, parent); } private static Void checkCreateClassLoader(String name) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Fri Jul 23 10:48:35 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Jul 2021 20:48:35 +1000 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: Message-ID: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> Perhaps the solution is to replace the entire class, instead of instrumenting one method? Compile a patched copy of the JVM, with modified class files, then replace the existing classes in the JVM with the modified classes? Kinda like maintaining a fork, but using Agents to instrument the original JVM with classes from the fork? I sure wish there was a better option, if anyone knows one, I'm all ears. Regards, Peter. On 23/07/2021 6:36 pm, Peter Firmstone wrote: > Post JEP 411, we need to write Agents to replace the current > permission checks performed within the JVM by instrumenting it, > following advice by OpenJDK developers, however for us this goes > against all our previous development practices, no part of our > codebase accesses any JDK implementation classes or internal api's.? > We also don't release anything that depends on deprecated API's.? > Modules didn't break our code, neither has tightening rules around > access in JEP 403. > > We have been advised that we need to instrument the JDK with Agent's > by OpenJDK. > > I am now ready to write these Agents, so that I can begin testing my > new authorization layer for Java: > https://github.com/pfirmstone/HighPerformanceSecurity > > As an example, we need to instrument java.lang.ClassLoader, in this > case we need to instrument the following method: > > private static Void checkCreateClassLoader(String name);?? This check > must be performed prior to calling java.lang.Object's constructor, to > throw an exception, without making ClassLoader susceptible to a > finalizer attack. > > Accessing private internal methods goes against all our current > development practices, these are at risk of breaking in future. > > We cannot add methods with Agent's only change method contents. > > I am requesting hooks, in the form of an annotation, such as the > following, so that OpenJDK developers know that this method will be > instrumented by Agent's and not to change it's signature. > > @Instrumented > > private static Void checkCreateClassLoader(String name); > > If OpenJDK will provide instrumentation hooks, then this is a workable > solution for us. > > Or is OpenJDK encouraging us to start accessing private methods and > have to test each Java release for breakages? > > I'm wondering what the point of JEP 403 is if, our solution to JEP > 411, is to start instrumenting private methods??? I don't think this > is what OpenJDK developers are proposing. > > Currently removing SM will allow an attacker to cause our software > running on the JVM to parse untrusted data, which previously required > an authenticated client?? Permission is only granted to Principal's, > of course post JEP 411, these checks will stop working in future, > making our software vulnerable to attacks by unauthenticated users. > > We're still up in the air about how to provide credentials for our TLS > and Kerberos connections, for authentication, I've created support for > obtaining the Subject from the Authorization context, in my > authorization layer software (linked above), but instrumenting private > methods in the JDK goes against all previously learned best practices. > > -- > Regards, > > Peter Firmstone > > Code snippet from java.lang.ClassLoader: > > if (name != null && name.isEmpty()) { > > throw new IllegalArgumentException("name must be non-empty or null"); > > } > > > @SuppressWarnings("removal") > > SecurityManager security = System.getSecurityManager(); > > if (security != null) { > > security.checkCreateClassLoader(); > > } > > return null; > > } > > > private ClassLoader(Void unused, String name, ClassLoader parent) { > > this.name = name; > > this.parent = parent; > > this.unnamedModule = new Module(this); > > if (ParallelLoaders.isRegistered(this.getClass())) { > > parallelLockMap = new ConcurrentHashMap<>(); > > assertionLock = new Object(); > > } else { > > // no finer-grained lock; lock on the classloader instance > > parallelLockMap = null; > > assertionLock = this; > > } > > this.package2certs = new ConcurrentHashMap<>(); > > this.nameAndId = nameAndId(this); > > } > > > /** > > * If the defining loader has a name explicitly set then > > * '' @ > > * If the defining loader has no name then > > * @ > > * If it's built-in loader then omit `@` as there is only one > instance. > > */ > > private static String nameAndId(ClassLoader ld) { > > String nid = ld.getName() != null ? "\'" + ld.getName() + "\'" > > : ld.getClass().getName(); > > if (!(ld instanceof BuiltinClassLoader)) { > > String id = Integer.toHexString(System.identityHashCode(ld)); > > nid = nid + " @" + id; > > } > > return nid; > > } > > > /** > > * Creates a new class loader of the specified name and using the > > * specified parent class loader for delegation. > > * > > * @apiNote If the parent is specified as {@codenull} (for the > > * bootstrap class loader) then there is no guarantee that all platform > > * classes are visible. > > * > > * @param name class loader name; or {@codenull} if not named > > * @param parent the parent class loader > > * > > * @throws IllegalArgumentException if the given name is empty. > > * > > * @throws SecurityException > > * If a security manager exists and its > > * {@link SecurityManager#checkCreateClassLoader()} > > * method doesn't allow creation of a new class loader. > > * > > * @since 9 > > */ > > protected ClassLoader(String name, ClassLoader parent) { > > this(checkCreateClassLoader(name), name, parent); > > } > private static Void checkCreateClassLoader(String name) { > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abakhtin at openjdk.java.net Fri Jul 23 11:38:21 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 23 Jul 2021 11:38:21 GMT Subject: RFR: 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key Message-ID: Hello, Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. If not applied, implementation can try to select signer from other providers Regards Alexey ------------- Commit messages: - Fixed formatting - 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key Changes: https://git.openjdk.java.net/jdk/pull/4887/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4887&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271199 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4887/head:pull/4887 PR: https://git.openjdk.java.net/jdk/pull/4887 From Alan.Bateman at oracle.com Fri Jul 23 11:45:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Jul 2021 12:45:32 +0100 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> Message-ID: <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> On 23/07/2021 11:48, Peter Firmstone wrote: > > Perhaps the solution is to replace the entire class, instead of > instrumenting one method? > > Compile a patched copy of the JVM, with modified class files, then > replace the existing classes in the JVM with the modified classes? > > Kinda like maintaining a fork, but using Agents to instrument the > original JVM with classes from the fork? > > I sure wish there was a better option, if anyone knows one, I'm all ears. JEP 411 puts the JDK on the road to dropping support for sandboxing. This means there won't be a built-in means to securely run code that has malicious intent. It means that many of the concerns for finalizer attacks go away too. In the case of the ClassLoader example in your first mail then it may be that the private static method that you want to instrument will be removed. If removed, then it should make the instrumentation a bit easier so that you can instrument the protected constructors to invokestatic your equivalent of a permission check before the invokespecial. So I think this specific case is surmountable but in general I don't think it will be tenable to patch hundreds of classes and be confident that you've got everything, esp. with a moving code base and new features. I can't tell if your "authorization layer" is for use when running with code that has malicious intent. If it is, then I don't think it will be tenable to duplicate all the deeply invasive permission checks that exist today and keep it up to date as new features and changes. When agents were muted in the early discussion on JEP 411 then the context was file and network access where several people were interested in having a means to veto access. Expanding this to have a SM equivalent be able to veto every reflective access, prevent trusted method chain and other attacks, amounts to keeping the SM forever. As regards the comments about agents having the power to instrument methods that aren't accessible to user code then that is normal. Java agents are for tools to do powerful things, they aren't intended for libraries for applications to use directly. This is why agents are opt-in on the command line. Agent maintainers weld great power and must take care to never leak the Instrumentation object to applications or libraries. -Alan From peter.firmstone at zeus.net.au Fri Jul 23 12:35:36 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Jul 2021 22:35:36 +1000 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> Message-ID: <5bf6544f-103d-a232-c6da-d16c13a25eaf@zeus.net.au> Trusted code only, but it's intended to be run in a locked down principle of least privilege environment, while we perform static analysis and targeted review, we don't have the resources required to perform thorough trusted code audits, so have been reliant on the principle of least privilege.? Hence the ability to generate policy files that we use for auditing. I utilize the constructor guarantee added in Java 6, that prevents finalizer attacks for atomic de-serialization, if invariants aren't satisfied, failure is atomic, thanks to this feature. We use the SM to ensure network connections used are secure and only have authenticated users, otherwise de-serialization and dynamic class loading is prevented. We don't need all the SM permission check features, but preventing unauthorized class loading is one of them.?? Network, file access, class loading, properties are a few that come to mind, I'm not worried about reflection, other recent changes are taking care of reflective access. We have a heap of our own Permission implementations as well. It appears that Java's future path is diverging from our software's needs and Java won't be a suitable platform in future. I wasn't aware that Java was heading in this direction.?? JEP 411 came as a big surprise, it just seemed like it was a core Java feature. I think the best course of action, will be to focus on Java 8, until that's EOL'd.?? I do like the improvements to TLS stateless connections and new features in later Java versions, but it looks like a mistake to try and keep up with Java, with this new knowledge.? I think I'll back out some more recent changes that were intended to allow our software to run on Java 17, as these cause breakages for downstream developers and it doesn't seem to make much sense now, to make those breaking changes.? I was actually looking forward to taking advantage of loom and the new vector API, but it looks like I need to be focused on what's going to be our next software platform.? I've always found llvm to be interesting, so maybe I'll focus on some languages that run on that, and implement privileged constraints at a lower level. Perhaps by the time Java 8's EOL'd there will be a new platform and language that's more suitable. Thank you for your time, I do appreciate your replies and it gives me the clarity I needed. I wish it wasn't the case, but I have to accept that times are changing. Best of luck for the future my Java friends, it's been a powerful language, especially with regard to concurrency and scaling, we got great performance, all our hotspots were native methods and Java let us get close to the metal at low levels as well using bit shift operations on primitives, that are magnitudes faster than standard string operations.?? TLS ran so much faster with stateless session tickets too. Regards, Peter. On 23/07/2021 9:45 pm, Alan Bateman wrote: > On 23/07/2021 11:48, Peter Firmstone wrote: >> >> Perhaps the solution is to replace the entire class, instead of >> instrumenting one method? >> >> Compile a patched copy of the JVM, with modified class files, then >> replace the existing classes in the JVM with the modified classes? >> >> Kinda like maintaining a fork, but using Agents to instrument the >> original JVM with classes from the fork? >> >> I sure wish there was a better option, if anyone knows one, I'm all >> ears. > > JEP 411 puts the JDK on the road to dropping support for sandboxing. > This means there won't be a built-in means to securely run code that > has malicious intent. It means that many of the concerns for finalizer > attacks go away too. In the case of the ClassLoader example in your > first mail then it may be that the private static method that you want > to instrument will be removed. If removed, then it should make the > instrumentation a bit easier so that you can instrument the protected > constructors to invokestatic your equivalent of a permission check > before the invokespecial. So I think this specific case is > surmountable but in general I don't think it will be tenable to patch > hundreds of classes and be confident that you've got everything, esp. > with a moving code base and new features. I can't tell if your > "authorization layer" is for use when running with code that has > malicious intent. If it is, then I don't think it will be tenable to > duplicate all the deeply invasive permission checks that exist today > and keep it up to date as new features and changes. When agents were > muted in the early discussion on JEP 411 then the context was file and > network access where several people were interested in having a means > to veto access. Expanding this to have a SM equivalent be able to veto > every reflective access, prevent trusted method chain and other > attacks, amounts to keeping the SM forever. > > As regards the comments about agents having the power to instrument > methods that aren't accessible to user code then that is normal. Java > agents are for tools to do powerful things, they aren't intended for > libraries for applications to use directly. This is why agents are > opt-in on the command line. Agent maintainers weld great power and > must take care to never leak the Instrumentation object to > applications or libraries. > > -Alan From mullan at openjdk.java.net Fri Jul 23 13:01:03 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 23 Jul 2021 13:01:03 GMT Subject: RFR: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 18:07:42 GMT, Rajan Halade wrote: > Test certificates are updated for now. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4878 From mullan at openjdk.java.net Fri Jul 23 13:21:01 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 23 Jul 2021 13:21:01 GMT Subject: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error In-Reply-To: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> References: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> Message-ID: On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote: > I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. > > CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. Have you thought about using a cached OCSPResponse to avoid the expiration issues? You would not be testing a live OCSP network request/response, but it might be an acceptable workaround for cases like this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4877 From rhalade at openjdk.java.net Fri Jul 23 14:22:10 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 23 Jul 2021 14:22:10 GMT Subject: Integrated: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 18:07:42 GMT, Rajan Halade wrote: > Test certificates are updated for now. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. This pull request has now been integrated. Changeset: 45abbeed Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/45abbeed2f4f2899a3c1595b0cd8e573990a16fa Stats: 246 lines in 2 files changed: 49 ins; 7 del; 190 mod 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4878 From rhalade at openjdk.java.net Fri Jul 23 14:48:04 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 23 Jul 2021 14:48:04 GMT Subject: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error In-Reply-To: References: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> Message-ID: On Fri, 23 Jul 2021 13:18:16 GMT, Sean Mullan wrote: > Have you thought about using a cached OCSPResponse to avoid the expiration issues? You would not be testing a live OCSP network request/response, but it might be an acceptable workaround for cases like this. For OCSP, it is possible to do backdated query and we do this when needed. The problem is some OCSP servers return UNAUTHORIZED error code after certificate expiry. We also need to update these certificates after expiry for CRL check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4877 From mullan at openjdk.java.net Fri Jul 23 15:07:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 23 Jul 2021 15:07:09 GMT Subject: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error In-Reply-To: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> References: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> Message-ID: On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote: > I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. > > CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. Marked as reviewed by mullan (Reviewer). But you could cache the OCSPResponse now while the certificate is not expired, and use that in the test by calling `PKIXRevocationChecker.setOcspResponses()`. For CRLs, you could also do something similar by caching the CRL and storing it in `CollectionCertStore` and adding that to `PKIXParameters`. Just some ideas to avoid having to continuously update the test certificates every 3 months. I can approve this now, but can you file a follow-on issue to look into this some more? ------------- PR: https://git.openjdk.java.net/jdk/pull/4877 From rhalade at openjdk.java.net Fri Jul 23 15:07:09 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 23 Jul 2021 15:07:09 GMT Subject: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error In-Reply-To: References: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> Message-ID: On Fri, 23 Jul 2021 15:00:44 GMT, Sean Mullan wrote: > But you could cache the OCSPResponse now while the certificate is not expired, and use that in the test by calling `PKIXRevocationChecker.setOcspResponses()`. For CRLs, you could also do something similar by caching the CRL and storing it in `CollectionCertStore` and adding that to `PKIXParameters`. Just some ideas to avoid having to continuously update the test certificates every 3 months. > > I can approve this now, but can you file a follow-on issue to look into this some more? Sure. I will investigate this along with idea of using TLS connection to test websites. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4877 From rhalade at openjdk.java.net Fri Jul 23 15:07:10 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 23 Jul 2021 15:07:10 GMT Subject: Integrated: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error In-Reply-To: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> References: <2TcTBrV6vQseTta5oBXZNGbKAvQUfaDOFvyKiJmXXWg=.d437621c-6845-4ed5-b8d7-8f0a46a81b67@github.com> Message-ID: On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote: > I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. > > CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. This pull request has now been integrated. Changeset: f4b3ee5d Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/f4b3ee5dca8cfdc2fbb8ee64a1e8cdb8894b0061 Stats: 29 lines in 2 files changed: 0 ins; 4 del; 25 mod 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4877 From alanb at openjdk.java.net Fri Jul 23 15:30:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 23 Jul 2021 15:30:07 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com> References: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com> Message-ID: <7ss8rAI-Yo8YnSkBEGOBYesUG72udl_Ie6zMvDCXQ4s=.acd0986b-b2c3-4caa-968b-b4f2068cf860@github.com> On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > The change to `PKCS7::verify(byte[])` looks fine. @seanjmullan Are you planning to sponsor this? ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From cverghese at openjdk.java.net Fri Jul 23 16:52:42 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 23 Jul 2021 16:52:42 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 05:52:25 GMT, djelinski wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Add blank space before and after the for loop > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 971: > >> 969: >> 970: boolean found = false; >> 971: for (CipherSuite cs : allowedCipherSuites) { > > We can avoid this loop; look up the cipher by name first (`cs = nameOf(name)`), then check for supported protocols. > Other than that, LGTM. Thank you for the feedback. I have updated the loop accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Fri Jul 23 16:52:38 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 23 Jul 2021 16:52:38 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v5] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Remove for loop from validValuesOf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/158714cf..39b78e65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From mullan at openjdk.java.net Fri Jul 23 17:06:06 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 23 Jul 2021 17:06:06 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com> References: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com> Message-ID: <2Snt76xMeYT8vZi0EmdlB-KaaopCmWV-zSU8qy-_Tzk=.deccb518-b7e2-49d3-a489-7db9c230f0a6@github.com> On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > The change to `PKCS7::verify(byte[])` looks fine. > @seanjmullan Are you planning to sponsor this? Yes, I can do that, but I will wait until Monday in case there are any post-integration issues that I need to follow up on. ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From cverghese at openjdk.java.net Fri Jul 23 17:11:30 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 23 Jul 2021 17:11:30 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v6] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Fix line length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/39b78e65..6e75c829 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From xuelei at openjdk.java.net Fri Jul 23 17:11:32 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 23 Jul 2021 17:11:32 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:52:38 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Remove for loop from validValuesOf src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 972: > 970: boolean found = false; > 971: CipherSuite cs; > 972: if ((cs = cipherSuiteNames.get(name)) != null && !cs.supportedProtocols.isEmpty()) { Nice update! I appreciate if you could avoid lines longer than 80 characters, since they?re not handled well by many terminals and tools (See [Java Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html)). ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Fri Jul 23 17:11:33 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 23 Jul 2021 17:11:33 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 17:05:58 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove for loop from validValuesOf > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 972: > >> 970: boolean found = false; >> 971: CipherSuite cs; >> 972: if ((cs = cipherSuiteNames.get(name)) != null && !cs.supportedProtocols.isEmpty()) { > > Nice update! I appreciate if you could avoid lines longer than 80 characters, since they?re not handled well by many terminals and tools (See [Java Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html)). Thank you @XueleiFan, Updated the length of the line. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From mullan at openjdk.java.net Fri Jul 23 17:26:19 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 23 Jul 2021 17:26:19 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String Message-ID: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. ------------- Commit messages: - Regression test for JDK-8270946. - 8270946: X509CertImpl.getFingerprint should not return the empty String Changes: https://git.openjdk.java.net/jdk/pull/4891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270946 Stats: 225 lines in 6 files changed: 186 ins; 13 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/4891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4891/head:pull/4891 PR: https://git.openjdk.java.net/jdk/pull/4891 From simonis at openjdk.java.net Fri Jul 23 17:35:10 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 23 Jul 2021 17:35:10 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v6] In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 17:11:30 GMT, Clive Verghese wrote: >> ### Benchmark results >> >> I have benchmarked 3 cases. >> >> 1. The current situation. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op >> >> >> 2. Use `static final array` instead of calling `CipherSuite.values` each time. >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op >> >> >> 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) >> >> Benchmark (cipherSuite) Mode Cnt Score Error Units >> CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op >> CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op >> >> >> I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Fix line length This change looks good to me except the vary minor fact that the test has no newline at the end of the file. I wonder why jcheck hasn't caught this issue. If I remember right it did it in the old Mercurial version. I'd appreciate if you could fix that as well before integrating (and no need for a new review from my side). I'll sponsor the change one you integrate. Thanks for this nice improvement! ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4783 From cverghese at openjdk.java.net Fri Jul 23 17:39:44 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 23 Jul 2021 17:39:44 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v7] In-Reply-To: References: Message-ID: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Add new line in end of CipherSuiteBench ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4783/files - new: https://git.openjdk.java.net/jdk/pull/4783/files/6e75c829..b0375b25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4783&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783 PR: https://git.openjdk.java.net/jdk/pull/4783 From xuelei at openjdk.java.net Fri Jul 23 17:49:03 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 23 Jul 2021 17:49:03 GMT Subject: RFR: 8270317: Large Allocation in CipherSuite [v5] In-Reply-To: References: Message-ID: <_bJvpnpIz0OkHY6q0f02rPGwwIHd57Sa2zZRNr-I3x8=.4989e596-1af8-4917-bd0c-7f48203d2113@github.com> On Fri, 23 Jul 2021 17:08:11 GMT, Clive Verghese wrote: >> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 972: >> >>> 970: boolean found = false; >>> 971: CipherSuite cs; >>> 972: if ((cs = cipherSuiteNames.get(name)) != null && !cs.supportedProtocols.isEmpty()) { >> >> Nice update! I appreciate if you could avoid lines longer than 80 characters, since they?re not handled well by many terminals and tools (See [Java Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html)). > > Thank you @XueleiFan, Updated the length of the line. Thank you for the update. This PR looks good to me, and I have no further comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From peter.firmstone at zeus.net.au Fri Jul 23 22:33:25 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 24 Jul 2021 08:33:25 +1000 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> Message-ID: <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> I think it's worth noting that there isn't a way to securely run code with malicious intent now, so I'm surprised that at this late stage you were still providing support for sand boxing (whack a mole). It's just for us many assumptions have been made on a Java platform with SM, using POLP (not sandboxing) as this was one of the foundational principles of secure coding guidelines (just like following concurrency best practice, were were following security best practice).?? Sandboxing is an all or nothing approach, if you had a trusted applet that was signed, it had AllPermission, if you had an unsigned applet, then it had no permissions.? Sandboxing was one of the use cases for SM, when combined with ClassLoader visibility, but we never realized that OpenJDK developers meant sandboxing == authorization access controls. When you remove that pillar, everything it's supporting collapses, not just sand boxing, so when you say you are removing support for sandboxing, we say, good idea, but we didn't realize you were saying you were removing support for all authorization access controls.?? Reduced and revised authorization and access control would have been acceptable, as tightening reflection visibility using a different form of access control removes the need for authorization based reflection access checks, but also removing atomic construction guarantee's just seems like were doing this at a rapid pace without the community understanding what you have in mind, and this may have more uses than just stopping finalizer attacks.? Unfortunately when you develop a feature, you can't be sure developers won't adapt and utilize it for multiple purposes. Personally I think a better approach would have been to first reduce and simplify authorization access controls, replacing some of the functionality with different but more appropriate mechanisms. Removing authorization access control features, without replacement means our software would be insecure, there isn't an obvious way to re-secure it, without re-architecting or re-designing it from the ground up, and Java is now a moving target anyway, so we would have to wait for it to re-stabilize as it transitions from Hippy to Hipster Java (just making a point it's not the same Java). With this new understanding, we need to reconsider both the language and the platform that we'll be developing on.? Clearly a language with less boilerplate is an obvious start, I don't yet know which, we will still consider the JVM, but it would be with Kafka or Clojure, but then we also need to consider whether we will be able to secure the underlying platform, or at least use it securely.? Arguably we can do things now that aren't possible on other platforms, so we need to develop that capability as well, not just secure it. Regards, Peter. On 23/07/2021 9:45 pm, Alan Bateman wrote: > On 23/07/2021 11:48, Peter Firmstone wrote: >> >> Perhaps the solution is to replace the entire class, instead of >> instrumenting one method? >> >> Compile a patched copy of the JVM, with modified class files, then >> replace the existing classes in the JVM with the modified classes? >> >> Kinda like maintaining a fork, but using Agents to instrument the >> original JVM with classes from the fork? >> >> I sure wish there was a better option, if anyone knows one, I'm all >> ears. > > JEP 411 puts the JDK on the road to dropping support for sandboxing. > This means there won't be a built-in means to securely run code that > has malicious intent. It means that many of the concerns for finalizer > attacks go away too. In the case of the ClassLoader example in your > first mail then it may be that the private static method that you want > to instrument will be removed. If removed, then it should make the > instrumentation a bit easier so that you can instrument the protected > constructors to invokestatic your equivalent of a permission check > before the invokespecial. So I think this specific case is > surmountable but in general I don't think it will be tenable to patch > hundreds of classes and be confident that you've got everything, esp. > with a moving code base and new features. I can't tell if your > "authorization layer" is for use when running with code that has > malicious intent. If it is, then I don't think it will be tenable to > duplicate all the deeply invasive permission checks that exist today > and keep it up to date as new features and changes. When agents were > muted in the early discussion on JEP 411 then the context was file and > network access where several people were interested in having a means > to veto access. Expanding this to have a SM equivalent be able to veto > every reflective access, prevent trusted method chain and other > attacks, amounts to keeping the SM forever. > > As regards the comments about agents having the power to instrument > methods that aren't accessible to user code then that is normal. Java > agents are for tools to do powerful things, they aren't intended for > libraries for applications to use directly. This is why agents are > opt-in on the command line. Agent maintainers weld great power and > must take care to never leak the Instrumentation object to > applications or libraries. > > -Alan From weijun at openjdk.java.net Fri Jul 23 22:43:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 23 Jul 2021 22:43:00 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String In-Reply-To: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: On Fri, 23 Jul 2021 17:16:26 GMT, Sean Mullan wrote: > Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. > > Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. src/java.base/share/classes/sun/security/validator/SymantecTLSPolicy.java line 161: > 159: X509Certificate anchor = chain[chain.length-1]; > 160: String fp = fingerprint(anchor); > 161: if (fp != null && FINGERPRINTS.contains(fp)) { I understand the original behavior is also bypassing the check if fingerprint cannot be calculated, but this sounds a little irresponsible. Same as in `UntrustedCertificates`. src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1924: > 1922: x -> getFingerprintInternal(x, debug)); > 1923: } > 1924: I'm a little confused by these methods. Can you inline `getFingerprintInternal` and rename `getFingerprint` on line 1936 to `getFingerprintInternal`? test/jdk/sun/security/x509/X509CertImpl/GetFingerprintError.java line 53: > 51: > 52: // test cert with bad encoding > 53: X509Certificate fcert = new X509CertificateWithBadEncoding(cert); In fact, `new X509CertImpl()` satisfies your requirement perfectly, which is an unpopulated cert with no encoding. It might be a little weird though. You can continue with your choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From cverghese at openjdk.java.net Sat Jul 24 10:18:09 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Sat, 24 Jul 2021 10:18:09 GMT Subject: Integrated: 8270317: Large Allocation in CipherSuite In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each time. > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. (Method in this PR) > > Benchmark (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well. This pull request has now been integrated. Changeset: e627caec Author: Clive Verghese Committer: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/e627caec84c169c99c04e0d355c29b806a0266ed Stats: 151 lines in 2 files changed: 91 ins; 45 del; 15 mod 8270317: Large Allocation in CipherSuite Reviewed-by: xuelei, simonis ------------- PR: https://git.openjdk.java.net/jdk/pull/4783 From peter.firmstone at zeus.net.au Sat Jul 24 23:30:09 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 25 Jul 2021 09:30:09 +1000 Subject: JEP 411: Sandboxing v's LOTJ (language other than Java) running on top of Java class libraries / JVM. Message-ID: <59b43c8f-62d0-c519-02c1-c951be124442@zeus.net.au> I have established it's not practical to implement agents to intercept Java class libraries (Not the JVM) to guard access, such as class loading, properties, IO, etc. It's also not practical to construct a Sandbox using ClassLoader, as has been suggested: 1. We would have to prevent access to java.lang.Class, to prevent code escaping the sandbox, this is far too restrictive. 2. It isn't practical to dynamically grant access, from within a sandbox. 3. The sandbox is an all or nothing approach. 4. The sandbox isn't an authorization layer. Clearly Java in future, will be a zone of implicit trust, similarly to how we use C today from Java. We need a "safer" language than Java, just like Java was a "safer" language than C. This "safer" language would then allow authorization access controls, for network, file, class loading, data parsing, etc. Rather than a sandbox, it just needs to be safer, with the ability to allow access to the underlying Java / C / etc, to trusted / authenticated / verified entities. If anyone has any ideas regarding suitable languages, I'd be very interested to hear your thoughts. -- Regards, Peter Firmstone -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jul 25 14:44:19 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Jul 2021 15:44:19 +0100 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> Message-ID: <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> On 23/07/2021 23:33, Peter Firmstone wrote: > I think it's worth noting that there isn't a way to securely run code > with malicious intent now, so I'm surprised that at this late stage > you were still providing support for sand boxing (whack a mole). > > It's just for us many assumptions have been made on a Java platform > with SM, using POLP (not sandboxing) as this was one of the > foundational principles of secure coding guidelines (just like > following concurrency best practice, were were following security best > practice).?? Sandboxing is an all or nothing approach, if you had a > trusted applet that was signed, it had AllPermission, if you had an > unsigned applet, then it had no permissions.? Sandboxing was one of > the use cases for SM, when combined with ClassLoader visibility, but > we never realized that OpenJDK developers meant sandboxing == > authorization access controls. > > When you remove that pillar, everything it's supporting collapses, not > just sand boxing, so when you say you are removing support for > sandboxing, we say, good idea, but we didn't realize you were saying > you were removing support for all authorization access controls.?? > Reduced and revised authorization and access control would have been > acceptable, as tightening reflection visibility using a different form > of access control removes the need for authorization based reflection > access checks, but also removing atomic construction guarantee's just > seems like were doing this at a rapid pace without the community > understanding what you have in mind, and this may have more uses than > just stopping finalizer attacks. I'm not 100% sure what you mean by "atomic construction guarantee" here. This JEP does not propose to change anything with finalization or do anything with the registration of finalizers after Object. runs. Our exchange in the previous mails was about classes (using ClassLoader as the example) that specify a SM permission check in their constructors, something that is strongly discouraged as the checks are easy to bypass. The idiom that we use in the JDK to prevent bypassing these SM permission checks with a finalizer attack is to check in a static method that returns a dummy parameter for the invokespecial. My point in the previous mail is that when the SM permission checks eventually go away then many of the uses of this idiom can do away too. That said, there is strong desire to eventually remove finalization too. Finalization was deprecated several years ago and the Java platform defines APIs that provide much more flexible and efficient ways do run cleanup actions when an object becomes unreachable. So another multi-year/multi-release effort to remove a problematic feature, just nothing to do with this JEP. As regards POLP, the focus of SM architecture when it was enhanced in Java 1.2. The JEP attempts to explain why this has been a failure. AccessController is voodoo that most developers have never encountered so anyone trying to run with SM ends up running counter to the principle of least privilege by granting all permissions. -Alan. From peter.firmstone at zeus.net.au Mon Jul 26 01:05:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 26 Jul 2021 11:05:32 +1000 Subject: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> Message-ID: <7ed9b7ec-85dd-e804-90c6-140c1c7ee3fa@zeus.net.au> Hi Alan, My apologies, finalizer removal, that's a positive step, I thought it was motivated by "the code is trusted so we don't need to worry about finalizer attacks". Also apologies for the long email, but it seems appropriate for information handover. Atomic construction guarantee; if invariant checks during construction throw an exception, prior to calling Object's zero arg constructor, an object instance will not be created, creation of the object is atomic, either it succeeds with all invariants satisfied, or an object is not created, such that it cannot be created in a broken state where invariants aren't satisfied.? We apply this constructor safety guarantee to deserialization of data, it is a requirement of the code performing deserialzation to check invariants and we require that users are authenticated, this is to avoid parsing untrusted data, while still validating user data.? We enforce it using SM infrastructure. I understand JEP 411 is a business decision, there wasn't enough adoption, following the fallout of applets, businesses and users running afoul of untrusted code, causing ongoing pain (publicly). The remaining attempts of JEP 411 to explain why POLP is a technical failure only apply to the default implementation and are incorrect when applied to other implementations, it's a commercial failure, as suggested by low rates of adoption in JEP 411, but that's due to a lack of investment in tooling, however I suspect OpenJDK has underestimated adoption, although probably not by a big margin, but I suspect it will be more painful than OpenJDK anticipates.? I have a perfectly good working reliable publicly available example (for years) contrary to JEP 411's technical claims. OpenJDK's decision has been made, and those affected must also assess and make their own decisions, the following only serves to share my thoughts and insights, no need to read further if not of interest.? Our Java programs are going into care and maintenance as we assess suitable replacement development platforms. <---------> Applets relied on SM (perhaps SM only exists due to their success), applets themselves weren't the cause of their own demise, for that we have Java Serialization to thank, otherwise applets were a commercial success, and had they remained so, then SM would have also remained, it appears to be inexorably tied to the fate of applets now. Serialization needed an atomic replacement before 2008, when it was becoming obvious that Java serialization was insecure. OpenJDK could still fix Java serialization without using white list filters (ironically white listing is a complication of SM, which reduced adoption, it's likely the same will occur with Serialization white lists, if tooling isn't provided), by removing the ability to serialize circular object graphs, or disabling it by default.? We had circular object graphs in JGDMS (which heavily utilised Java serialization), but we refactored these out after implementing atomic de-serialization, we did this in a way that didn't require breaking the serial form compatibility of existing classes (unless they contained circular references).? This keeps serial data invariant validation code with the object implementation, rather than as a separate white list (and it is more powerful and less complex than white listing), reducing complexity and maintenance, and because failure is atomic an attacker cannot formulate a gadget chain, type safety is also read ahead and checked prior to de-serialization of data.?? The development of atomic serialization started with atomic deserialization which was completed a few years ago, atomic serialization was under current development, with new explicit public API methods for used for serialization, to avoid any issues with reflection and module access controls, we were still using Java serialization to serialize, but an alternative AtomicObjectInputStream to de-serialize. SM Performance isn't an issue, my policy implementation is high scaling and has no hotspots, neither is deployment, we have tools to generate policy files (more than one) and have been doing so for many years (the first tool was written by Sun Microsystems circa 2004 I think, it still required policy file editing, but listed permissions required), the second tool was written 8 years ago approx.? Our use cases have passed the tests of time.? I don't believe people hand author policy files in the age of computing: I've seen examples of policy generation tools by other authors on GitHub.? Sure some developers might grant AllPermission, to get something running, or for tests, but I haven't seen anyone serious about security in production that does.? I don't use the built in policy provider (it has a blocking permission cache that negatively impacts performance), my policy implementation doesn't have a cache and it's many magnitudes faster and high scaling thanks to shared immutability, thread confined mutability and the garbage collector, the last remaining pain point is SocketPermssion and DNS.? If SocketPermission was changed to use URI RFC3986 normalization and had netmask wildcards, that would address remaining issues (Too many SocketPermission grants required in policy files).?? I managed to avoid most DNS calls by using a PermissionComparator, which finds the closest match, if it doesn't find an exact match, to reduce the number of actual permission checks.?? We also had to implement our own ClassLoader to avoid the DNS calls originating from SecureClassLoader. Java's memory model has more voodoo than AccessController, the JMM makes AccessController look simple, programming is voodoo to a non programmer, everything is relative and based on experience.? I guess you are suggesting the complexity to use ratio is too high. I can imagine what it was like being at a presentation when someone enables SecurityManager and it stops working, why the default provider wasn't fixed then I'm not sure, budget perhaps? If I was at that presentation, I'd generate the policy file on the first pass, then make the new policy file the default policy.? It would have added about 10 minutes to the presentation as we stepped through the swim lanes, or whatever people like to call executing desired functionality (preferably automated test cases), at least it would look like we knew what we were doing, then you validate it by attempting to do something you shouldn't, it leaves the JVM in a very locked down state (which can also prevent user errors), occasionally you can forget to execute some necessary functionality (not have a test case for it), or not allow the program to run long enough to capture all necessary permissions, but the missing permissions are quickly sorted, by running the tool a second time, the missing permissions are appended to policy files. I would have preferred that we reduced the number of permissions, these can be removed without breaking backward compatibility, the policy just treats it as an UnresolvedPermission. Many permissions are being replaced by better access controls (as they should), such as more recent changes to package / module access and reflection and this could be a gradual process as unnecessary permissions are removed.?? We aren't trying to sandbox code, it's used for company authorization rules.? The code is trusted, but if it's from a third party, or another company with a business relationship, eg approved vendor, we need to place some constraints on it, which aren't intended to defend against malicious code.? Our intent is to prevent parsing of malicious data and loading of malicious code. I would have preferred to build a model around permissions required for authorization of users and trusted code, rather than focusing on sandboxes and malicious code.?? If a user or service doesn't authenticate, they cannot dynamically load code because they are not granted permission to do so, they also cannot generally deserialize untrusted data, this all depends on SM infrastructure. We need to control access to networks, files, user credentials, properties (of certificate store locations) and class loading. Primarily we do this by authenticating users, we also allow some authenticated users and services to also dynamically download and load classes. Due to JEP 411, we have no future Java upgrade path, what's possible currently with authorization, will not be possible in future versions of Java, design assumptions throughout our software are built on SM infrastructure.?? When we remove SM from our systems, it enables deserialization of untrusted data from unauthenticated users and it allows downloads and class loading of untrusted code.?? Our software uses TLS over IPv6 for it's point to point connectivity and is able to dynamically discover compatible services over global networks, so we cannot use a firewall to protect it either. The library we use and provide publicy can be found here, in case its of interest: https://github.com/pfirmstone/JGDMS At the end of the day, choosing any development platform is a risk, and this was one of the risks of choosing a commercial platform (at that time Java was a commercial platform and it's still funded by commercial interests today), budgets dictate both the initial development compromises and the eventual demise when adoption falls and a feature is no longer commercially viable for the people responsible for maintaining it. Due to JEP 411 all our Java development will be put into care and maintenance, I'm currently looking at our options for other programming languages and platforms on which to base new development, Haskell looks interesting and seems to have better type safety, due to it's academic background, its developers are focused on solving very difficult problems and doing so in a way that is provably correct, using mathematical theorems, I think that's why its taken years longer to stabilize.? By not having made compromises, it will likely be useful for much longer, even with some change.? It seems unlikely that an academic language would lose features due to budget constraints, it is more likely that inadequate or problematic features will be addressed and upgraded or replaced. It is not so much that JEP 411 might break backward compatibility, we can live with that, what we are unable to address; it removes a feature that cannot be re-implemented and has no replacement, which exposes us to low probability, but unacceptable consequences. There are no hard feelings, it's just a consequence of our original platform adoption choice, we knew there were risks.? It's time to move on and deal with it.? No doubt Java will be useful to many people for many years to come, and many don't require an authorization layer or chose something other than SM to implement one.? With no Java upgrade path, it leaves us free to choose from what is available now, rather than a choice made 20 years ago. In any case it's likely a choice that we would have needed to make eventually, JEP 411 has only brought it forward.?? If Haskell is a magnitude more efficient, as its proponents claim, then it may ultimately provide an overall cost saving.?? We haven't made a choice yet though, it's still under investigation. I do appreciate that you took the time to respond to my emails. Regards, Peter. On 26/07/2021 12:44 am, Alan Bateman wrote: > On 23/07/2021 23:33, Peter Firmstone wrote: >> I think it's worth noting that there isn't a way to securely run code >> with malicious intent now, so I'm surprised that at this late stage >> you were still providing support for sand boxing (whack a mole). >> >> It's just for us many assumptions have been made on a Java platform >> with SM, using POLP (not sandboxing) as this was one of the >> foundational principles of secure coding guidelines (just like >> following concurrency best practice, were were following security >> best practice).?? Sandboxing is an all or nothing approach, if you >> had a trusted applet that was signed, it had AllPermission, if you >> had an unsigned applet, then it had no permissions.? Sandboxing was >> one of the use cases for SM, when combined with ClassLoader >> visibility, but we never realized that OpenJDK developers meant >> sandboxing == authorization access controls. >> >> When you remove that pillar, everything it's supporting collapses, >> not just sand boxing, so when you say you are removing support for >> sandboxing, we say, good idea, but we didn't realize you were saying >> you were removing support for all authorization access controls.?? >> Reduced and revised authorization and access control would have been >> acceptable, as tightening reflection visibility using a different >> form of access control removes the need for authorization based >> reflection access checks, but also removing atomic construction >> guarantee's just seems like were doing this at a rapid pace without >> the community understanding what you have in mind, and this may have >> more uses than just stopping finalizer attacks. > I'm not 100% sure what you mean by "atomic construction guarantee" > here. This JEP does not propose to change anything with finalization > or do anything with the registration of finalizers after Object. > runs. Our exchange in the previous mails was about classes (using > ClassLoader as the example) that specify a SM permission check in > their constructors, something that is strongly discouraged as the > checks are easy to bypass. The idiom that we use in the JDK to prevent > bypassing these SM permission checks with a finalizer attack is to > check in a static method that returns a dummy parameter for the > invokespecial. My point in the previous mail is that when the SM > permission checks eventually go away then many of the uses of this > idiom can do away too. > > That said, there is strong desire to eventually remove finalization > too. Finalization was deprecated several years ago and the Java > platform defines APIs that provide much more flexible and efficient > ways do run cleanup actions when an object becomes unreachable. So > another multi-year/multi-release effort to remove a problematic > feature, just nothing to do with this JEP. > > As regards POLP, the focus of SM architecture when it was enhanced in > Java 1.2. The JEP attempts to explain why this has been a failure. > AccessController is voodoo that most developers have never encountered > so anyone trying to run with SM ends up running counter to the > principle of least privilege by granting all permissions. > > -Alan. From shade at openjdk.java.net Mon Jul 26 08:00:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 08:00:05 GMT Subject: RFR: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. Looks like a clean removal to me. Approving so this can be backported to JDK Updates that would be after the cert expiry date. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4851 From github.com+741251+turbanoff at openjdk.java.net Mon Jul 26 11:30:21 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 26 Jul 2021 11:30:21 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying Message-ID: I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. ------------- Commit messages: - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying Changes: https://git.openjdk.java.net/jdk/pull/4487/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269130 Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4487/head:pull/4487 PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+10835776+stsypanov at openjdk.java.net Mon Jul 26 11:30:21 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 26 Jul 2021 11:30:21 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. I think the same simlification can be done for some classes affected by your previous PR https://github.com/openjdk/jdk/pull/4482, e.g. `HttpsClient`, lines 154-157 and 177-180 and `PKCS7`, so I'd wait for https://github.com/openjdk/jdk/pull/4482 and then add one more commit here. @turbanoff I've filed a ticket for this: https://bugs.openjdk.java.net/browse/JDK-8269130. Also I think you can integrate https://github.com/openjdk/jdk/pull/4482 ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+741251+turbanoff at openjdk.java.net Mon Jul 26 11:30:22 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 26 Jul 2021 11:30:22 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com> References: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com> Message-ID: On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien wrote: >> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. >> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. > > src/java.base/share/classes/java/security/Security.java line 656: > >> 654: return null; >> 655: >> 656: return candidates.toArray(new Provider[0]); > > `candidates.toArray(new Provider[candidates.size()]);` > > would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO. > > The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise. > > (i am no reviewer) Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/ ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+114367+mbien at openjdk.java.net Mon Jul 26 11:30:21 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Mon, 26 Jul 2021 11:30:21 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com> On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. src/java.base/share/classes/java/security/Security.java line 656: > 654: return null; > 655: > 656: return candidates.toArray(new Provider[0]); `candidates.toArray(new Provider[candidates.size()]);` would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO. The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise. (i am no reviewer) ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+114367+mbien at openjdk.java.net Mon Jul 26 11:30:22 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Mon, 26 Jul 2021 11:30:22 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com> Message-ID: On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/security/Security.java line 656: >> >>> 654: return null; >>> 655: >>> 656: return candidates.toArray(new Provider[0]); >> >> `candidates.toArray(new Provider[candidates.size()]);` >> >> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO. >> >> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise. >> >> (i am no reviewer) > > Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/ oh I am sorry my mistake - I actually now remember reading the article. (It would be interesting to rerun the benchmark on modern JDKs since I would expect the gap to be smaller now) Please disregard my suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From serb at openjdk.java.net Mon Jul 26 11:30:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 26 Jul 2021 11:30:23 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: <522sj45K-E26GUke0gp6dDoq_4dpwfLMytNVmg5V2k8=.2d5a1a6c-4191-4f63-a83e-af35c69cb6e4@github.com> On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 191: > 189: installed[i]); > 190: } > 191: String[] retval = map.keySet().toArray(new String[0]); Looks like previously the code returns values, and now it will return keys, please recheck. ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From mullan at openjdk.java.net Mon Jul 26 13:41:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 13:41:09 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String In-Reply-To: References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: On Fri, 23 Jul 2021 22:18:26 GMT, Weijun Wang wrote: >> Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. >> >> Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. > > src/java.base/share/classes/sun/security/validator/SymantecTLSPolicy.java line 161: > >> 159: X509Certificate anchor = chain[chain.length-1]; >> 160: String fp = fingerprint(anchor); >> 161: if (fp != null && FINGERPRINTS.contains(fp)) { > > I understand the original behavior is also bypassing the check if fingerprint cannot be calculated, but this sounds a little irresponsible. Same as in `UntrustedCertificates`. Right, I see your point, and I agree it makes more sense in this case to fail, so I will change it. However, if this situation were to occur because of a rogue X509Certificate impl, it is also possible for it to return an encoding that generates a different fingerprint. > src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1924: > >> 1922: x -> getFingerprintInternal(x, debug)); >> 1923: } >> 1924: > > I'm a little confused by these methods. Can you inline `getFingerprintInternal` and rename `getFingerprint` on line 1936 to `getFingerprintInternal`? Not sure what you mean by inline. Do you mean use an anonymous inner class instead of a lambda for the `Function` argument to `ConcurrentHashMap.computeIfAbsent`? Note that `getFingerprintInternal` calls `this.getEncodedInternal` so it cannot be static. > test/jdk/sun/security/x509/X509CertImpl/GetFingerprintError.java line 53: > >> 51: >> 52: // test cert with bad encoding >> 53: X509Certificate fcert = new X509CertificateWithBadEncoding(cert); > > In fact, `new X509CertImpl()` satisfies your requirement perfectly, which is an unpopulated cert with no encoding. It might be a little weird though. You can continue with your choice. Although I didn't include it as part of this change, there are a number of other tests that override a few methods of X509Certificate and the code can be changed to use this pattern. I'll file a follow-on issue to clean that up. ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From weijun at openjdk.java.net Mon Jul 26 14:16:07 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 26 Jul 2021 14:16:07 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String In-Reply-To: References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: On Mon, 26 Jul 2021 13:37:39 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1924: >> >>> 1922: x -> getFingerprintInternal(x, debug)); >>> 1923: } >>> 1924: >> >> I'm a little confused by these methods. Can you inline `getFingerprintInternal` and rename `getFingerprint` on line 1936 to `getFingerprintInternal`? > > Not sure what you mean by inline. Do you mean use an anonymous inner class instead of a lambda for the `Function` argument to `ConcurrentHashMap.computeIfAbsent`? Note that `getFingerprintInternal` calls `this.getEncodedInternal` so it cannot be static. It's "inline" in code refactoring. I was thinking about moving the body of the current `getFingerprintInternal` into its only caller above which is also an instance method. IMO, the other `getFingerPrint` on line 1936 is more internal. ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From mullan at openjdk.java.net Mon Jul 26 17:03:11 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 17:03:11 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String [v2] In-Reply-To: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: > Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. > > Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Refactor X509CertImpl.getFingerprint(String, Debug). Treat null fingerprint as untrusted. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4891/files - new: https://git.openjdk.java.net/jdk/pull/4891/files/50b47ad9..d8652367 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4891&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4891&range=00-01 Stats: 35 lines in 4 files changed: 10 ins; 3 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/4891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4891/head:pull/4891 PR: https://git.openjdk.java.net/jdk/pull/4891 From mullan at openjdk.java.net Mon Jul 26 17:03:12 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 17:03:12 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String [v2] In-Reply-To: References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: <4T93Ryxq82w-uJaWfLSfgHs06DBwNWXNnLgNYAzffCE=.df40f239-9f43-4a32-86f1-76a1381bf244@github.com> On Mon, 26 Jul 2021 14:12:48 GMT, Weijun Wang wrote: >> Not sure what you mean by inline. Do you mean use an anonymous inner class instead of a lambda for the `Function` argument to `ConcurrentHashMap.computeIfAbsent`? Note that `getFingerprintInternal` calls `this.getEncodedInternal` so it cannot be static. > > It's "inline" in code refactoring. I was thinking about moving the body of the current `getFingerprintInternal` into its only caller above which is also an instance method. IMO, the other `getFingerPrint` on line 1936 is more internal. Ok, check out the latest commit to see if it is clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From github.com+741251+turbanoff at openjdk.java.net Mon Jul 26 18:22:39 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 26 Jul 2021 18:22:39 GMT Subject: Integrated: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: <8hxiUvDJy5Y4ewfuAit7Z2ya46d-1B0FTYPCt3oX7So=.7fa4203e-2378-4e5b-b5ef-8f07f6f7e3c9@github.com> On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. This pull request has now been integrated. Changeset: b8f79a7f Author: Andrey Turbanov Committer: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/b8f79a7ff798d3a0eee03a8153be942401781bbc Stats: 18 lines in 3 files changed: 1 ins; 4 del; 13 mod 8268873: Unnecessary Vector usage in java.base Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From weijun at openjdk.java.net Mon Jul 26 18:34:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 26 Jul 2021 18:34:30 GMT Subject: RFR: 8270946: X509CertImpl.getFingerprint should not return the empty String [v2] In-Reply-To: References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: <46pns9yVWcZMf_IPYQdB6W7gH51w22ngm9zYkSCZFZc=.5fb40ee5-921e-43f4-95db-a6fe8615f122@github.com> On Mon, 26 Jul 2021 17:03:11 GMT, Sean Mullan wrote: >> Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. >> >> Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Refactor X509CertImpl.getFingerprint(String, Debug). > Treat null fingerprint as untrusted. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From mullan at openjdk.java.net Mon Jul 26 19:01:31 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 19:01:31 GMT Subject: RFR: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4851 From mullan at openjdk.java.net Mon Jul 26 19:10:35 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 19:10:35 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. The changes to the security classes look good. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+2996845+bokken at openjdk.java.net Mon Jul 26 19:18:33 2021 From: github.com+2996845+bokken at openjdk.java.net (Brett Okken) Date: Mon, 26 Jul 2021 19:18:33 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. src/java.base/share/classes/java/security/Security.java line 656: > 654: return null; > 655: > 656: return candidates.toArray(new Provider[0]); Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)? ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+2996845+bokken at openjdk.java.net Mon Jul 26 19:58:30 2021 From: github.com+2996845+bokken at openjdk.java.net (Brett Okken) Date: Mon, 26 Jul 2021 19:58:30 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92: > 90: } > 91: > 92: InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]); Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From valeriep at openjdk.java.net Mon Jul 26 23:33:33 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 26 Jul 2021 23:33:33 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Thu, 22 Jul 2021 18:30:50 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 762: >> >>> 760: >>> 761: dst.put(out, 0, rlen); >>> 762: processed += srcLen; >> >> It seems that callers of this implGCMCrypt() method such as GCMEngine.doLastBlock() adds the returned value to the "processed" field which looks like double counting? However, some caller such as GCMEncrypt.doUpdate() does not. Seems inconsistent and may lead to wrong value for the "processed" field? > > All the callers that use GCMOperations, ie op.update(...), have the processed value updated. implGCMCrypt() calls op.update() and updates the value. It cannot double count 'processed' is not updated after implGCMCrypt(). I can see your point, but the other methods do not have access to 'processed' and would mean I copy that line 3 times elsewhere. I'd rather keep it as is As long the "processed" value is correct, it's fine. Not sure if I may be missing some subtle things, GCMEngine.implGCMCrypt(GCMOperation op, ByteBuffer src, ByteBuffer dst) impl would increment "processed" with "srcLen". But then in GCMEngine.doLastBlock(GCMOperation op, ByteBuffer buffer, ByteBuffer src, ByteBuffer dst) impl, it calls the GCMEngine.implGCMCrypt(GCMOperation op, ByteBuffer src, ByteBuffer dst) method and stores the return value into "resultLen" and then again increment "processed" with "resultLen" after op.doFinal(...) call. Since "resultLen" contains the number of bytes processed by GCMEngine.implGCMCrypt(GCMOperation op, ByteBuffer src, ByteBuffer dst) method already, adding it to "prcessed" looks like double counting. Not sure what did I miss. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From wetmore at openjdk.java.net Tue Jul 27 00:48:50 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 27 Jul 2021 00:48:50 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v6] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - More codereview comments - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Switching tasks - Merge branch 'master' into JDK-8267485 - More Codereview Comments - Merge branch 'master' into JDK-8267485 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/efa63dc1...2ee40c1e ------------- Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=05 Stats: 53 lines in 2 files changed: 11 ins; 11 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Tue Jul 27 02:50:54 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 27 Jul 2021 02:50:54 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v7] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Additional codereview comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4150/files - new: https://git.openjdk.java.net/jdk/pull/4150/files/2ee40c1e..65f4a2e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=05-06 Stats: 24 lines in 1 file changed: 3 ins; 11 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From mchung at openjdk.java.net Tue Jul 27 03:55:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 27 Jul 2021 03:55:31 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v7] In-Reply-To: References: Message-ID: <9ecBiiNA1i_Z6WJYyhbJ0ZFOCdi4D1jJboQNw85VkNY=.9d617c85-2b01-43aa-8853-73969197fb44@github.com> On Tue, 27 Jul 2021 02:50:54 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Additional codereview comments Looks good with some minor comments. src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 76: > 74: StackWalker dummyWalker = AccessController.doPrivileged( > 75: (PrivilegedAction) (() -> StackWalker.getInstance( > 76: Option.RETAIN_CLASS_REFERENCE))); An alternative is to declare a local variable of `PrivilegedAction` to avoid the cast: PrivilegedAction pa = () -> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); StackWalker dummyWalker = AccessController.doPrivileged(pa); src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 114: > 112: return (callerCodeBase != null) ? > 113: getCryptoPermissionFromURL(callerCodeBase, > 114: alg, defaultPerm) : defaultPerm;}) nit: the line break at ":" would make it easier to read than breaking at `arg`. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Tue Jul 27 05:43:53 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 27 Jul 2021 05:43:53 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v8] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: More codereview comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4150/files - new: https://git.openjdk.java.net/jdk/pull/4150/files/65f4a2e2..40b0de09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=06-07 Stats: 8 lines in 1 file changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Tue Jul 27 05:50:32 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 27 Jul 2021 05:50:32 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v7] In-Reply-To: <9ecBiiNA1i_Z6WJYyhbJ0ZFOCdi4D1jJboQNw85VkNY=.9d617c85-2b01-43aa-8853-73969197fb44@github.com> References: <9ecBiiNA1i_Z6WJYyhbJ0ZFOCdi4D1jJboQNw85VkNY=.9d617c85-2b01-43aa-8853-73969197fb44@github.com> Message-ID: On Tue, 27 Jul 2021 03:51:01 GMT, Mandy Chung wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional codereview comments > > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 76: > >> 74: StackWalker dummyWalker = AccessController.doPrivileged( >> 75: (PrivilegedAction) (() -> StackWalker.getInstance( >> 76: Option.RETAIN_CLASS_REFERENCE))); > > An alternative is to declare a local variable of `PrivilegedAction` to avoid the cast: > > > PrivilegedAction pa = > () -> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); > StackWalker dummyWalker = AccessController.doPrivileged(pa); Reverted to the original style without the cast. > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 114: > >> 112: return (callerCodeBase != null) ? >> 113: getCryptoPermissionFromURL(callerCodeBase, >> 114: alg, defaultPerm) : defaultPerm;}) > > nit: the line break at ":" would make it easier to read than breaking at `arg`. Adding all three params would make it > 80 char lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From mullan at openjdk.java.net Tue Jul 27 13:20:31 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 27 Jul 2021 13:20:31 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 05:43:53 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > More codereview comments The JBS issue should have an applicable `noreg` label. Perhaps `noreg-other` with a comment about the existing tests that have been run. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From mullan at openjdk.java.net Tue Jul 27 13:52:37 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 27 Jul 2021 13:52:37 GMT Subject: Integrated: 8270946: X509CertImpl.getFingerprint should not return the empty String In-Reply-To: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> References: <-6NaMJDwe_DVYkGlCGx_nG9PgS0VSjQ4WVybzy72cSY=.c16cb07f-4752-472b-b368-6a059f288eae@github.com> Message-ID: On Fri, 23 Jul 2021 17:16:26 GMT, Sean Mullan wrote: > Please review this fix to change the internal `X509CertImpl.getFingerprint` method to not return "" as a fingerprint if there is an error generating that fingerprint. Instead, `null` is now returned, and "" is no longer cached as a valid fingerprint. Although errors generating fingerprints should be very rare, this is a cleaner way to handle them. > > Also, debugging messages have been added when there is an exception. And, as a memory/performance improvement, `X509CertImpl.getFingerprint` now calls `X509CertImpl.getEncodedInternal` which avoids cloning the encoded bytes if the `Certificate` is an instance of `X509CertImpl`. This pull request has now been integrated. Changeset: fc80a6b4 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/fc80a6b49364594fafa0e2efc769d2f6234cfa22 Stats: 228 lines in 6 files changed: 192 ins; 12 del; 24 mod 8270946: X509CertImpl.getFingerprint should not return the empty String Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/4891 From wetmore at openjdk.java.net Tue Jul 27 17:14:33 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 27 Jul 2021 17:14:33 GMT Subject: Integrated: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java In-Reply-To: References: Message-ID: On Sat, 22 May 2021 00:20:11 GMT, Bradford Wetmore wrote: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. This pull request has now been integrated. Changeset: c8af8238 Author: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/c8af8238b4b55d515573374800015e115042d883 Stats: 55 lines in 2 files changed: 13 ins; 20 del; 22 mod 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From peter.firmstone at zeus.net.au Tue Jul 27 23:12:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 28 Jul 2021 09:12:32 +1000 Subject: How to remove the SecurityManager In-Reply-To: <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks Remi, Sand-boxing is a bad idea, we are in agreement, it's not something we do, personally I'm taking an interest in safer languages, eg Haskell on secure platforms, eg OpenBSD on Sparc64 *. Perhaps JEP 411 is simply a reflection on the evolution of languages.? Java was safer than C and C++ so replaced these, something safer again will replace Java. I think people are getting our primary use case, authorization, confused with sandboxing (not on our use case list).? OpenJDK developers provided a Sandbox example, I just wanted to communicate that I didn't think it was a practical defense against exploits, nor applicable to our use case: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ Our process for establishing whether third party libraries are trusted before we use them: 1. Build dependency check using Owasp https://owasp.org/www-project-dependency-check/? Reject any dependencies that fail, see https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line 87 for an example of a disabled module due to a vulnerability in a dependency, the module will only be re-enabled if the vulnerability is fixed. 2. Static analysis using SpotBugs, then review identified bugs, review source code if available.? Reject if security bugs are present, or fix / patch. 3. Profiling of permission access checks using: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java 4. Reviewing generated policy files, using grep, this example was generated from over 2000 tests: https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new 5. Remove any permission from the policy file you don't want to grant to third party code, if safe to do so, eg usage statistics reporting. One of my use cases for SM is for auditing to establish trust, and then using SM with POLP policy files generated following the audit, to turn off JVM features we're not using.?? Our policy provider is performant and high scaling even with policy files containing 1000's of lines: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java Our use of SM for access decisions occurs during and after authentication, but also defines access roles for trusted parties, it's not possible to replace SM authorization layer functionality (not to be confused with sandboxes).?? Our use case is distributed systems, with trusted services and trusted clients, which have POJO proxy's, different service proxies are given different ProtectionDomain identity and these identities are used for authorization decisions. In a simple Client - Server application, you only have one user, from the client and the thread runs with this permission, but our systems might be performing a transaction, with 5 different services, and the transaction service is the client of these 5 services, which are represented by their proxy ProtectionDomain's.?? If one of the authenticated services is not authorized to participate in the transaction (eg a third party that's not on the contract, or maybe the contract expired), then it's not authorized and the transaction will fail.? This all occurs over secure authenticated connections, where both servers and clients are authenticated, who's the server and who's the client, well that gets a little blurred sometimes. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java Back in the Jini days, Sun Microsystems, allowed different service proxy's to be loaded by the same ClassLoader, if they had the same CodeSource, they had the same identity if they had the same parent ClassLoader, we don't do that, ClassLoader's are assigned to a service proxy, based on it's authenticated identity. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java This system, at its foundations is based on Jini Extensible Remote Invocation (JERI), we've replaced the serialization layer, to use what we term atomic serialization and apply constraints during connection establishment over secure connections. https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint We limit access based on both the service and user identity.? We generate our policy files by profiling (the tool creates a policy file with correct syntax, ready for immediate use), we recently added replacement of local file paths with properties for policy property expansion with cross platform trans-portability.? While its possible to use a dynamic proxy without downloading code, via an atomic serialization connection, it's not generally advised to do so with unauthenticated users, decisions around dynamic discovery, whether class loading or downloads are allowed, it's all based on policy decisions. The problem with our software is its designed to operate on un-trusted networks, and SM infrastructure is involved in authorization decisions during the authentication process, as well as providing user credentials for secure connections. We have no future Java migration path after JEP 411, the decision's been made, time to move on... On the bright side, according the JEP 411, we did achieve what OpenJDK dev's thought to be almost impossible. :)?? I'm pretty sure using the process I've documented above, you will identify 99% of accidental vulnerabilities in local code, and that was good enough for me lol. > The threat of accidental vulnerabilities in local code is almost > impossible to address with the Security Manager. * OpenBSD on Sparc (very well supported, Oracle should sell these lol, the only drawback is no zfs) is a good idea, no Spectre or Meltdown vulnerabilities. buffy$ uname -a OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64 Although this one's a couple of versions behind, time for an upgrade. Regards, Peter. On 28/07/2021 5:52 am, forax at univ-mlv.fr wrote: > ----- Original Message ----- >> From: "Alan Bateman" >> To: "Remi Forax" , "Peter Firmstone" >> Sent: Tuesday, July 27, 2021 6:33:25 PM >> Subject: Re: How to remove the SecurityManager >> On 27/07/2021 17:11, Remi Forax wrote: >>> Peter, this is how you remove the security manager using the jdk 17 (the >>> SystemMirror class is specific to a JDK version). >>> >>> Any in-process security measures fail if the API let you to peek and poke the >>> memory like Unsafe does. >> I hope you aren't really suggesting anyone does this :-) > nope, it's a small example to explain why in-process sandboxing is a bad idea. > > >> It's dependent >> on the field layout so can break and crash the VM if it doesn't match. >> Also it assumes that someone gets theUnsafe before a SM is set. > yes, it's just an example, you have infinite variations using JNI/JNA/JNR or panama and changing some field value. > >> -Alan > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Tue Jul 27 23:52:19 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 28 Jul 2021 09:52:19 +1000 Subject: How to remove the SecurityManager In-Reply-To: References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> Message-ID: On 28/07/2021 9:12 am, Peter Firmstone wrote: > While its possible to use a dynamic proxy without downloading code, > via an atomic serialization connection, it's not generally advised to > do so with unauthenticated users, decisions around dynamic discovery, > whether class loading or downloads are allowed, it's all based on > policy decisions. Minor clarification / correction, it's not possible on our system to allow an unauthenticated user over a secure connection, our code disallows TLS connections with anon clients. We do provide TCP/IP connections, that are unsecured, however this is generally to allow testing of services during development and shouldn't be used in production.?? No changes to a service need to be made other than configuration settings to enable secure connections. Regards, Peter. From forax at univ-mlv.fr Wed Jul 28 09:41:08 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 28 Jul 2021 11:41:08 +0200 (CEST) Subject: How to remove the SecurityManager In-Reply-To: References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> Message-ID: <199834340.71514.1627465268614.JavaMail.zimbra@u-pem.fr> > From: "Peter Firmstone" > To: "Remi Forax" , "Alan Bateman" > Cc: "jdk-dev" , "security-dev" > > Sent: Wednesday, July 28, 2021 1:12:32 AM > Subject: Re: How to remove the SecurityManager > Thanks Remi, > Sand-boxing is a bad idea, we are in agreement, it's not something we do, > personally I'm taking an interest in safer languages, eg Haskell on secure > platforms, eg OpenBSD on Sparc64 *. > Perhaps JEP 411 is simply a reflection on the evolution of languages. Java was > safer than C and C++ so replaced these, something safer again will replace > Java. All mainstream languages have a way to access to raw pointers to be able to call C functions, here is the one in Haskell https://hackage.haskell.org/package/base-4.5.0.0/docs/Foreign-Storable.html > I think people are getting our primary use case, authorization, confused with > sandboxing (not on our use case list). OpenJDK developers provided a Sandbox > example, I just wanted to communicate that I didn't think it was a practical > defense against exploits, nor applicable to our use case: > [ https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ | > https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ ] > Our process for establishing whether third party libraries are trusted before we > use them: > 1. Build dependency check using Owasp [ > https://owasp.org/www-project-dependency-check/ | > https://owasp.org/www-project-dependency-check/ ] Reject any dependencies that > fail, see [ https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml | > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml ] line 87 for an > example of a disabled module due to a vulnerability in a dependency, the module > will only be re-enabled if the vulnerability is fixed. > 2. Static analysis using SpotBugs, then review identified bugs, review source > code if available. Reject if security bugs are present, or fix / patch. > 3. Profiling of permission access checks using: [ > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java > | > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java > ] > 4. Reviewing generated policy files, using grep, this example was generated from > over 2000 tests: [ > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new > | > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new > ] > 5. Remove any permission from the policy file you don't want to grant to third > party code, if safe to do so, eg usage statistics reporting. > One of my use cases for SM is for auditing to establish trust, and then using SM > with POLP policy files generated following the audit, to turn off JVM features > we're not using. Our policy provider is performant and high scaling even with > policy files containing 1000's of lines: [ > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java > | > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java > ] > Our use of SM for access decisions occurs during and after authentication, but > also defines access roles for trusted parties, it's not possible to replace SM > authorization layer functionality (not to be confused with sandboxes). Our use > case is distributed systems, with trusted services and trusted clients, which > have POJO proxy's, different service proxies are given different > ProtectionDomain identity and these identities are used for authorization > decisions. > In a simple Client - Server application, you only have one user, from the client > and the thread runs with this permission, but our systems might be performing a > transaction, with 5 different services, and the transaction service is the > client of these 5 services, which are represented by their proxy > ProtectionDomain's. If one of the authenticated services is not authorized to > participate in the transaction (eg a third party that's not on the contract, or > maybe the contract expired), then it's not authorized and the transaction will > fail. This all occurs over secure authenticated connections, where both servers > and clients are authenticated, who's the server and who's the client, well that > gets a little blurred sometimes. > [ > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java > | > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java > ] > Back in the Jini days, Sun Microsystems, allowed different service proxy's to be > loaded by the same ClassLoader, if they had the same CodeSource, they had the > same identity if they had the same parent ClassLoader, we don't do that, > ClassLoader's are assigned to a service proxy, based on it's authenticated > identity. > [ > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java > | > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java > ] > This system, at its foundations is based on Jini Extensible Remote Invocation > (JERI), we've replaced the serialization layer, to use what we term atomic > serialization and apply constraints during connection establishment over secure > connections. [ > https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint > | > https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint > ] > We limit access based on both the service and user identity. We generate our > policy files by profiling (the tool creates a policy file with correct syntax, > ready for immediate use), we recently added replacement of local file paths > with properties for policy property expansion with cross platform > trans-portability. While its possible to use a dynamic proxy without > downloading code, via an atomic serialization connection, it's not generally > advised to do so with unauthenticated users, decisions around dynamic > discovery, whether class loading or downloads are allowed, it's all based on > policy decisions. > The problem with our software is its designed to operate on un-trusted networks, > and SM infrastructure is involved in authorization decisions during the > authentication process, as well as providing user credentials for secure > connections. > We have no future Java migration path after JEP 411, the decision's been made, > time to move on... > On the bright side, according the JEP 411, we did achieve what OpenJDK dev's > thought to be almost impossible. :) I'm pretty sure using the process I've > documented above, you will identify 99% of accidental vulnerabilities in local > code, and that was good enough for me lol. >> The threat of accidental vulnerabilities in local code is almost impossible to >> address with the Security Manager. In your validation process, you have a static part to check the dependencies + SpotBug and a runtime part using a combination of class loader + security manager. For the runtime part, instead of using classloaders, you can use an agent, it will also see all the requests to load a class, it can then do a static analysis of the bytecode to determine if the bytecode only contains kosher method calls and field access, the same way SpotBug does. If you really want to have a mechanism that authorize some method calls or not at runtime, you can change the bytecode to introduce a method call that checks the security policy just before the authorizable method call/field access (you also have to blacklist java.lang.reflect and java.lang.invoke but i supppose you already do this). This approach is better than using a classloader + security manager because - Java allows you to define classes not linked to a classloader since Java 8 (the old API is Unsafe.defineAnonymousClass(), the new one is Lookup.defineHiddenClass()) - you can check any calls not only the ones that the SecurityManager traps. - you can reject calls before loading the class, so earlier than with a SecurityManager, more like the bytecode verifier does. - it's more lightweight in term of memory usage because it does not rely on ClassLoaders (each ClassLoader has its own metaspace, so a lot of CL fragment the memory a lot). To read and transform the bytecode, you can ASM [1], this is one of the library used by SpotBug to read/check the bytecode. (disclaimer: i'm one of the maintainer of that library). It's still not 100% perfect because the agent runs in the same process as the code. (you can go deeper by having the authorization framework in a VM puppeteering a client VM likes jshell does using JVMTI). > * OpenBSD on Sparc (very well supported, Oracle should sell these lol, the only > drawback is no zfs) is a good idea, no Spectre or Meltdown vulnerabilities. > buffy$ uname -a > OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64 > Although this one's a couple of versions behind, time for an upgrade. > Regards, > Peter. regards, R?mi [1] https://asm.ow2.io/ > On 28/07/2021 5:52 am, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >> ----- Original Message ----- >>> From: "Alan Bateman" [ mailto:Alan.Bateman at oracle.com | >>> ] To: "Remi Forax" [ mailto:forax at univ-mlv.fr | >>> ] , "Peter Firmstone" [ mailto:peter.firmstone at zeus.net.au >>> | ] Sent: Tuesday, July 27, 2021 6:33:25 PM >>> Subject: Re: How to remove the SecurityManager >>> On 27/07/2021 17:11, Remi Forax wrote: >>>> Peter, this is how you remove the security manager using the jdk 17 (the >>>> SystemMirror class is specific to a JDK version). >>>> Any in-process security measures fail if the API let you to peek and poke the >>>> memory like Unsafe does. >>> I hope you aren't really suggesting anyone does this :-) >> nope, it's a small example to explain why in-process sandboxing is a bad idea. >>> It's dependent >>> on the field layout so can break and crash the VM if it doesn't match. >>> Also it assumes that someone gets theUnsafe before a SM is set. >> yes, it's just an example, you have infinite variations using JNI/JNA/JNR or >> panama and changing some field value. >>> -Alan >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Wed Jul 28 12:10:30 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 28 Jul 2021 22:10:30 +1000 Subject: How to remove the SecurityManager In-Reply-To: <199834340.71514.1627465268614.JavaMail.zimbra@u-pem.fr> References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> <199834340.71514.1627465268614.JavaMail.zimbra@u-pem.fr> Message-ID: <25541dcc-e1d2-cc6f-1770-7d3ebcea24f4@zeus.net.au> Thanks Remi, I'm a user of ASM also, for a long time, since 2007, it's a very performant library. Yes, we could replace the policy audit with another tool, but it's academic, the remaining code cannot be upgraded. For now the policy tools informs me of reflection access, I don't need to blacklist it if I read the code and it's doing something harmless, eg. it might be calling public methods, to support multiple versions of java. I looked at Agents to replace permission checks, it requires modification of private methods, it's bad practice, we've removed all code that accessed private implementation or state, we only use public API. It's not just a simple case of instrumenting public API's, many permissions defend constructors, and constructors contain private static methods to defend against finalizer attacks.?? While I could defend public methods, methods are called far more often than constructors, it would have an unacceptable impact on performance.? Years will pass before finalizers are removed and constructors are simplified so they can be instrumented. It's not viable to re-implement an authorization layer as an external library for Java. Right now SM only has a less than 3% impact on performance and doesn't affect scalability, how can I justify replacing it, for what new feature??? I don't run untrusted code, it works reliably for the authorization based access controls that I require and provides access to subject credentials for authentication of secure connections. Performance profiling of SM running with stateless TLS sockets https://imgur.com/VcSwffC https://imgur.com/VcSwffC https://imgur.com/VcSwffC I think Haskell has better type safety than Java, it handles Null with Maybe, it's good for parsing data, it appears to have made few compromises in its design, but I'm not saying that from experience. I think if I was looking for something to run untrusted code, it would be as source code that I parsed, then compiled, perhaps a subset of Haskell parsed as source code, if I used it for that, then it's audited by parsing and the compiler. I guess something similar could be done with ASM and bytecode, but it's not my goal to run untrusted code, I'll leave the sandbox for the developers cat to bury applets. Regards, Peter. On 28/07/2021 7:41 pm, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *From: *"Peter Firmstone" > *To: *"Remi Forax" , "Alan Bateman" > > *Cc: *"jdk-dev" , "security-dev" > > *Sent: *Wednesday, July 28, 2021 1:12:32 AM > *Subject: *Re: How to remove the SecurityManager > > Thanks Remi, > > Sand-boxing is a bad idea, we are in agreement, it's not something > we do, personally I'm taking an interest in safer languages, eg > Haskell on secure platforms, eg OpenBSD on Sparc64 *. > > Perhaps JEP 411 is simply a reflection on the evolution of > languages.? Java was safer than C and C++ so replaced these, > something safer again will replace Java. > > > All mainstream languages have a way to access to raw pointers to be > able to call C functions, > here is the one in Haskell > https://hackage.haskell.org/package/base-4.5.0.0/docs/Foreign-Storable.html > > > I think people are getting our primary use case, authorization, > confused with sandboxing (not on our use case list).? OpenJDK > developers provided a Sandbox example, I just wanted to > communicate that I didn't think it was a practical defense against > exploits, nor applicable to our use case: > > https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ > > > Our process for establishing whether third party libraries are > trusted before we use them: > > 1. Build dependency check using Owasp > https://owasp.org/www-project-dependency-check/ > Reject any > dependencies that fail, see > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml > > line 87 for an example of a disabled module due to a > vulnerability in a dependency, the module will only be > re-enabled if the vulnerability is fixed. > 2. Static analysis using SpotBugs, then review identified bugs, > review source code if available.? Reject if security bugs are > present, or fix / patch. > 3. Profiling of permission access checks using: > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java > > 4. Reviewing generated policy files, using grep, this example was > generated from over 2000 tests: > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new > > 5. Remove any permission from the policy file you don't want to > grant to third party code, if safe to do so, eg usage > statistics reporting. > > One of my use cases for SM is for auditing to establish trust, and > then using SM with POLP policy files generated following the > audit, to turn off JVM features we're not using.?? Our policy > provider is performant and high scaling even with policy files > containing 1000's of lines: > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java > > > Our use of SM for access decisions occurs during and after > authentication, but also defines access roles for trusted parties, > it's not possible to replace SM authorization layer functionality > (not to be confused with sandboxes).?? Our use case is distributed > systems, with trusted services and trusted clients, which have > POJO proxy's, different service proxies are given different > ProtectionDomain identity and these identities are used for > authorization decisions. > > In a simple Client - Server application, you only have one user, > from the client and the thread runs with this permission, but our > systems might be performing a transaction, with 5 different > services, and the transaction service is the client of these 5 > services, which are represented by their proxy ProtectionDomain's. > If one of the authenticated services is not authorized to > participate in the transaction (eg a third party that's not on the > contract, or maybe the contract expired), then it's not authorized > and the transaction will fail.? This all occurs over secure > authenticated connections, where both servers and clients are > authenticated, who's the server and who's the client, well that > gets a little blurred sometimes. > > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java > > > Back in the Jini days, Sun Microsystems, allowed different service > proxy's to be loaded by the same ClassLoader, if they had the same > CodeSource, they had the same identity if they had the same parent > ClassLoader, we don't do that, ClassLoader's are assigned to a > service proxy, based on it's authenticated identity. > > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java > > > This system, at its foundations is based on Jini Extensible Remote > Invocation (JERI), we've replaced the serialization layer, to use > what we term atomic serialization and apply constraints during > connection establishment over secure connections. > > https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint > > > We limit access based on both the service and user identity.? We > generate our policy files by profiling (the tool creates a policy > file with correct syntax, ready for immediate use), we recently > added replacement of local file paths with properties for policy > property expansion with cross platform trans-portability.? While > its possible to use a dynamic proxy without downloading code, via > an atomic serialization connection, it's not generally advised to > do so with unauthenticated users, decisions around dynamic > discovery, whether class loading or downloads are allowed, it's > all based on policy decisions. > > The problem with our software is its designed to operate on > un-trusted networks, and SM infrastructure is involved in > authorization decisions during the authentication process, as well > as providing user credentials for secure connections. > > We have no future Java migration path after JEP 411, the > decision's been made, time to move on... > > On the bright side, according the JEP 411, we did achieve what > OpenJDK dev's thought to be almost impossible. :) I'm pretty sure > using the process I've documented above, you will identify 99% of > accidental vulnerabilities in local code, and that was good enough > for me lol. > > The threat of accidental vulnerabilities in local code is > almost impossible to address with the Security Manager. > > > In your validation process, you have a static part to check the > dependencies + SpotBug and a runtime part using a combination of class > loader + security manager. > For the runtime part, instead of using classloaders, you can use an > agent, it will also see all the requests to load a class, it can then > do a static analysis of the bytecode to determine if the bytecode only > contains kosher method calls and field access, the same way SpotBug does. > If you really want to have a mechanism that authorize some method > calls or not at runtime, you can change the bytecode to introduce a > method call that checks the security policy just before the > authorizable method call/field access > (you also have to blacklist java.lang.reflect and java.lang.invoke but > i supppose you already do this). > > This approach is better than using a classloader + security manager > because > - Java allows you to define classes not linked to a classloader since > Java 8 (the old API is Unsafe.defineAnonymousClass(), the new one is > Lookup.defineHiddenClass()) > - you can check any calls not only the ones that the SecurityManager > traps. > - you can reject calls before loading the class, so earlier than with > a SecurityManager, more like the bytecode verifier does. > - it's more lightweight in term of memory usage because it does not > rely on ClassLoaders (each ClassLoader has its own metaspace, so a lot > of CL fragment the memory a lot). > > To read and transform the bytecode, you can ASM [1], this is one of > the library used by SpotBug to read/check the bytecode. > (disclaimer: i'm one of the maintainer of that library). > > It's still not 100% perfect because the agent runs in the same process > as the code. > (you can go deeper by having the authorization framework in a VM > puppeteering a client VM likes jshell does using JVMTI). > > > * OpenBSD on Sparc (very well supported, Oracle should sell these > lol, the only drawback is no zfs) is a good idea, no Spectre or > Meltdown vulnerabilities. > > buffy$ uname -a > OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64 > > Although this one's a couple of versions behind, time for an upgrade. > > Regards, > > Peter. > > > regards, > R?mi > > [1] https://asm.ow2.io/ > > > On 28/07/2021 5:52 am, forax at univ-mlv.fr > wrote: > > ----- Original Message ----- > > From: "Alan Bateman" > To: "Remi Forax" , "Peter Firmstone" > Sent: Tuesday, July 27, 2021 6:33:25 PM > Subject: Re: How to remove the SecurityManager > > On 27/07/2021 17:11, Remi Forax wrote: > > Peter, this is how you remove the security manager using the jdk 17 (the > SystemMirror class is specific to a JDK version). > > Any in-process security measures fail if the API let you to peek and poke the > memory like Unsafe does. > > I hope you aren't really suggesting anyone does this :-) > > nope, it's a small example to explain why in-process sandboxing is a bad idea. > > > It's dependent > on the field layout so can break and crash the VM if it doesn't match. > Also it assumes that someone gets theUnsafe before a SM is set. > > yes, it's just an example, you have infinite variations using JNI/JNA/JNR or panama and changing some field value. > > -Alan > > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fguallini at openjdk.java.net Wed Jul 28 18:33:38 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 28 Jul 2021 18:33:38 GMT Subject: Integrated: 8209776: Refactor jdk/security/JavaDotSecurity/ifdefs.sh to plain java test In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 11:05:08 GMT, Fernando Guallini wrote: > This change converts security/JavaDotSecurity/ifdefs.sh to java equivalent This pull request has now been integrated. Changeset: 97110337 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/9711033780d2329a376ea5b2a72c0da2e1731114 Stats: 159 lines in 2 files changed: 101 ins; 58 del; 0 mod 8209776: Refactor jdk/security/JavaDotSecurity/ifdefs.sh to plain java test Reviewed-by: rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/4791 From svkamath at openjdk.java.net Wed Jul 28 23:14:04 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 28 Jul 2021 23:14:04 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v5] In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: > I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Extended jtreg test case, made changes to .cpp and .java files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4019/files - new: https://git.openjdk.java.net/jdk/pull/4019/files/4a36816f..108d4a3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=03-04 Stats: 110 lines in 9 files changed: 53 ins; 29 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019 From rhalade at openjdk.java.net Thu Jul 29 00:25:31 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 29 Jul 2021 00:25:31 GMT Subject: Integrated: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. This pull request has now been integrated. Changeset: 2ec45dc2 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/2ec45dc2dd3a6bcb4f68ee7cde5858d63614305a Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod 8225082: Remove IdenTrust certificate that is expiring in September 2021 Reviewed-by: shade, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4851 From iignatyev at openjdk.java.net Thu Jul 29 00:53:12 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 29 Jul 2021 00:53:12 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package Message-ID: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Hi all, could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? the majority of the patch is the following substitutions: - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` - `s/sun.hotspot.code/jdk.test.whitebox.code/g` - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` testing: tier1-4 Thanks, -- Igor ------------- Commit messages: - copyright year - update TEST.ROOT - jdk: s/sun\.hotspot\.gc/jdk.test.whitebox.gc/g - jdk: s/sun\.hotspot\.code/jdk.test.whitebox.code/g - jdk: s/sun\.hotspot\.WhiteBox/jdk.test.whitebox.WhiteBox/g - hotspot: 's~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g' - hotspot: s/sun\.hotspot\.parser/jdk.test.whitebox.parser/g - hotspot: s/sun\.hotspot\.cpuinfo/jdk.test.whitebox.cpuinfo/g - hotspot: s/sun\.hotspot\.code/jdk.test.whitebox.code/g - hotspot: 's/sun\.hotspot\.gc/jdk.test.whitebox.gc/g' - ... and 9 more: https://git.openjdk.java.net/jdk17/compare/c8ae7e5b...8f12f2cf Changes: https://git.openjdk.java.net/jdk17/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8067223 Stats: 2310 lines in 949 files changed: 0 ins; 0 del; 2310 mod Patch: https://git.openjdk.java.net/jdk17/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk17/pull/290 From peter.firmstone at zeus.net.au Thu Jul 29 01:20:49 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 29 Jul 2021 11:20:49 +1000 Subject: How to remove the SecurityManager In-Reply-To: References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> Message-ID: <7164cfa7-d76a-5de0-dcee-1eda919bcfc4@zeus.net.au> The intent of the following process is to perform a targeted audit, which allows inspection of small parts of the code identified by these steps. On 28/07/2021 9:12 am, Peter Firmstone wrote: > > Our process for establishing whether third party libraries are trusted > before we use them: > > 1. Build dependency check using Owasp > https://owasp.org/www-project-dependency-check/ Reject any > dependencies that fail, see > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line > 87 for an example of a disabled module due to a vulnerability in a > dependency, the module will only be re-enabled if the > vulnerability is fixed. > 2. Static analysis using SpotBugs, then review identified bugs, > review source code if available.? Reject if security bugs are > present, or fix / patch. > 3. Profiling of permission access checks using: > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java > 4. Reviewing generated policy files, using grep, this example was > generated from over 2000 tests: > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new > 5. Remove any permission from the policy file you don't want to grant > to third party code, if safe to do so, eg usage statistics reporting. > In the construction industry, a similar approach is used by structural engineers and weld inspectors, when inspecting welds for defects, using Ultrasonic, X-Ray or visual inspection, weld defects in structures have the potential to cause catastrophic failure and multiple fatalities, likely worse consequences than a bug in Java, so engineers identify critical areas? for inspectors to target with 100% coverage, perhaps by UT or X-Ray, to inspect the weld internally, then the structural engineer will nominate to inspect 10% of other areas with UT, with 100% visual inspection, for example, if defects are found, then they will increase UT inspection coverage, welds need to be gouged out and re-welded, until the inspector is satisfied with quality. A targeted code audit process will also identify code quality, if there are many bugs, don't use it, even if these aren't security bugs. This can hardly be compared with the approach used for running Applets in a sandbox that may have malicious intent, in that case no auditing has been performed at all. This use case of SecurityManager recognizes shortcomings of Java platform security.?? Sandboxing was a marketing term used for Applets, I don't know the origin of the term sandbox when used for computer security, but whenever there is a sandbox, there is a risk of escape, and simplicity is thy friend, it should be left to cyber security professionals. If you removed applets, then there is no use case for a Sandbox, so why remove SecurityManager? Come on honestly, JEP 411 is confirmation biased, is overly focused on sandboxing and therefore not factual or relevant, I've provided sufficient evidence contrary to it's claims.?? It needs to take the ability to migrate code into account as well as use cases other than sandboxing. We use SM to prevent loading of untrusted (unaudited) code and untrusted (unauthenticated) data, but we don't use it as a sandbox to attempt to encapsulate malicious code and malicious users, we use it for authorization decisions, for external users and services, this could also be applied to Web Services, not just Jini services, these authorization decisions prevent loading untrusted code and parsing untrusted data. grant codebase "httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd", ??? principal javax.security.auth.x500.X500Principal "CN=Outrigger" { ??? permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; }; Rather than throwing developers who use SM under the bus, we could be given a migration path: 1. Review and reduce the number of permissions focused *only* on authorization use cases. ? Eg: Give Properties useful for authorization their own guarded area in the Property map??? I mean, why are we guarding java.util.PropertyPermission "java.specification.version", "read" and many others like it? Fix SocketPermission, add netmask wild cards, use RFC3986 normalization, stop using DNS.? Ever heard of DNS spoofing? 2. What about parsing of data?? Such as XML and Java Serialization, among others, this should have a permission check, that when granted to users, ensures the data source has been authenticated.?? This is a server application, not client.?? Permission to parse data should only be granted to user principal's.? No user, then the data is untrusted and shouldn't be parsed. 3. Create a guard security provider interface to replace permission checks, to allow developers to focus on their authorization needs, that would allow us to completely ignore permission checks that are irrelevant and replace bad implementations like SocketPermission. 4. Consider simplification of "Voodoo", maybe instead of trying to check every Thread stack (inheriting call stacks), if there is no doPrivileged call on the current Thread's stack (reduces shared state, it's thread confined), then report it and throw a SecurityException, don't try to inherit thread context, because it doesn't work for executor tasks.?? Then it will be fixed downstream instead of allowed to create viral permission checks that violate the principle of least privilege.?? This is not a security vulnerability risk, we are only using it for authorization, not sandboxing and it will make policy files much shorter, improving readability. 5. We still use AccessController and AccessControlContext to establish TLS connections, why break it? 6. Get a tool to generate policy files (mine's only 653 lines of code). https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java JEP 411 nukes backward compatibility so it cannot be fixed at all. Regards, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvn at openjdk.java.net Thu Jul 29 01:33:29 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 29 Jul 2021 01:33:29 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com> On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` > - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` > - `s/sun.hotspot.code/jdk.test.whitebox.code/g` > - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` > - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` > > testing: tier1-4 > > Thanks, > -- Igor I know that tests fixes could be pushed during RDP2 without approval. But these one is very big and it is not a fix - it is enhancement. What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18. And I can't even review it because GutHub UI hangs on these big changes. ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From dholmes at openjdk.java.net Thu Jul 29 01:59:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Jul 2021 01:59:34 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com> Message-ID: On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > I know that tests fixes could be pushed during RDP2 without approval. > But these one is very big and it is not a fix - it is enhancement. > > What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18. > > And I can't even review it because GutHub UI hangs on these big changes. I agree with @vnkozlov this too big and disruptive for 17 at this stage of the release. I also think a better approach to this cleanup would have been to copy the WhiteBox class to the new package structure, then update the tests in chunks, then remove the old WhiteBox classes when that is complete. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From peter.firmstone at zeus.net.au Thu Jul 29 06:38:23 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 29 Jul 2021 16:38:23 +1000 Subject: How to remove the SecurityManager In-Reply-To: <7164cfa7-d76a-5de0-dcee-1eda919bcfc4@zeus.net.au> References: <960217215.42388.1627402274612.JavaMail.zimbra@u-pem.fr> <92effb58-0218-82ca-afaf-6c9014572fad@oracle.com> <2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr> <7164cfa7-d76a-5de0-dcee-1eda919bcfc4@zeus.net.au> Message-ID: Appended inline below. On 29/07/2021 11:20 am, Peter Firmstone wrote: > > The intent of the following process is to perform a targeted audit, > which allows inspection of small parts of the code identified by these > steps. > > On 28/07/2021 9:12 am, Peter Firmstone wrote: >> >> Our process for establishing whether third party libraries are >> trusted before we use them: >> >> 1. Build dependency check using Owasp >> https://owasp.org/www-project-dependency-check/ Reject any >> dependencies that fail, see >> https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line >> 87 for an example of a disabled module due to a vulnerability in >> a dependency, the module will only be re-enabled if the >> vulnerability is fixed. >> 2. Static analysis using SpotBugs, then review identified bugs, >> review source code if available.? Reject if security bugs are >> present, or fix / patch. >> 3. Profiling of permission access checks using: >> https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java >> 4. Reviewing generated policy files, using grep, this example was >> generated from over 2000 tests: >> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new >> 5. Remove any permission from the policy file you don't want to >> grant to third party code, if safe to do so, eg usage statistics >> reporting. >> > In the construction industry, a similar approach is used by structural > engineers and weld inspectors, when inspecting welds for defects, > using Ultrasonic, X-Ray or visual inspection, weld defects in > structures have the potential to cause catastrophic failure and > multiple fatalities, likely worse consequences than a bug in Java, so > engineers identify critical areas? for inspectors to target with 100% > coverage, perhaps by UT or X-Ray, to inspect the weld internally, then > the structural engineer will nominate to inspect 10% of other areas > with UT, with 100% visual inspection, for example, if defects are > found, then they will increase UT inspection coverage, welds need to > be gouged out and re-welded, until the inspector is satisfied with > quality. > > A targeted code audit process will also identify code quality, if > there are many bugs, don't use it, even if these aren't security bugs. > > This can hardly be compared with the approach used for running Applets > in a sandbox that may have malicious intent, in that case no auditing > has been performed at all. > > This use case of SecurityManager recognizes shortcomings of Java > platform security.?? Sandboxing was a marketing term used for Applets, > I don't know the origin of the term sandbox when used for computer > security, but whenever there is a sandbox, there is a risk of escape, > and simplicity is thy friend, it should be left to cyber security > professionals. > > If you removed applets, then there is no use case for a Sandbox, so > why remove SecurityManager? > > Come on honestly, JEP 411 is confirmation biased, is overly focused on > sandboxing and therefore not factual or relevant, I've provided > sufficient evidence contrary to it's claims.?? It needs to take the > ability to migrate code into account as well as use cases other than > sandboxing. > > We use SM to prevent loading of untrusted (unaudited) code and > untrusted (unauthenticated) data, but we don't use it as a sandbox to > attempt to encapsulate malicious code and malicious users, we use it > for authorization decisions, for external users and services, this > could also be applied to Web Services, not just Jini services, these > authorization decisions prevent loading untrusted code and parsing > untrusted data. > > grant codebase > "httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd", > ??? principal javax.security.auth.x500.X500Principal "CN=Outrigger" > { > ??? permission org.apache.river.api.io.DeSerializationPermission > "MARSHALL"; > ??? permission net.jini.security.AuthenticationPermission > "javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer > javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; > }; > > Rather than throwing developers who use SM under the bus, we could be > given a migration path: > > 1. Review and reduce the number of permissions focused *only* on > authorization use cases. ? Eg: Give Properties useful for > authorization their own guarded area in the Property map??? I > mean, why are we guarding java.util.PropertyPermission > "java.specification.version", "read" and many others like it??? > Fix SocketPermission, add netmask wild cards, use RFC3986 > normalization, stop using DNS.? Ever heard of DNS spoofing? > 2. What about parsing of data?? Such as XML and Java Serialization, > among others, this should have a permission check, that when > granted to users, ensures the data source has been > authenticated.?? This is a server application, not client.?? > Permission to parse data should only be granted to user > principal's.? No user, then the data is untrusted and shouldn't be > parsed. > 3. Create a guard security provider interface to replace permission > checks, to allow developers to focus on their authorization needs, > that would allow us to completely ignore permission checks that > are irrelevant and replace bad implementations like SocketPermission. > 4. Consider simplification of "Voodoo", maybe instead of trying to > check every Thread stack (inheriting call stacks), if there is no > doPrivileged call on the current Thread's stack (reduces shared > state, it's thread confined), then report it and throw a > SecurityException, don't try to inherit thread context, because it > doesn't work for executor tasks.?? Then it will be fixed > downstream instead of allowed to create viral permission checks > that violate the principle of least privilege.?? This is not a > security vulnerability risk, we are only using it for > authorization, not sandboxing and it will make policy files much > shorter, improving readability. > 5. We still use AccessController and AccessControlContext to > establish TLS connections, why break it? > 6. Get a tool to generate policy files (mine's only 653 lines of > code). > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java > 7. https://www.oracle.com/java/technologies/javase/seccodeguide.html#8-5 Class::getProtectionDomain shouldn't return a null ProtectionDomain for Java platform library code (the java library is over-privileged), instead use modules: jrt://java.base, etc, so we can grant permissions to authenticated users instead of code, and in this case to ensure that there is an authenticated user on the stack.? The user is the data source during de-serialization. I added Security::doAs methods that appended a Subject ProtectionDomain, rather than injecting Principal's into every ProtectionDomain on the stack, this does two things, one allows a Subject to be more privileged than some code, that it interacts with and also to reduce the intersection of permissions, in the presence of privileged domains (like the Java platform libraries above), to avoid the security issues described. This method is papering over the underlying problem however, which is excessive privileges granted to code. https://github.com/pfirmstone/JGDMS/blob/abb310f4ece90e31f2444e2368efe3864d3f9c09/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590 Anyone can find problems, it's the solutions to problems that matter. 99% of problems with SM have been solved outside of OpenJDK.?? I can't see maintenance being a major issue if OpenJDK stops treating it like a sandbox, and instead, starts treating it like an authorization layer and reduce its complexity and mostly automate it.?? It doesn't require as much work as you suspect. JGDMS tests are run with security enabled by default, that includes generating TLS certificates, signing them with a test CA, then adding them to trust stores and key stores.? It's been over 10 years since I've run tests without SM enabled, I'm not even sure it works without it. > JEP 411 nukes backward compatibility so it cannot be fixed at all. > > Regards, > > Peter. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jul 29 14:05:34 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Jul 2021 10:05:34 -0400 Subject: Incorrect encoding of PKCS12 bag attributes In-Reply-To: <12842ec5-b129-b437-5897-9ef96a78dfab@siemens.com> References: <12842ec5-b129-b437-5897-9ef96a78dfab@siemens.com> Message-ID: Are you calling the PKCS12Attribute(String, String) constructor from your code? That API currently specifies that String values are encoded as UTF-8, so we could not change the behavior without a specification change. Can you use the PKCS12Attribute(byte[]) constructor instead which takes a DER-encoded value? --Sean On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote: > Folks, > > can someone confirm the following bug or tell me I am too stupid to read > the RFCs: > > I have recently created a PKCS12-based trust store and had one CA from > Hungary with non-ASCII chars in the subject's CN RDN. > > RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1: >> >> friendlyName ATTRIBUTE ::= { >> WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName)) >> EQUALITY MATCHING RULE caseIgnoreMatch >> SINGLE VALUE TRUE >> ID pkcs-9-at-friendlyName >> } > > So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that > Java ignores the RFC and always creates an UTF8String regardless of the > attribute OID, thus breaking the semantics of friendlyName. > > Who's wrong here? > > For some strange reason OpenSSL does it in a similar fashion: > In pkcs12.h.in: > > # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8 > where the function contains: >> if (X509at_add1_attr_by_NID(&bag->attrib, NID_friendlyName, >> MBSTRING_UTF8, (unsigned char *)name, namelen) != NULL) > > > [1] > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/security/PKCS12Attribute.java#L230-L245 > > Regards, > > Michael > From mullan at openjdk.java.net Thu Jul 29 14:32:44 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 29 Jul 2021 14:32:44 GMT Subject: RFR: 8232066: Remove outdated code/methods from PKIX implementation Message-ID: Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING variant and related code that is no longer needed in the PKIX implementation. ------------- Commit messages: - 8232066: Remove outdated code/methods from PKIX implementation Changes: https://git.openjdk.java.net/jdk/pull/4934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4934&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232066 Stats: 182 lines in 7 files changed: 6 ins; 167 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4934/head:pull/4934 PR: https://git.openjdk.java.net/jdk/pull/4934 From weijun at openjdk.java.net Thu Jul 29 15:12:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 29 Jul 2021 15:12:30 GMT Subject: RFR: 8232066: Remove outdated code/methods from PKIX implementation In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 14:24:52 GMT, Sean Mullan wrote: > Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING variant and related code that is no longer needed in the PKIX implementation. Looks good. One nit: `Validator::getInstance` methods are internal. Does it really matter to check for null? ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4934 From rriggs at openjdk.java.net Thu Jul 29 16:44:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 16:44:55 GMT Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Improve the clarity of comments in the ObjectInputFilter FilterInThread example. ------------- Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - 8269763: The JEditorPane is blank after JDK-8265167 - 8265580: Enhanced style for RTF kit - 8265574: Improve handling of sheets - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561 Changes: https://git.openjdk.java.net/jdk17/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod Patch: https://git.openjdk.java.net/jdk17/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk17/pull/292 From mullan at openjdk.java.net Thu Jul 29 17:31:03 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 29 Jul 2021 17:31:03 GMT Subject: RFR: 8232066: Remove outdated code/methods from PKIX implementation [v2] In-Reply-To: References: Message-ID: > Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING variant and related code that is no longer needed in the PKIX implementation. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Remove NPE check in Validator.getInstance. Update ConstructorTest not to test for this case anymore. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4934/files - new: https://git.openjdk.java.net/jdk/pull/4934/files/52be3dd2..b388bb4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4934&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4934&range=00-01 Stats: 26 lines in 2 files changed: 0 ins; 21 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4934/head:pull/4934 PR: https://git.openjdk.java.net/jdk/pull/4934 From mullan at openjdk.java.net Thu Jul 29 17:31:05 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 29 Jul 2021 17:31:05 GMT Subject: RFR: 8232066: Remove outdated code/methods from PKIX implementation [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 15:09:14 GMT, Weijun Wang wrote: > Looks good. One nit: `Validator::getInstance` methods are internal. Does it really matter to check for null? Good point. Also, NPE will be thrown later when an `EndEntityChecker` is invoked and it needs to determine the variant to use. However, I had to change the `ConstructorTest` test not to test for this case anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/4934 From rriggs at openjdk.java.net Thu Jul 29 17:46:36 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 17:46:36 GMT Subject: [jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com> On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread example. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/292 From mullan at openjdk.java.net Fri Jul 30 12:46:31 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 30 Jul 2021 12:46:31 GMT Subject: Integrated: 8232066: Remove outdated code/methods from PKIX implementation In-Reply-To: References: Message-ID: <6DB391VK6Kj5X7Pg2o8AnpuD03NARB-7Di-7Y2FL5ow=.e5aa23e0-b42f-4c99-a779-c4b86bb0f741@github.com> On Thu, 29 Jul 2021 14:24:52 GMT, Sean Mullan wrote: > Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING variant and related code that is no longer needed in the PKIX implementation. This pull request has now been integrated. Changeset: 89f5c96d Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/89f5c96d63a7a08e0b4145eee83a946fc99141e4 Stats: 196 lines in 8 files changed: 0 ins; 182 del; 14 mod 8232066: Remove outdated code/methods from PKIX implementation Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/4934 From iignatyev at openjdk.java.net Fri Jul 30 15:36:35 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 30 Jul 2021 15:36:35 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com> Message-ID: On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > I know that tests fixes could be pushed during RDP2 without approval. > But these one is very big and it is not a fix - it is enhancement. > > What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18. > > And I can't even review it because GutHub UI hangs on these big changes. @vnkozlov, @dholmes-ora, Thank you for looking at this! I want this to be integrated into JDK 17 b/c some "external" libraries use (used to use) WhiteBox API, e.g. jcstress[[2]] used WhiteBox API to deoptimize compiled methods[[3]], and it would be easier for maintainers of such libraries to condition package name based on JDK major version. Also, given JDK 17 is an LTS, it would be beneficial for everyone not to have big differences in test bases b/w it and the mainline. according to JEP 3, test RFEs are allowed until the very end and don't require late enhancement approval: "Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate"[[1]]. So, process-wise, I don't see any issues w/ integrating this RFE, yet, I fully agree that due to its size, this patch can be disruptive and can cause massive failures, which is something we obviously don't want at the current stage of JDK 17. I like David's idea about phasing this clean-up, and, due to the reasons described above, I would like to integrate the first part, copying WhiteBox classes to the new package structure and associated changes w/o updating all the tests, into JDK 17 and update the tests on the mainline (w/ backporting into jdk17u). WDYT? Cheers, -- Igor [1]: https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process [2]: https://github.com/openjdk/jcstress [3]: https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/jcstress-core/src/main/java/org/openjdk/jcstress/vm/WhiteBoxSupport.java ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From valeriep at openjdk.java.net Fri Jul 30 18:56:41 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 30 Jul 2021 18:56:41 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Thu, 22 Jul 2021 17:19:20 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 650: >> >>> 648: int originalOutOfs = 0; >>> 649: byte[] in; >>> 650: byte[] out; >> >> The name "in", "out" are almost used in all calls, it's hard to tell when these two are actually used. Can we rename them to make them more unique? > > ok This is still present in the latest update. Is there another update coming? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 30 18:56:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 30 Jul 2021 18:56:40 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Thu, 22 Jul 2021 17:16:45 GMT, Anthony Scarpino wrote: >> Seems strange to have GCMOperation op defined in GCMEngine but not initialized, nor used. The methods in GCMEngine which use op has an argument named op anyway. Either you just use the "op" field (remove the "op" argument) or the "op" argument (move the op field to GCMEncrypt/GCMDecrypt class). Having both looks confusing. > > Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it This is still present in the latest update. Is there another update coming? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From svkamath at openjdk.java.net Fri Jul 30 18:56:40 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 30 Jul 2021 18:56:40 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 30 Jul 2021 18:23:18 GMT, Valerie Peng wrote: >> Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it > > This is still present in the latest update. Is there another update coming? Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From svkamath at openjdk.java.net Fri Jul 30 18:56:42 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 30 Jul 2021 18:56:42 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 30 Jul 2021 18:23:44 GMT, Valerie Peng wrote: >> ok > > This is still present in the latest update. Is there another update coming? Yes. There will be another update. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From svkamath at openjdk.java.net Fri Jul 30 18:56:43 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 30 Jul 2021 18:56:43 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Mon, 19 Jul 2021 19:18:54 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 717: > >> 715: in = new byte[Math.min(PARALLEL_LEN, srcLen)]; >> 716: out = new byte[Math.min(PARALLEL_LEN, srcLen)]; >> 717: } > > Move this down to else-block below just like the 'ct' variable. I've kept this code as is and not moved as recommended. If we move this line to the else part, the case where srcLen is less than PARALLEL_LEN but greater than BlockSize, in[] is null. As a result, three tests in test/jdk/../Cipher/AEAD were failing on src.get(in, 0, rlen) line. Do let me know if that's okay. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From svkamath at openjdk.java.net Fri Jul 30 19:03:53 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 30 Jul 2021 19:03:53 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v6] In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: > I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - changed file property of GaloisCounterMode.java - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm - Extended jtreg test case, made changes to .cpp and .java files - Updated AES-GCM intrinsic to match latest Java Code - merge master - 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl - Merge master - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions ------------- Changes: https://git.openjdk.java.net/jdk/pull/4019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=05 Stats: 1320 lines in 21 files changed: 1148 ins; 100 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019 From mullan at openjdk.java.net Fri Jul 30 20:12:34 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 30 Jul 2021 20:12:34 GMT Subject: RFR: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked In-Reply-To: References: Message-ID: <3qrQyvageJUpJJBsFpMyZLk41WtV9A168BvxqSFLJoc=.744286d6-952e-4e6a-944a-ee5ac583874c@github.com> On Tue, 20 Jul 2021 23:50:44 GMT, Rajan Halade wrote: > Test certificates are updated. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4849 From mullan at openjdk.java.net Fri Jul 30 20:15:32 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 30 Jul 2021 20:15:32 GMT Subject: RFR: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 23:10:33 GMT, Rajan Halade wrote: > Update the test certificates. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4847 From valeriep at openjdk.java.net Fri Jul 30 20:19:37 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 30 Jul 2021 20:19:37 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Thu, 22 Jul 2021 17:57:13 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 761: >> >>> 759: } >>> 760: >>> 761: dst.put(out, 0, rlen); >> >> This looks belong to the above if-block? I wonder how this have not affected the operation to fail. Perhaps the existing regression tests did not cover the 'rlen < blockSize' case. If the code in the above if-block is not run, this outsize dst.put(...) call would put extra output bytes into the output buffer. > > Yes... this one and the ct offset problem earlier I would have expected the regression test it pick the mistake. There should be tests that catch this.. I'm not sure what's up. This shall be addressed in next update I assume? ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 30 20:19:37 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 30 Jul 2021 20:19:37 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 30 Jul 2021 18:40:14 GMT, Smita Kamath wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 717: >> >>> 715: in = new byte[Math.min(PARALLEL_LEN, srcLen)]; >>> 716: out = new byte[Math.min(PARALLEL_LEN, srcLen)]; >>> 717: } >> >> Move this down to else-block below just like the 'ct' variable. > > I've kept this code as is and not moved as recommended. If we move this line to the else part, the case where srcLen is less than PARALLEL_LEN but greater than BlockSize, in[] is null. As a result, three tests in test/jdk/../Cipher/AEAD were failing on src.get(in, 0, rlen) line. Do let me know if that's okay. Thanks. Hmm, I see. Sure, fine to keep it as is then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From valeriep at openjdk.java.net Fri Jul 30 20:19:38 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 30 Jul 2021 20:19:38 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <9DGzWlRgC8DaSEZFFeOzQJuRvopW8CISMLJwYQAUGTo=.1aa32797-386f-4101-a96d-6cbad78934f7@github.com> Message-ID: On Thu, 22 Jul 2021 22:52:14 GMT, Anthony Scarpino wrote: >> Yes, I know. Basically, we are trying to optimize performance by trying to write into the supplied buffers (out) as much as we can. But then when tag verification failed, the "written" bytes are erased w/ 0. Ideal case would be not to touch the output buffer until after the tag verification succeeds. Isn't this the previous approach? Verify the tag first and then write out the plain text afterwards. > > With this new intrinsic doing both ghash and gctr at the same time, I cannot do the that ghash check first before the gctr op. I wish I could Oh-well, ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From rhalade at openjdk.java.net Fri Jul 30 20:19:55 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 30 Jul 2021 20:19:55 GMT Subject: RFR: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked [v2] In-Reply-To: References: Message-ID: > Test certificates are updated. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8248899 - 8248899: update ProblemList.txt - 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked ------------- Changes: https://git.openjdk.java.net/jdk/pull/4849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4849&range=01 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod Patch: https://git.openjdk.java.net/jdk/pull/4849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4849/head:pull/4849 PR: https://git.openjdk.java.net/jdk/pull/4849 From rhalade at openjdk.java.net Fri Jul 30 20:19:56 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 30 Jul 2021 20:19:56 GMT Subject: Integrated: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 23:50:44 GMT, Rajan Halade wrote: > Test certificates are updated. This pull request has now been integrated. Changeset: d6bb8461 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d6bb846159be7e46fba0c3ca2915617f945e0b42 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4849 From rhalade at openjdk.java.net Fri Jul 30 20:25:50 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 30 Jul 2021 20:25:50 GMT Subject: RFR: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert [v2] In-Reply-To: References: Message-ID: > Update the test certificates. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8263059 - 8263059: update ProblemList.txt - 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert ------------- Changes: https://git.openjdk.java.net/jdk/pull/4847/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4847&range=01 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/4847.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4847/head:pull/4847 PR: https://git.openjdk.java.net/jdk/pull/4847 From rhalade at openjdk.java.net Fri Jul 30 20:32:35 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 30 Jul 2021 20:32:35 GMT Subject: Integrated: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 23:10:33 GMT, Rajan Halade wrote: > Update the test certificates. This pull request has now been integrated. Changeset: 4bc9b049 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/4bc9b049846bd59f5c41bd62a59b567b52c9efc5 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4847 From michael.osipov at siemens.com Fri Jul 30 15:26:48 2021 From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM)) Date: Fri, 30 Jul 2021 17:26:48 +0200 Subject: Incorrect encoding of PKCS12 bag attributes In-Reply-To: References: <12842ec5-b129-b437-5897-9ef96a78dfab@siemens.com> Message-ID: Am 2021-07-29 um 16:05 schrieb Sean Mullan: > Are you calling the PKCS12Attribute(String, String) constructor from > your code? That API currently specifies that String values are encoded > as UTF-8, so we could not change the behavior without a specification > change. Can you use the PKCS12Attribute(byte[]) constructor instead > which takes a DER-encoded value? Hi Sean, I don't use this API. I interact with > KeyStore javaTrustStore = KeyStore.getInstance("PKCS12"); > javaTrustStore.load(null, null); > for (Rdn rdn : ldapName.getRdns()) { > if (rdn.getType().equalsIgnoreCase("CN")) > alias = (String) rdn.getValue(); > } > javaTrustStore .setCertificateEntry(alias, cert); only. So I am using a high level API. But even if I'd use this API and pass the UCS-2 encoded byte array of that cert > CN=NetLock Arany (Class Gold) F?tan?s?tv?ny,OU=Tan?s?tv?nykiad?k (Certification Services),O=NetLock Kft.,L=Budapest,C=HU The ASN.1 tag would still be incorrect for friendlyName (1.2.840.113549.1.9.20) because it would OctetString and not BMPString. It seems to be that the API, or ObjectIdentifier and KnownOIDs classes miss to carry the ASN.1 tag for the actual value. Don't they? Michael PS: This CA > CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon Merkezi,O=E-Tu?ra EBG Bili?im Teknolojileri ve Hizmetleri A.?.,L=Ankara,C=TR was smart enough to stick with US-ASCII only in the CN, but still single-byte != two-byte UCS-2 > On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote: >> Folks, >> >> can someone confirm the following bug or tell me I am too stupid to read >> the RFCs: >> >> I have recently created a PKCS12-based trust store and had one CA from >> Hungary with non-ASCII chars in the subject's CN RDN. >> >> RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1: >>> >>> ??? friendlyName ATTRIBUTE ::= { >>> ??????????? WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName)) >>> ??????????? EQUALITY MATCHING RULE caseIgnoreMatch >>> ??????????? SINGLE VALUE TRUE >>> ??????????? ID pkcs-9-at-friendlyName >>> ??? } >> >> So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that >> Java ignores the RFC and always creates an UTF8String regardless of the >> attribute OID, thus breaking the semantics of friendlyName. >> >> Who's wrong here? >> >> For some strange reason OpenSSL does it in a similar fashion: >> In pkcs12.h.in: >> ? > # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8 >> where the function contains: >>> if (X509at_add1_attr_by_NID(&bag->attrib, NID_friendlyName, >>> ???????????????????????????????? MBSTRING_UTF8, (unsigned char >>> *)name, namelen) != NULL) >> >> >> [1] >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F739769c8fc4b496f08a92225a12d07414537b6c0%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fjava%2Fsecurity%2FPKCS12Attribute.java%23L230-L245&data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7Cc475c3e0ca4b4dffe9e308d9529a0987%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637631643594135158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yi0n7ZEXPHxas%2Fe17phd7ahX%2BXwlFXnCTJsYMqhLyZM%3D&reserved=0 >> >> >> Regards, >> >> Michael >> From peter.firmstone at zeus.net.au Sat Jul 31 03:04:07 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 31 Jul 2021 13:04:07 +1000 Subject: JEP 411, removal of finalizers, a path forward. Message-ID: The current JEP 411 plan of action, if left unchanged, will leave developers who adopted the SM architecture as an authorization layer unable to upgrade to later versions of Java, until finalizers and the finalizer attack defensive methods in constructors are removed.? JEP 411 has the potential to cause significant disruption for a small proportion of Java developers, but doesn't have to if managed appropriately. The blocker is the ability to implement guard checks using Agents on public API, due to finalizer attack defensive private static methods in constructors. Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? Furthermore, as developers must support multiple Java releases, I propose the following amendments, to ease difficulties of multiple release support (with multi release jars): * AccessController, AccessControlContext, DomainCombiner and related Subject and Executors methods, remain until Java 8 is EOL in 2030.? Also consider un-deprecation of these methods, as their removal causes shotgun surgery (used in 1000's of locations in my software alone) and they are required for preservation of Subject, used for obtaining TLS and Kerberos connection credentials on all existing versions of Java. * AccessControlContext - remove inherited thread context, replace it with an unprivileged ProtectionDomain, such that doPrivileged methods are required for authorization checks and only the current thread stack needs to be walked when checks occur, and stack walks aren't unnecessarily performed when creating new threads.?? This is compatible with Loom, update loom to allow the use of AccessControlContext to be used, to establish TLS and Kerberos connections.? Loom will be very useful for network connections, especially long latency connections over the internet, which are typically secured using TLS.?? This removes the problem of viral checks, and Executor task privilege escalation. * Modules that are mapped to the boot loader should get a unique PD that includes a useful code source rather than using a "shared" PD, this allows us to reduce the privileged footprint of the Java platform libraries, to allow privileges to be granted to users, not code, or users and code.? This is useful to limit data parsing privileges to authenticated users on servers (a practise that should be more widely encouraged). * Remove finalizers, and defensive methods in constructors where permissions check points occur as these cause problems for Agents, prior to removal of SecurityManager. * Deprecate for removal Permission implementations, then remove them in a following release. * Remove SecurityManager. This allows a forward migration path for poor sod's like myself who are currently using SM infrastructure as an authorization layer, and to establish TLS conenctions, this or at least some sort of compromise is far preferable to the thermonuclear option currently planned. What I would like OpenJDK to consider, is to allow developers like myself to continue to stay current with Java, by coordinating the removal of finalizers and defensive methods in constructors, with JEP 411, so we have a workable future migration path. Without these considerations, options are; go back to Java 8, and plan to redevelop existing software, if forced to do so, Java is unlikely to be on the list for redevelopment, simply because development costs are lower in newer languages, such as automated unit tests, https://hackage.haskell.org/package/QuickCheck, no need to worry about null pointers and less boilerplate. Don't get me wrong, I like Java and have many years experience with it, but I have to be pragmatic, it won't just be me, many other developers, when Java 8 is EOL, will work for companies stuck on that platform, simply due to the number of changes required, because they haven't kept up (eg budgets) with the current release cadence and pace of development, will be looking at redevelopment and replacement instead of migration.?? Clearly the current pace of development is a good thing for Java, but the overall strategy could be tweaked a little, to ensure migration doesn't become insurmountable.? A healthy and vibrant Java community is essential for the survival of Java, Java has already shed phone and client markets, lets not shed too many more. Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jul 31 07:35:06 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 31 Jul 2021 08:35:06 +0100 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: Message-ID: <7afa85d5-27c7-a35a-d1ed-513cf5b802ec@oracle.com> On 31/07/2021 04:04, Peter Firmstone wrote: > > Allan has advised when finalizers are removed, it will be practical to > use Agents to instrument public API to implement an authorization > layer, this is try, so can it be coordinated with JEP 411 et al? > Our exchange was about instrumenting constructors that specify SM permission checks and where the classes that define these constructors have been hardened to thwart finalizer attacks. It wasn't a comment on the bigger question on how practical it is to use instrumented the entire JDK. Once you get further on then I assume a big challenge will be with APIs that separate the interface and implementation (think factory methods, APIs that define service provider interfaces ...). Here I expect you will want to instrument the implementation classes. Going deeper, you may find places where the SM check isn't on method entry but instead after defensive copying of mutable parameters or after acquiring a lock that prevents mutation while do a security sensitive operations. So non-trivial but a fun approach to explore. If you have the cycles then pick a version and try it. That will give you a sense on how much effort may be required to keep up and be confident that every interesting code path is covered. -Alan From peter.firmstone at zeus.net.au Sat Jul 31 09:05:57 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 31 Jul 2021 19:05:57 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <7afa85d5-27c7-a35a-d1ed-513cf5b802ec@oracle.com> References: <7afa85d5-27c7-a35a-d1ed-513cf5b802ec@oracle.com> Message-ID: <0366dd24-fc82-4274-d862-0913e83b307c@zeus.net.au> I'm potentially watching many years of development efforts burn, due to JEP 411 and trying to find a way to save it, I don't refer to it as fun.? Frustrating, infuriating, irritating, anger, that would more accurately describe the emotions current circumstances create. I'll be focusing only on the following in Java's public API's: 1. Network. 2. File system access. 3. ClassLoading. 4. Properties. The most important task is to prevent class loading from unauthenticated sources. This is intended to sure up perimeter defenses and constrain trusted third parties in our software, these would be wide open if we just switched off SM. I'm following all guidance provided by OpenJDK in this instance. I will wait for finalizers to be removed, before instrumenting any constructors that have finalizer attack defenses.? Hopefully OpenJDK will chose to remove finalizers soon, prior to removal of SM. Regards, Peter. On 31/07/2021 5:35 pm, Alan Bateman wrote: > On 31/07/2021 04:04, Peter Firmstone wrote: >> >> Allan has advised when finalizers are removed, it will be practical >> to use Agents to instrument public API to implement an authorization >> layer, this is try, so can it be coordinated with JEP 411 et al? >> > Our exchange was about instrumenting constructors that specify SM > permission checks and where the classes that define these constructors > have been hardened to thwart finalizer attacks. It wasn't a comment on > the bigger question on how practical it is to use instrumented the > entire JDK. Once you get further on then I assume a big challenge will > be with APIs that separate the interface and implementation (think > factory methods, APIs that define service provider interfaces ...). > Here I expect you will want to instrument the implementation classes. > Going deeper, you may find places where the SM check isn't on method > entry but instead after defensive copying of mutable parameters or > after acquiring a lock that prevents mutation while do a security > sensitive operations. So non-trivial but a fun approach to explore. If > you have the cycles then pick a version and try it. That will give you > a sense on how much effort may be required to keep up and be confident > that every interesting code path is covered. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iignatyev at openjdk.java.net Sat Jul 31 20:42:10 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 31 Jul 2021 20:42:10 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: > Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` > - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` > - `s/sun.hotspot.code/jdk.test.whitebox.code/g` > - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` > - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` > > testing: tier1-4 > > Thanks, > -- Igor Igor Ignatyev 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 12 new commits since the last revision: - fixed ctw build - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class - updated requires.VMProps - updated TEST.ROOT - adjusted hotspot source - added test - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class - removed sun/hotspot/parser/DiagnosticCommand - deprecated sun/hotspot classes disallowed s.h.WhiteBox w/ security manager - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/290/files - new: https://git.openjdk.java.net/jdk17/pull/290/files/8f12f2cf..237e8860 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=00-01 Stats: 3248 lines in 939 files changed: 969 ins; 0 del; 2279 mod Patch: https://git.openjdk.java.net/jdk17/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk17/pull/290 From iignatyev at openjdk.java.net Sat Jul 31 20:51:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 31 Jul 2021 20:51:46 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev 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. Vladimir, David, I've (forced) pushed a smaller version of the renaming. instead of removing `sun.hotspot` classes, it copies them to `jdk.test.whitebox` (w/ `s.h.parser.DiagnosticCommand` being removed as it's used in WhiteBox signature and it was easier to update a few tests that use it), updates hotspot code to register native methods for both `sun.hotspot.WhiteBox` and `jdk.test.whitebox.WhiteBox` classes. To make it easier and not to introduce extra dependency, I've made it impossible to use `s.h.WB` w/ a security manager enabled, otherwise there would be a dependency b/w `s.h.WB` and `j.t.w.WB$WhiteBoxPermission` or there would be 2 permissions. There are no open JDK tests that are impacted by this limitation. With minor tweaks in closed source, the patch successfully passes Oracle's tier1-4. -- Igor ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From ron.pressler at oracle.com Sat Jul 31 08:22:47 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 31 Jul 2021 08:22:47 +0000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: Message-ID: Hi Peter. - JEP 411, like every spec-changing JEP, is meant to allow those that use the removed functionality a migration path forward. The API elements that are deprecated for removal have some years before they are actually removed, so there?s nothing too urgent other than beginning to think of a migration path. I think it?s still too soon to consider concrete suggestions for change, especially non-trivial ones. - If by Java 8 EOL you mean the time when the last vendor offers extended support for it, then 2030 is, I believe, the *earliest* possible date that is guaranteed *now. It?s possible that support would be extended until 2130. Such offerings have no bearing on the development of current JDK versions. - The number of significant code changes required since JDK 8 to keep up with current JDK releases is, for the vast majority of Java users, low (what?s affected most users is reliance on non-spec-compliant libraries, and the need to import the external artefacts for EE). The most impactful change has probably been the removal of some client deployment technologies from the Oracle JDK, but as far as OpenJDK is concerned, the affected areas have been CORBA, pack200, Nashorn, and now the process to remove SM is starting. The number of people using any one of these is low, and the number of those who need to work hard for alternatives is very low. I think that advance warning, and then support offerings by multiple vendors for those who have not managed to migrate in the advance warning period is reasonable; always offering ways to support removed technologies together with new features in current releases with the same code base is not. When compared with other ecosystems, Java?s strategy is exceptionally tolerant of those that prefer slow change. - Property-based testing is wonderful, I wish more people would use it, and I hope to see it used in the JDK as well. Java has several PBT tools, but I believe the most popular one these days is https://jqwik.net/. As long as you?re still with Java, give it a try. ? Ron > On 31 Jul 2021, at 04:04, Peter Firmstone wrote: > > The current JEP 411 plan of action, if left unchanged, will leave developers who adopted the SM architecture as an authorization layer unable to upgrade to later versions of Java, until finalizers and the finalizer attack defensive methods in constructors are removed. JEP 411 has the potential to cause significant disruption for a small proportion of Java developers, but doesn't have to if managed appropriately. > > The blocker is the ability to implement guard checks using Agents on public API, due to finalizer attack defensive private static methods in constructors. > > Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? > > Furthermore, as developers must support multiple Java releases, I propose the following amendments, to ease difficulties of multiple release support (with multi release jars): > > * AccessController, AccessControlContext, DomainCombiner and related > Subject and Executors methods, remain until Java 8 is EOL in 2030. > Also consider un-deprecation of these methods, as their removal > causes shotgun surgery (used in 1000's of locations in my software > alone) and they are required for preservation of Subject, used for > obtaining TLS and Kerberos connection credentials on all existing > versions of Java. > * AccessControlContext - remove inherited thread context, replace it > with an unprivileged ProtectionDomain, such that doPrivileged > methods are required for authorization checks and only the current > thread stack needs to be walked when checks occur, and stack walks > aren't unnecessarily performed when creating new threads. This is > compatible with Loom, update loom to allow the use of > AccessControlContext to be used, to establish TLS and Kerberos > connections. Loom will be very useful for network connections, > especially long latency connections over the internet, which are > typically secured using TLS. This removes the problem of viral > checks, and Executor task privilege escalation. > * Modules that are mapped to the boot loader should get a unique PD > that includes a useful code source rather than using a "shared" PD, > this allows us to reduce the privileged footprint of the Java > platform libraries, to allow privileges to be granted to users, not > code, or users and code. This is useful to limit data parsing > privileges to authenticated users on servers (a practise that should > be more widely encouraged). > * Remove finalizers, and defensive methods in constructors where > permissions check points occur as these cause problems for Agents, > prior to removal of SecurityManager. > * Deprecate for removal Permission implementations, then remove them > in a following release. > * Remove SecurityManager. > > This allows a forward migration path for poor sod's like myself who are currently using SM infrastructure as an authorization layer, and to establish TLS conenctions, this or at least some sort of compromise is far preferable to the thermonuclear option currently planned. > > What I would like OpenJDK to consider, is to allow developers like myself to continue to stay current with Java, by coordinating the removal of finalizers and defensive methods in constructors, with JEP 411, so we have a workable future migration path. Without these considerations, options are; go back to Java 8, and plan to redevelop existing software, if forced to do so, Java is unlikely to be on the list for redevelopment, simply because development costs are lower in newer languages, such as automated unit tests, https://hackage.haskell.org/package/QuickCheck, no need to worry about null pointers and less boilerplate. > > Don't get me wrong, I like Java and have many years experience with it, but I have to be pragmatic, it won't just be me, many other developers, when Java 8 is EOL, will work for companies stuck on that platform, simply due to the number of changes required, because they haven't kept up (eg budgets) with the current release cadence and pace of development, will be looking at redevelopment and replacement instead of migration. Clearly the current pace of development is a good thing for Java, but the overall strategy could be tweaked a little, to ensure migration doesn't become insurmountable. A healthy and vibrant Java community is essential for the survival of Java, Java has already shed phone and client markets, lets not shed too many more. > > Thanks, > > Peter >