Integrated: 8252204: AArch64: Implement SHA3 accelerator/intrinsic
On Wed, 16 Sep 2020 16:36:54 GMT, Fei Yang wrote: > Contributed-by: ard.biesheu...@linaro.org, dong...@huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto > Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding > the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for > the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to > differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports > SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on > aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no > regression. > > We used one existing JMH test for performance test: > test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 > digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can > auto-enable this when it is fully tested on real hardware. But for the above > testing purposes, this is auto-enabled when the corresponding hardware > feature is detected. This pull request has now been integrated. Changeset: b25d8940 Author:Fei Yang URL: https://git.openjdk.java.net/jdk/commit/b25d8940 Stats: 1265 lines in 36 files changed: 1010 ins; 22 del; 233 mod 8252204: AArch64: Implement SHA3 accelerator/intrinsic Co-authored-by: Ard Biesheuvel Co-authored-by: Dong Bo Reviewed-by: aph, kvn - PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
On Thu, 22 Oct 2020 03:59:45 GMT, Vladimir Kozlov wrote: > tier1,2,3 passed. I verified that new SHA3 tests were run and passed. > But because SHA3 is not enabled for now (even on aarch64), it does not test > asm code. > At least testing verified that changes in shared code does not cause any > issues. Great to hear that :-) Thanks for the effect. With that testing result and reviewing from three reviewers, I think it's safe to integrate. - PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
On Wed, 21 Oct 2020 23:42:33 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheu...@linaro.org, dong...@huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto >> Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding >> the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for >> the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to >> differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports >> SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on >> aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no >> regression. >> >> We used one existing JMH test for performance test: >> test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 >> digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can >> auto-enable this when it is fully tested on real hardware. But for the >> above testing purposes, this is auto-enabled when the corresponding hardware >> feature is detected. > > Fei Yang has updated the pull request incrementally with one additional > commit since the last revision: > > Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java tier1,2,3 passed. I verified that new SHA3 tests were run and passed. But because SHA3 is not enabled for now (even on aarch64), it does not test asm code. At least testing verified that changes in shared code does not cause any issues. - Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
On Wed, 21 Oct 2020 19:20:28 GMT, Vladimir Kozlov wrote:
>> OK. Will update with the following change after Aleksey's PR is integrated:
>>
>> ---
>> a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>> +++
>> b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>> @@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
>> if (!config.useSHA512Intrinsics()) {
>> add(ignore, "sun/security/provider/SHA5." + shaCompressName +
>> "([BI)V");
>> }
>> +
>> +if (isJDK16OrHigher()) {
>> +add(toBeInvestigated, "sun/security/provider/SHA3." +
>> shaCompressName + "([BI)V");
>> +}
>> }
>
> Yes, please, do that.
Done.
Commit:
https://github.com/openjdk/jdk/pull/207/commits/b43f91970d44e6e0c1b3b4ef452ec388ecbecb83
I think this will not conflict with Aleksey's PR as we modify in different
places of CheckGraalIntrinsics.java
-
PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
> Contributed-by: ard.biesheu...@linaro.org, dong...@huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto > Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding > the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for > the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to > differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports > SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on > aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no > regression. > > We used one existing JMH test for performance test: > test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 > digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can > auto-enable this when it is fully tested on real hardware. But for the above > testing purposes, this is auto-enabled when the corresponding hardware > feature is detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java - Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/d32c8ad7..b43f9197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=09-10 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207
Integrated: 8199697: FIPS 186-4 RSA Key Generation
On Wed, 30 Sep 2020 03:25:06 GMT, Valerie Peng wrote: > Could someone please help review this RFE? Update existing RSA key pair > generation code following the guidelines from FIPS 186-4 and FIPS 186-5 > (draft). Current proposed changes updates the prime generation code (for P, > Q) based on FIPS 186-4 B.3.3 when keysize and public exponent met the > requirements set in FIPS 186-4/5. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 1191a633 Author:Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/1191a633 Stats: 176 lines in 2 files changed: 108 ins; 22 del; 46 mod 8199697: FIPS 186-4 RSA Key Generation Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/420
Re: RFR CSR: JDK-8254709 (Support for EdDSA signature scheme in JSSE)
On 10/21/2020 1:01 PM, Jamil Nimeh wrote: I'm not very sure why EdDSA cannot apply to ServerKeyExchange and CertificateVerify in TLS 1.0 and 1.1. ServerKeyExchange and CertificateVerify is used to authenticate the server or the client's possession of the private key of the cert. So if EdDSA cannot be used for them, the EdDSA certificate should not be selected for TLS 1.0/1.1 as well. I did not read the RFC fully yet, it looks like that EdDSA can be used for TLS 1.0/1.1 ServerKeyExchange and CertificateVerify as well. I may miss something. JN: So far I have yet to find a server implementation that will accept a 1.0/1.1 client hello with no signature_algorithms extension and not barf. It's OK if we don't want to support EdDSA for TLS 1.0/1.1 for some reason. Although I would prefer to support for better interoperability. I did not get the idea of the CSR. It may be nice to have a explicit statement that we don't support certificates of EdDSA-capable public key for TLS 1.0 and 1.1. Xuelei
Re: RFR CSR: JDK-8254709 (Support for EdDSA signature scheme in JSSE)
Hi Xuelei, thanks for the comments. I'll respond in-line: On 10/21/2020 11:52 AM, Xuelei Fan wrote: Hi Jamil, Sorry for delay. It took a few days before I was able to read the CSR. Just a few comments for your consideration. In the specification section, you mentioned how to disable the algorithms. It might not be necessary. It is just something we need to implement so that it does not break the mechanism. JN: I was under the impression that where System/Security properties have an impact on the feature that we typically make note of it. I'm not very sure of the order of EdDSA in the signature algorithms. EdDSA and EdDSA certificate are not popular yet. I'm fine with the order. Would you mind to share your consideration of the preference? No real consideration. All I did was remove the explicit disable code in SignatureScheme.java:278 - 286. The ordering in the enumeration then shows up in the signature_algorithms[_cert] extensions. Ed* schemes could be moved down a bit in the enumeration if we think that will make a difference. I think it would only matter if a server or client had both ECC and EdDSA keyed certs that would be up for selection. There are other implementations that do have Ed* signature schemes a little further down in their lists. The list of signature schemes is out of the quote box and hard to read. I may just list one scheme one line in one quote box, like: + ed25519 + ed448 ecdsa_secp256r1_sha256 JN: I could do that. I was trying to avoid having it be a mile long, but if it's not rendering horizontally then I'll change it. I suppose it doesn't have to be the list of all sig schemes. Just a few lines of context on either side of the new signature schemes should drive the point home and keep it succinct. I'm not very sure why EdDSA cannot apply to ServerKeyExchange and CertificateVerify in TLS 1.0 and 1.1. ServerKeyExchange and CertificateVerify is used to authenticate the server or the client's possession of the private key of the cert. So if EdDSA cannot be used for them, the EdDSA certificate should not be selected for TLS 1.0/1.1 as well. I did not read the RFC fully yet, it looks like that EdDSA can be used for TLS 1.0/1.1 ServerKeyExchange and CertificateVerify as well. I may miss something. JN: So far I have yet to find a server implementation that will accept a 1.0/1.1 client hello with no signature_algorithms extension and not barf. This of course assumes that the server only has EdDSA keyed TLS certificates. As I mentioned to you on the side, if it's RSA/DSA/ECC and has an EdDSA signature, then things work great. To be fair, I haven't experimented with anything other than my modified JSSE and OpenSSL so far. Hope it helps. Xuelei On 10/13/2020 10:59 AM, Jamil Nimeh wrote: Hi Folks, I just put out the draft CSR for the RFE that adds EdDSA support in JSSE. If anyone has some spare cycles to review this I'd appreciate it. https://bugs.openjdk.java.net/browse/JDK-8254709 Thanks, --Jamil
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
On Wed, 21 Oct 2020 09:19:57 GMT, Fei Yang wrote:
> > Someone in Oracle have to run tier1-tier3 testing with these changes to
> > make sure nothing is broken. I don't want to repeat 8254790.
>
> That's appreciated.
> On my side, I run tier1-tier3 both on aarch64 linux and x86_64 linux.
> The test result on these two platforms looks good for the latest changes.
I started testing of 09: version.
>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>> line 604:
>>
>>> 602: add(ignore, "sun/security/provider/SHA5." +
>>> shaCompressName + "([BI)V");
>>> 603: }
>>> 604: add(toBeInvestigated, "sun/security/provider/SHA3." +
>>> shaCompressName + "([BI)V");
>>
>> This should be under `if (isJDK16OrHigher())` check. Something like this:
>> https://github.com/openjdk/jdk/pull/650/files#diff-d1f378fc1b7fe041309e854d40b3a95a91e63fdecf0ecd9826b7c95eaeba314eR527
>> You can wait when Aleksey push it and update your changes
>
> OK. Will update with the following change after Aleksey's PR is integrated:
>
> ---
> a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> +++
> b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> @@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
> if (!config.useSHA512Intrinsics()) {
> add(ignore, "sun/security/provider/SHA5." + shaCompressName +
> "([BI)V");
> }
> +
> +if (isJDK16OrHigher()) {
> +add(toBeInvestigated, "sun/security/provider/SHA3." +
> shaCompressName + "([BI)V");
> +}
> }
Yes, please, do that.
-
PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]
On Tue, 20 Oct 2020 17:23:26 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393 [2] and associated pull request [3]). >> >> The main goal of this API is to provide a way to call native functions from >> Java code without the need of intermediate JNI glue code. In order to do >> this, native calls are modeled through the MethodHandle API. I suggest >> reading the writeup [4] I put together few weeks ago, which illustrates what >> the foreign linker support is, and how it should be used by clients. >> >> Disclaimer: the pull request mechanism isn't great at managing *dependent* >> reviews. For this reasons, I'm attaching a webrev which contains only the >> differences between this PR and the memory access PR. I will be periodically >> uploading new webrevs, as new iterations come out, to try and make the life >> of reviewers as simple as possible. >> >> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main >> architects of all the hotspot changes you see here, and without their help, >> the foreign linker support wouldn't be what it is today. As usual, a big >> thank to Paul Sandoz, who provided many insights (often by trying the bits >> first hand). >> >> Thanks >> Maurizio >> >> Webrev: >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html >> >> Specdiff (relative to [3]): >> >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html >> >> CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254232 >> >> >> >> ### API Changes >> >> The API changes are actually rather slim: >> >> * `LibraryLookup` >> * This class allows clients to lookup symbols in native libraries; the >> interface is fairly simple; you can load a library by name, or absolute >> path, and then lookup symbols on that library. >> * `FunctionDescriptor` >> * This is an abstraction that is very similar, in spirit, to `MethodType`; >> it is, at its core, an aggregate of memory layouts for the function >> arguments/return type. A function descriptor is used to describe the >> signature of a native function. >> * `CLinker` >> * This is the real star of the show. A `CLinker` has two main methods: >> `downcallHandle` and `upcallStub`; the first takes a native symbol (as >> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` >> and returns a `MethodHandle` instance which can be used to call the target >> native symbol. The second takes an existing method handle, and a >> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a >> code stub allocated by the VM which acts as a trampoline from native code to >> the user-provided method handle. This is very useful for implementing >> upcalls. >>* This class also contains the various layout constants that should be >> used by clients when describing native signatures (e.g. `C_LONG` and >> friends); these layouts contain additional ABI classfication information (in >> the form of layout attributes) which is used by the runtime to *infer* how >> Java arguments should be shuffled for the native call to take place. >> * Finally, this class provides some helper functions e.g. so that clients >> can convert Java strings into C strings and back. >> * `NativeScope` >> * This is an helper class which allows clients to group together logically >> related allocations; that is, rather than allocating separate memory >> segments using separate *try-with-resource* constructs, a `NativeScope` >> allows clients to use a _single_ block, and allocate all the required >> segments there. This is not only an usability boost, but also a performance >> boost, since not all allocation requests will be turned into `malloc` calls. >> * `MemorySegment` >> * Only one method added here - namely `handoff(NativeScope)` which allows >> a segment to be transferred onto an existing native scope. >> >> ### Safety >> >> The foreign linker API is intrinsically unsafe; many things can go wrong >> when requesting a native method handle. For instance, the description of the >> native signature might be wrong (e.g. have too many arguments) - and the >> runtime has, in the general case, no way to detect such mismatches. For >> these reasons, obtaining a `CLinker` instance is a *restricted* operation, >> which can be enabled by specifying the usual JDK property >> `-Dforeign.restricted=permit` (as it's the case for other restricted method >> in the foreign memory API). >> >> ### Implementation changes >> >> The Java changes associated with `LibraryLookup` are relative >> straightforward; the only interesting thing to note here is that library
Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]
On Wed, 21 Oct 2020 11:33:27 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393 [2] and associated pull request [3]). >> >> The main goal of this API is to provide a way to call native functions from >> Java code without the need of intermediate JNI glue code. In order to do >> this, native calls are modeled through the MethodHandle API. I suggest >> reading the writeup [4] I put together few weeks ago, which illustrates what >> the foreign linker support is, and how it should be used by clients. >> >> Disclaimer: the pull request mechanism isn't great at managing *dependent* >> reviews. For this reasons, I'm attaching a webrev which contains only the >> differences between this PR and the memory access PR. I will be periodically >> uploading new webrevs, as new iterations come out, to try and make the life >> of reviewers as simple as possible. >> >> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main >> architects of all the hotspot changes you see here, and without their help, >> the foreign linker support wouldn't be what it is today. As usual, a big >> thank to Paul Sandoz, who provided many insights (often by trying the bits >> first hand). >> >> Thanks >> Maurizio >> >> Webrev: >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html >> >> Specdiff (relative to [3]): >> >> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html >> >> CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254232 >> >> >> >> ### API Changes >> >> The API changes are actually rather slim: >> >> * `LibraryLookup` >> * This class allows clients to lookup symbols in native libraries; the >> interface is fairly simple; you can load a library by name, or absolute >> path, and then lookup symbols on that library. >> * `FunctionDescriptor` >> * This is an abstraction that is very similar, in spirit, to `MethodType`; >> it is, at its core, an aggregate of memory layouts for the function >> arguments/return type. A function descriptor is used to describe the >> signature of a native function. >> * `CLinker` >> * This is the real star of the show. A `CLinker` has two main methods: >> `downcallHandle` and `upcallStub`; the first takes a native symbol (as >> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` >> and returns a `MethodHandle` instance which can be used to call the target >> native symbol. The second takes an existing method handle, and a >> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a >> code stub allocated by the VM which acts as a trampoline from native code to >> the user-provided method handle. This is very useful for implementing >> upcalls. >>* This class also contains the various layout constants that should be >> used by clients when describing native signatures (e.g. `C_LONG` and >> friends); these layouts contain additional ABI classfication information (in >> the form of layout attributes) which is used by the runtime to *infer* how >> Java arguments should be shuffled for the native call to take place. >> * Finally, this class provides some helper functions e.g. so that clients >> can convert Java strings into C strings and back. >> * `NativeScope` >> * This is an helper class which allows clients to group together logically >> related allocations; that is, rather than allocating separate memory >> segments using separate *try-with-resource* constructs, a `NativeScope` >> allows clients to use a _single_ block, and allocate all the required >> segments there. This is not only an usability boost, but also a performance >> boost, since not all allocation requests will be turned into `malloc` calls. >> * `MemorySegment` >> * Only one method added here - namely `handoff(NativeScope)` which allows >> a segment to be transferred onto an existing native scope. >> >> ### Safety >> >> The foreign linker API is intrinsically unsafe; many things can go wrong >> when requesting a native method handle. For instance, the description of the >> native signature might be wrong (e.g. have too many arguments) - and the >> runtime has, in the general case, no way to detect such mismatches. For >> these reasons, obtaining a `CLinker` instance is a *restricted* operation, >> which can be enabled by specifying the usual JDK property >> `-Dforeign.restricted=permit` (as it's the case for other restricted method >> in the foreign memory API). >> >> ### Implementation changes >> >> The Java changes associated with `LibraryLookup` are relative >> straightforward; the only interesting thing to note here is that library
Re: RFR CSR: JDK-8254709 (Support for EdDSA signature scheme in JSSE)
Hi Jamil, Sorry for delay. It took a few days before I was able to read the CSR. Just a few comments for your consideration. In the specification section, you mentioned how to disable the algorithms. It might not be necessary. It is just something we need to implement so that it does not break the mechanism. I'm not very sure of the order of EdDSA in the signature algorithms. EdDSA and EdDSA certificate are not popular yet. I'm fine with the order. Would you mind to share your consideration of the preference? The list of signature schemes is out of the quote box and hard to read. I may just list one scheme one line in one quote box, like: + ed25519 + ed448 ecdsa_secp256r1_sha256 I'm not very sure why EdDSA cannot apply to ServerKeyExchange and CertificateVerify in TLS 1.0 and 1.1. ServerKeyExchange and CertificateVerify is used to authenticate the server or the client's possession of the private key of the cert. So if EdDSA cannot be used for them, the EdDSA certificate should not be selected for TLS 1.0/1.1 as well. I did not read the RFC fully yet, it looks like that EdDSA can be used for TLS 1.0/1.1 ServerKeyExchange and CertificateVerify as well. I may miss something. Hope it helps. Xuelei On 10/13/2020 10:59 AM, Jamil Nimeh wrote: Hi Folks, I just put out the draft CSR for the RFE that adds EdDSA support in JSSE. If anyone has some spare cycles to review this I'd appreciate it. https://bugs.openjdk.java.net/browse/JDK-8254709 Thanks, --Jamil
Re: ldap.mechsAllowedToSendCredentials - only SASL?
And just to add to my confusion, this seems that it only checks when
STARTTLS is actually requested but not used?
This code really needs revised documentation.
+// If current connection is not encrypted, and context seen
to be secured with STARTTLS+// or
'mechsAllowedToSendCredentials' is set to any value via system/context
environment properties+if (!isConnectionEncrypted() &&
(contextSeenStartTlsEnabled || anyPropertyIsSet)) {
Am Mi., 21. Okt. 2020 um 19:26 Uhr schrieb Bernd :
> BTW: the security patch looks like "simple" is supposed to be rejected
> when a principal is set, however this is not the case in my tests. Maybe
> the method is not called correctly in this case?
>
> if ("simple".equalsIgnoreCase(authMechanism) &&
> !envprops.containsKey(SECURITY_PRINCIPAL)) {
>
> Gruss
> Bernd
>
> Am Mi., 21. Okt. 2020 um 18:21 Uhr schrieb Bernd :
>
>> Hello,
>>
>> I am looking at 11.0.9 PSU (as of Zulu 11.43-sa) about the
>> CVE-2020-14781 / JDK-8237990 fix and try to understand if my customers
>> might be affected.
>>
>> jdk.jndi.ldap.mechsAllowedToSendCredentials
>>
>> It was not obvious to me, how the mechanism restriction works.
>>
>> According to Oracle and Redhat release notes it only looks at clear /
>> non-TLS.
>>
>> - Can you confirm that SASL with wrapping is not considered as encrypted
>> in this case?
>>
>> - Can you confirm it only applies to SASL based negotiation? (in my test
>> SIMPLE with cleartext passwords works just fine)
>>
>> - Can you confirm it does not apply to "secure" mechanisms like
>> DIGEST-MD5 or different methods like GSSAPI or SIMPLE?
>>
>> Gruss
>> Bernd
>>
>
Re: ldap.mechsAllowedToSendCredentials - only SASL?
BTW: the security patch looks like "simple" is supposed to be rejected when
a principal is set, however this is not the case in my tests. Maybe the
method is not called correctly in this case?
if ("simple".equalsIgnoreCase(authMechanism) &&
!envprops.containsKey(SECURITY_PRINCIPAL)) {
Gruss
Bernd
Am Mi., 21. Okt. 2020 um 18:21 Uhr schrieb Bernd :
> Hello,
>
> I am looking at 11.0.9 PSU (as of Zulu 11.43-sa) about the CVE-2020-14781
> / JDK-8237990 fix and try to understand if my customers might be
> affected.
>
> jdk.jndi.ldap.mechsAllowedToSendCredentials
>
> It was not obvious to me, how the mechanism restriction works.
>
> According to Oracle and Redhat release notes it only looks at clear /
> non-TLS.
>
> - Can you confirm that SASL with wrapping is not considered as encrypted
> in this case?
>
> - Can you confirm it only applies to SASL based negotiation? (in my test
> SIMPLE with cleartext passwords works just fine)
>
> - Can you confirm it does not apply to "secure" mechanisms like DIGEST-MD5
> or different methods like GSSAPI or SIMPLE?
>
> Gruss
> Bernd
>
ldap.mechsAllowedToSendCredentials - only SASL?
Hello, I am looking at 11.0.9 PSU (as of Zulu 11.43-sa) about the CVE-2020-14781 / JDK-8237990 fix and try to understand if my customers might be affected. jdk.jndi.ldap.mechsAllowedToSendCredentials It was not obvious to me, how the mechanism restriction works. According to Oracle and Redhat release notes it only looks at clear / non-TLS. - Can you confirm that SASL with wrapping is not considered as encrypted in this case? - Can you confirm it only applies to SASL based negotiation? (in my test SIMPLE with cleartext passwords works just fine) - Can you confirm it does not apply to "secure" mechanisms like DIGEST-MD5 or different methods like GSSAPI or SIMPLE? Gruss Bernd
Integrated: 8242068: Signed JAR support for RSASSA-PSS and EdDSA
On Wed, 23 Sep 2020 14:41:59 GMT, Weijun Wang wrote: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in > jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a > signed JAR) are reused for new signature algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as > SignerInfo::signatureAlgorithm. We used to use the encryption algorithm there > like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to > SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify > creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all > old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once > ContentSigner is removed This pull request has now been integrated. Changeset: 839f01dd Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/839f01dd Stats: 1869 lines in 24 files changed: 1132 ins; 558 del; 179 mod 8242068: Signed JAR support for RSASSA-PSS and EdDSA Reviewed-by: valeriep - PR: https://git.openjdk.java.net/jdk/pull/322
Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]
On Mon, 19 Oct 2020 11:24:45 GMT, Jorn Vernee wrote: >> I looked through some Hotspot runtime code and that looks ok. I saw a >> couple of strange things on my way through the code. See comments. > > Hi David, this code somewhat predates me, so I initially kept the JVM_ENTRY > since that was what was already in place. IIRC the thread state transition > was added later to be able to call JNI code, which checks that the thread > state is native in some asserts. > > I've re-written this code, per @coleenp 's suggestion, to use VM code > directly to replace what we were doing with JNI, so the thread state > transition is also gone. > > I've looked at some of the *_ENTRY macros and the only one that seems to > avoid the thread state transition is JVM_LEAF. I've switched the > RegisterNatives functions we use to JVM_LEAF to avoid the redundant > transitions. I also tried changing `PI_invokeNative` to JVM_LEAF, but since > we can call back into Java from that, I run into a missing handle mark assert > for some of the tests, so I've left that one as JVM_ENTRY (but removed some > redundant braces). > > I've created a separate sub-pr against this PR's branch to make it easier to > see what I've changed: https://github.com/mcimadamore/jdk/pull/1 (feel free > to take a look). > > Thanks for the comments. I've fixed the following issues from review comments: - don't rely on `MethodHandles::adapter_code_size` (after private discussion) - update copyright years - use VM-internal API instead of JNI when parsing ABIDescriptor and BufferLayout objects while generating down/up call wrappers. As far as I see, that covers all open review comments. - PR: https://git.openjdk.java.net/jdk/pull/634
Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]
> This patch contains the changes associated with the first incubation round of > the foreign linker access API incubation > (see JEP 389 [1]). This work is meant to sit on top of the foreign memory > access support (see JEP 393 [2] and associated pull request [3]). > > The main goal of this API is to provide a way to call native functions from > Java code without the need of intermediate JNI glue code. In order to do > this, native calls are modeled through the MethodHandle API. I suggest > reading the writeup [4] I put together few weeks ago, which illustrates what > the foreign linker support is, and how it should be used by clients. > > Disclaimer: the pull request mechanism isn't great at managing *dependent* > reviews. For this reasons, I'm attaching a webrev which contains only the > differences between this PR and the memory access PR. I will be periodically > uploading new webrevs, as new iterations come out, to try and make the life > of reviewers as simple as possible. > > A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects > of all the hotspot changes you see here, and without their help, the foreign > linker support wouldn't be what it is today. As usual, a big thank to Paul > Sandoz, who provided many insights (often by trying the bits first hand). > > Thanks > Maurizio > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff (relative to [3]): > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254232 > > > > ### API Changes > > The API changes are actually rather slim: > > * `LibraryLookup` > * This class allows clients to lookup symbols in native libraries; the > interface is fairly simple; you can load a library by name, or absolute path, > and then lookup symbols on that library. > * `FunctionDescriptor` > * This is an abstraction that is very similar, in spirit, to `MethodType`; > it is, at its core, an aggregate of memory layouts for the function > arguments/return type. A function descriptor is used to describe the > signature of a native function. > * `CLinker` > * This is the real star of the show. A `CLinker` has two main methods: > `downcallHandle` and `upcallStub`; the first takes a native symbol (as > obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and > returns a `MethodHandle` instance which can be used to call the target native > symbol. The second takes an existing method handle, and a > `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a > code stub allocated by the VM which acts as a trampoline from native code to > the user-provided method handle. This is very useful for implementing upcalls. >* This class also contains the various layout constants that should be > used by clients when describing native signatures (e.g. `C_LONG` and > friends); these layouts contain additional ABI classfication information (in > the form of layout attributes) which is used by the runtime to *infer* how > Java arguments should be shuffled for the native call to take place. > * Finally, this class provides some helper functions e.g. so that clients > can convert Java strings into C strings and back. > * `NativeScope` > * This is an helper class which allows clients to group together logically > related allocations; that is, rather than allocating separate memory segments > using separate *try-with-resource* constructs, a `NativeScope` allows clients > to use a _single_ block, and allocate all the required segments there. This > is not only an usability boost, but also a performance boost, since not all > allocation requests will be turned into `malloc` calls. > * `MemorySegment` > * Only one method added here - namely `handoff(NativeScope)` which allows a > segment to be transferred onto an existing native scope. > > ### Safety > > The foreign linker API is intrinsically unsafe; many things can go wrong when > requesting a native method handle. For instance, the description of the > native signature might be wrong (e.g. have too many arguments) - and the > runtime has, in the general case, no way to detect such mismatches. For these > reasons, obtaining a `CLinker` instance is a *restricted* operation, which > can be enabled by specifying the usual JDK property > `-Dforeign.restricted=permit` (as it's the case for other restricted method > in the foreign memory API). > > ### Implementation changes > > The Java changes associated with `LibraryLookup` are relative > straightforward; the only interesting thing to note here is that library > loading does _not_ depend on class loaders, so `LibraryLookup` is not subject > to the same restrictions which apply to JNI library loading (e.g. same > library can
Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v8]
> This patch contains the changes associated with the first incubation round of > the foreign linker access API incubation > (see JEP 389 [1]). This work is meant to sit on top of the foreign memory > access support (see JEP 393 [2] and associated pull request [3]). > > The main goal of this API is to provide a way to call native functions from > Java code without the need of intermediate JNI glue code. In order to do > this, native calls are modeled through the MethodHandle API. I suggest > reading the writeup [4] I put together few weeks ago, which illustrates what > the foreign linker support is, and how it should be used by clients. > > Disclaimer: the pull request mechanism isn't great at managing *dependent* > reviews. For this reasons, I'm attaching a webrev which contains only the > differences between this PR and the memory access PR. I will be periodically > uploading new webrevs, as new iterations come out, to try and make the life > of reviewers as simple as possible. > > A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects > of all the hotspot changes you see here, and without their help, the foreign > linker support wouldn't be what it is today. As usual, a big thank to Paul > Sandoz, who provided many insights (often by trying the bits first hand). > > Thanks > Maurizio > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff (relative to [3]): > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254232 > > > > ### API Changes > > The API changes are actually rather slim: > > * `LibraryLookup` > * This class allows clients to lookup symbols in native libraries; the > interface is fairly simple; you can load a library by name, or absolute path, > and then lookup symbols on that library. > * `FunctionDescriptor` > * This is an abstraction that is very similar, in spirit, to `MethodType`; > it is, at its core, an aggregate of memory layouts for the function > arguments/return type. A function descriptor is used to describe the > signature of a native function. > * `CLinker` > * This is the real star of the show. A `CLinker` has two main methods: > `downcallHandle` and `upcallStub`; the first takes a native symbol (as > obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and > returns a `MethodHandle` instance which can be used to call the target native > symbol. The second takes an existing method handle, and a > `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a > code stub allocated by the VM which acts as a trampoline from native code to > the user-provided method handle. This is very useful for implementing upcalls. >* This class also contains the various layout constants that should be > used by clients when describing native signatures (e.g. `C_LONG` and > friends); these layouts contain additional ABI classfication information (in > the form of layout attributes) which is used by the runtime to *infer* how > Java arguments should be shuffled for the native call to take place. > * Finally, this class provides some helper functions e.g. so that clients > can convert Java strings into C strings and back. > * `NativeScope` > * This is an helper class which allows clients to group together logically > related allocations; that is, rather than allocating separate memory segments > using separate *try-with-resource* constructs, a `NativeScope` allows clients > to use a _single_ block, and allocate all the required segments there. This > is not only an usability boost, but also a performance boost, since not all > allocation requests will be turned into `malloc` calls. > * `MemorySegment` > * Only one method added here - namely `handoff(NativeScope)` which allows a > segment to be transferred onto an existing native scope. > > ### Safety > > The foreign linker API is intrinsically unsafe; many things can go wrong when > requesting a native method handle. For instance, the description of the > native signature might be wrong (e.g. have too many arguments) - and the > runtime has, in the general case, no way to detect such mismatches. For these > reasons, obtaining a `CLinker` instance is a *restricted* operation, which > can be enabled by specifying the usual JDK property > `-Dforeign.restricted=permit` (as it's the case for other restricted method > in the foreign memory API). > > ### Implementation changes > > The Java changes associated with `LibraryLookup` are relative > straightforward; the only interesting thing to note here is that library > loading does _not_ depend on class loaders, so `LibraryLookup` is not subject > to the same restrictions which apply to JNI library loading (e.g. same > library can
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
On Tue, 20 Oct 2020 23:08:22 GMT, Vladimir Kozlov wrote: > Someone in Oracle have to run tier1-tier3 testing with these changes to make > sure nothing is broken. I don't want to repeat 8254790. That's appreciated. On my side, I run tier1-tier3 both on aarch64 linux and x86_64 linux. The test result on these two platforms looks good for the latest changes. - PR: https://git.openjdk.java.net/jdk/pull/207
Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
On Tue, 20 Oct 2020 23:06:41 GMT, Vladimir Kozlov wrote:
>> Fei Yang has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 13 commits:
>>
>> - Fix trailing whitespace issue reported by jcheck
>> - Merge master
>> - Merge master
>> - Remove unnecessary code changes in vm_version_aarch64.cpp
>> - Merge master
>> - Merge master
>> - Merge master
>> - Merge master
>> - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate
>> the test in assembler_aarch64.cpp:asm_check
>> - Rebase
>> - ... and 3 more:
>> https://git.openjdk.java.net/jdk/compare/cdc8c401...d32c8ad7
>
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> line 604:
>
>> 602: add(ignore, "sun/security/provider/SHA5." + shaCompressName
>> + "([BI)V");
>> 603: }
>> 604: add(toBeInvestigated, "sun/security/provider/SHA3." +
>> shaCompressName + "([BI)V");
>
> This should be under `if (isJDK16OrHigher())` check. Something like this:
> https://github.com/openjdk/jdk/pull/650/files#diff-d1f378fc1b7fe041309e854d40b3a95a91e63fdecf0ecd9826b7c95eaeba314eR527
> You can wait when Aleksey push it and update your changes
OK. Will update with the following change after Aleksey's PR is integrated:
---
a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
+++
b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
@@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
if (!config.useSHA512Intrinsics()) {
add(ignore, "sun/security/provider/SHA5." + shaCompressName +
"([BI)V");
}
+
+if (isJDK16OrHigher()) {
+add(toBeInvestigated, "sun/security/provider/SHA3." +
shaCompressName + "([BI)V");
+}
}
-
PR: https://git.openjdk.java.net/jdk/pull/207
