From sean.mullan at oracle.com Tue Mar 1 19:21:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Mar 2016 14:21:26 -0500 Subject: RFR 8138653: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations should be upgraded In-Reply-To: <56CDC426.4020708@oracle.com> References: <56CDC426.4020708@oracle.com> Message-ID: <56D5EBB6.9090504@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8138653/webrev.01/ The following changes have been made: - The default key size for DSA has not been changed (stays at 1024) due to the high risk of breaking compatibility with applications still using SHA1withDSA (key sizes larger than 1024 may be incompatible and rejected). We will wait on this one for now. - The SunPKCS11 default size for RSA keys has been increased to 2048. - A bug in the PKCS11 tests was fixed which caused the version of newer NSS libraries to be unrecognized. --Sean On 02/24/2016 09:54 AM, Sean Mullan wrote: > Please review this fix to improve security defaults by increasing the > default keysize of the RSA, DSA, and DiffieHellman implementations of > AlgorithmParameterGenerator and KeyPairGenerator from 1024 to 2048 bits: > > http://cr.openjdk.java.net/~mullan/webrevs/8138653/webrev.00/ > > Thanks, > Sean > From vincent.x.ryan at oracle.com Tue Mar 1 21:50:38 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 1 Mar 2016 21:50:38 +0000 Subject: RFR 8138653: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations should be upgraded In-Reply-To: <56D5EBB6.9090504@oracle.com> References: <56CDC426.4020708@oracle.com> <56D5EBB6.9090504@oracle.com> Message-ID: <92F500B6-6304-46B3-B4CE-A5F39E83C768@oracle.com> Your fix looks fine. Thanks. > On 1 Mar 2016, at 19:21, Sean Mullan wrote: > > Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8138653/webrev.01/ > > The following changes have been made: > > - The default key size for DSA has not been changed (stays at 1024) due to the high risk of breaking compatibility with applications still using SHA1withDSA (key sizes larger than 1024 may be incompatible and rejected). We will wait on this one for now. > > - The SunPKCS11 default size for RSA keys has been increased to 2048. > > - A bug in the PKCS11 tests was fixed which caused the version of newer NSS libraries to be unrecognized. > > --Sean > > On 02/24/2016 09:54 AM, Sean Mullan wrote: >> Please review this fix to improve security defaults by increasing the >> default keysize of the RSA, DSA, and DiffieHellman implementations of >> AlgorithmParameterGenerator and KeyPairGenerator from 1024 to 2048 bits: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8138653/webrev.00/ >> >> Thanks, >> Sean >> From anthony.scarpino at oracle.com Tue Mar 1 22:29:29 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 1 Mar 2016 14:29:29 -0800 Subject: RFR 8098580: drainRefQueueBounds() puts pressure on pool.size() Message-ID: <56D617C9.1040905@oracle.com> Hi, I need a review of this change to SunPKCS11 where it's a bit smarter in disposing of native library object by reusing the same pkcs11 session is possible. Additionally changes to the session pool to fix a performance bottleneck. http://cr.openjdk.java.net/~ascarpino/8098580/webrev/ thanks Tony From jamil.j.nimeh at oracle.com Wed Mar 2 16:48:34 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 2 Mar 2016 08:48:34 -0800 Subject: RFR: JDK-8132942: ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments Message-ID: <56D71962.8090909@oracle.com> Hello all, this fixes a minor issue with OCSP stapling, where we now do the argument checking up-front before attempting to instantiate the CertificateStatus handshake message object. Also I've pulled out the OCSP stapling processing from within the clientHello method since it already was really long and placed it in its own private method. Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.01/ Thanks, --Jamil From mstjohns at comcast.net Thu Mar 3 21:04:53 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 3 Mar 2016 16:04:53 -0500 Subject: JEP Review Request: SHA-3 Hash Algorithm In-Reply-To: <56D4AD9D.7080903@oracle.com> References: <56C51524.3050700@oracle.com> <56CCF1FA.6070306@comcast.net> <56D4AD9D.7080903@oracle.com> Message-ID: <56D8A6F5.3070601@comcast.net> On 2/29/2016 3:44 PM, Valerie Peng wrote: > > Thanks for the comments, there are only < 3 months left for this to be > implemented. > Besides just assigning the mech numbers, we need the underlying PKCS11 > library (Solaris or NSS) to support SHA-3. > Once we have that, enhancing SunPKCS11 provider is fairly trivial and > can be done via an RFE. > I think it makes more sense to not include PKCS11 into this JEP unless > SHA-3 is already supported by the underlying PKCS11 library. > It's not like we won't support SHA-3 in SunPKCS11 provider ever, it's > just done at a later time, may be very soon but that depends on how > fast SHA-3 support will be added to the native PKCS11 library. I don't actually think you need to wait for Solaris/NSS to implement support in their PKCS11 DLL to implement support in the Java libraries. I chatted with the OASIS PKCS11 folks and there's a draft document with the mechanism assignments. Looking at the PKCS11 code, what you would need to do is provide a mapping between the java algorithm name and the specific PKCS11 mechanism values. Those changes are all in SunPKCS11.java and PKCS11Constants.java. > m(CKM_SHA_1)); > d(MD, "SHA-256", P11Digest, > m(CKM_SHA256)); > d(MD, "SHA-384", P11Digest, > m(CKM_SHA384)); > d(MD, "SHA-512", P11Digest, > m(CKM_SHA512)); It would seem trivial to add d(MD, "SHA3-256", P11Digest, m(CKM_SHA3_256); /// and the rest to SunPKCS11 and public static final long CKM_SHA3_256 = 0x??????; // and the rest... to PKCS11Constants. PKCS11Constants already has a bunch of values that aren't used by any of the SunPKCS11 libraries for example. Doing this would allow other PKCS11 DLLs to work with the SunPKCS11 provider even before you implement the SHA3 support in the underlying Solaris/NSS crypto libraries. If you're willing to do the update, I'm willing to do the grunt work of merging in the new constants and mappings. Later, Mike > > Regards, > Valerie > > On 2/23/2016 3:57 PM, Michael StJohns wrote: >> On 2/17/2016 7:49 PM, Valerie Peng wrote: >>> Please review this drafted JEP for adding SHA-3 Hash Algorithm >>> support to JDK 9: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8064399 >>> >>> Thanks, >>> Valerie >> >> This looks pretty good. However, I wouldn't throw PKCS11 to the side >> of the road. >> >> https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes13012016 >> suggests that PKCS11 will have the mechanism numbers probably before >> you get this approved and implemented. If you ask, they may be >> willing to assign the mechanism numbers prior to the release of the >> document, and that's really all that's necessary. >> >> Mike >> From joe.darcy at oracle.com Thu Mar 3 22:51:54 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 3 Mar 2016 14:51:54 -0800 Subject: JDK 9 RFR of JDK-8151225: Mark SpecTest.java as intermittently failing Message-ID: <56D8C00A.3010407@oracle.com> Hello, The test sun/security/rsa/SpecTest.java has been observed to fail intermittently with a timeout (JDK-8137231). The observed timeouts have been for the largest key size. Until that issue is resolved, the test should be marked as failing intermittently. Please review the patch below which does this marking. Thanks, -Joe --- a/test/sun/security/rsa/SpecTest.java Thu Mar 03 12:49:12 2016 -0800 +++ b/test/sun/security/rsa/SpecTest.java Thu Mar 03 14:51:29 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -34,6 +34,7 @@ /** * @test * @bug 8044199 + * @key intermittent * @summary Check same KeyPair's private key and public key have same modulus. * also check public key's public exponent equals to given spec's public * exponent. From joe.darcy at oracle.com Fri Mar 4 00:20:53 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 3 Mar 2016 16:20:53 -0800 Subject: JDK 9 RFR of JDK-8151228: Mark TestDSAGenParameterSpec.java as intermittently failing Message-ID: <56D8D4E5.6080009@oracle.com> Hello, The test sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java has been observed to intermittently fail (JDK-8137255). Until that problem is resolved, the test should be marked accordingly. Please review the patch below which does that marking. Thanks, -Joe --- a/test/sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java Thu Mar 03 15:47:08 2016 -0800 +++ b/test/sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java Thu Mar 03 16:20:25 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -37,6 +37,7 @@ /* * @test * @bug 8075286 + * @key intermittent * @summary Verify that DSAGenParameterSpec can and can only be used to generate * DSA within some certain range of key sizes as described in the class * specification (L, N) as (1024, 160), (2048, 224), (2048, 256) and From Xuelei.Fan at Oracle.COM Fri Mar 4 05:53:39 2016 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Fri, 4 Mar 2016 13:53:39 +0800 Subject: JDK 9 RFR of JDK-8151228: Mark TestDSAGenParameterSpec.java as intermittently failing In-Reply-To: <56D8D4E5.6080009@oracle.com> References: <56D8D4E5.6080009@oracle.com> Message-ID: <56D922E3.3040404@Oracle.COM> Looks fine to me. Thanks! Xuelei On 3/4/2016 8:20 AM, joe darcy wrote: > Hello, > > The test > > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > > has been observed to intermittently fail (JDK-8137255). Until that > problem is resolved, the test should be marked accordingly. > > Please review the patch below which does that marking. > > Thanks, > > -Joe > > --- a/test/sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > Thu Mar 03 15:47:08 2016 -0800 > +++ b/test/sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > Thu Mar 03 16:20:25 2016 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -37,6 +37,7 @@ > /* > * @test > * @bug 8075286 > + * @key intermittent > * @summary Verify that DSAGenParameterSpec can and can only be used > to generate > * DSA within some certain range of key sizes as described in > the class > * specification (L, N) as (1024, 160), (2048, 224), (2048, > 256) and > From xuelei.fan at oracle.com Fri Mar 4 10:30:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 4 Mar 2016 18:30:16 +0800 Subject: RFR: JDK-8132942: ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments In-Reply-To: <56D71962.8090909@oracle.com> References: <56D71962.8090909@oracle.com> Message-ID: <56D963B8.7090701@oracle.com> JDK-8132942: "The current implementation for OCSP stapling has ServerHandshaker trying to construct a CertificateStatus message, but if the arguments are invalid it throws SSLHandshakeException." In your webrev, looks like the exception get ignore before your update. I may miss something. Can you have more details about this point. On 3/3/2016 12:48 AM, Jamil Nimeh wrote: > Hello all, this fixes a minor issue with OCSP stapling, where we now do > the argument checking up-front before attempting to instantiate the > CertificateStatus handshake message object. I may miss something. I did not find the update related to this point. Can you have more details? > Also I've pulled out the > OCSP stapling processing from within the clientHello method since it > already was really long and placed it in its own private method. > The price is there are three more new class variables. I would try to avoid it. Looks like "staplingActive" should not be a class variable, too. Xuelei > Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.01/ > > Thanks, > --Jamil From xuelei.fan at oracle.com Fri Mar 4 11:53:27 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 4 Mar 2016 19:53:27 +0800 Subject: Code Review Request 8148108 Disable Diffie-Hellman keys less than 1024 bits Message-ID: <56D97737.6070703@oracle.com> Hi, Please review the update for JDK-8148108: http://cr.openjdk.java.net/~xuelei/8148108/webrev.00/ In this update, it is proposed to restrict the use of DH keys less than 1024 bits in length in the SSL/TLS/DTLS implementation in JDK 9. This restriction is applied via the Java Security property, "jdk.tls.disabledAlgorithms". This will impact providers that adhere to this security property, for example, the SunJSSE provider. Thanks, Xuelei From vincent.x.ryan at oracle.com Fri Mar 4 12:30:01 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 4 Mar 2016 12:30:01 +0000 Subject: Code Review Request 8148108 Disable Diffie-Hellman keys less than 1024 bits In-Reply-To: <56D97737.6070703@oracle.com> References: <56D97737.6070703@oracle.com> Message-ID: <5692754C-FB46-447C-B3B6-93C4A253261F@oracle.com> Your fix looks fine. Thanks. > On 4 Mar 2016, at 11:53, Xuelei Fan wrote: > > Hi, > > Please review the update for JDK-8148108: > http://cr.openjdk.java.net/~xuelei/8148108/webrev.00/ > > In this update, it is proposed to restrict the use of DH keys less than > 1024 bits in length in the SSL/TLS/DTLS implementation in JDK 9. This > restriction is applied via the Java Security property, > "jdk.tls.disabledAlgorithms". This will impact providers that adhere to > this security property, for example, the SunJSSE provider. > > Thanks, > Xuelei From sean.mullan at oracle.com Fri Mar 4 13:32:43 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Mar 2016 08:32:43 -0500 Subject: JDK 9 RFR of JDK-8151225: Mark SpecTest.java as intermittently failing In-Reply-To: <56D8C00A.3010407@oracle.com> References: <56D8C00A.3010407@oracle.com> Message-ID: <56D98E7B.5010205@oracle.com> Looks fine to me. --Sean On 03/03/2016 05:51 PM, joe darcy wrote: > Hello, > > The test > > sun/security/rsa/SpecTest.java > > has been observed to fail intermittently with a timeout (JDK-8137231). > The observed timeouts have been for the largest key size. Until that > issue is resolved, the test should be marked as failing intermittently. > > Please review the patch below which does this marking. > > Thanks, > > -Joe > > --- a/test/sun/security/rsa/SpecTest.java Thu Mar 03 12:49:12 2016 -0800 > +++ b/test/sun/security/rsa/SpecTest.java Thu Mar 03 14:51:29 2016 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -34,6 +34,7 @@ > /** > * @test > * @bug 8044199 > + * @key intermittent > * @summary Check same KeyPair's private key and public key have same > modulus. > * also check public key's public exponent equals to given spec's public > * exponent. > From vincent.x.ryan at oracle.com Mon Mar 7 14:05:31 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 7 Mar 2016 14:05:31 +0000 Subject: [9] review request 8151149: CipherSpi implementation of PBEWithSHA1AndDESede returns key size in bytes Message-ID: <74280128-4E77-4249-A6AA-63687B44A00F@oracle.com> Please review this fix to PKCS#12 PBE CipherSpi classes to return the cipher key size in bits. An effective key size of 112 bits is used for Triple DES. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8151149 Webrev: http://cr.openjdk.java.net/~vinnie/8151149/webrev.00/ From xuelei.fan at oracle.com Mon Mar 7 14:14:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Mar 2016 22:14:48 +0800 Subject: [9] review request 8151149: CipherSpi implementation of PBEWithSHA1AndDESede returns key size in bytes In-Reply-To: <74280128-4E77-4249-A6AA-63687B44A00F@oracle.com> References: <74280128-4E77-4249-A6AA-63687B44A00F@oracle.com> Message-ID: <56DD8CD8.60905@oracle.com> On 3/7/2016 10:05 PM, Vincent Ryan wrote: > Please review this fix to PKCS#12 PBE CipherSpi classes to return the cipher key size in bits. > An effective key size of 112 bits is used for Triple DES. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151149 > Webrev: http://cr.openjdk.java.net/~vinnie/8151149/webrev.00/ > Nice! Looks fine to me. Thanks, Xuelei From vincent.x.ryan at oracle.com Mon Mar 7 14:15:15 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 7 Mar 2016 14:15:15 +0000 Subject: [9] review request 8151149: CipherSpi implementation of PBEWithSHA1AndDESede returns key size in bytes In-Reply-To: <56DD8CD8.60905@oracle.com> References: <74280128-4E77-4249-A6AA-63687B44A00F@oracle.com> <56DD8CD8.60905@oracle.com> Message-ID: <32A1ABC2-5CF3-416E-82BF-10971BE0F58A@oracle.com> Thanks Xuelei. > On 7 Mar 2016, at 14:14, Xuelei Fan wrote: > > On 3/7/2016 10:05 PM, Vincent Ryan wrote: >> Please review this fix to PKCS#12 PBE CipherSpi classes to return the cipher key size in bits. >> An effective key size of 112 bits is used for Triple DES. >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151149 >> Webrev: http://cr.openjdk.java.net/~vinnie/8151149/webrev.00/ >> > Nice! Looks fine to me. > > Thanks, > Xuelei From sean.mullan at oracle.com Tue Mar 8 21:55:27 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Mar 2016 16:55:27 -0500 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56D477F3.9030802@oracle.com> References: <56D477F3.9030802@oracle.com> Message-ID: <56DF4A4F.70603@oracle.com> You should also copy build-dev on the next iteration since there are a few Makefile changes. On 02/29/2016 11:55 AM, Anthony Scarpino wrote: > I need a code review of this change: > > http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ > > Currently CertPath algorithm restrictions allow or deny all > certificates. This change adds the ability to reject certificate chains > that contain a restricted algorithm and the chain terminates at a root > CA; therefore, allowing a self-signed or chain that does not terminate > at a root CA. > > https://bugs.openjdk.java.net/browse/JDK-8140422 Looks good, but had a few comments as I went through ... java.security ------------- 551 # "cacerts" prohibits the algorithm only if it is used in a 552 # certificate chain that terminates at a distribution provided 553 # trust anchor in the lib/security/cacerts keystore. All other 554 # chains are not affected. Example: to apply this constraint 555 # to SHA-1 certificates, include the following: "SHA1 cacerts" Suggest rewording in middle part: "... at a trust anchor in the lib/security/cacerts.fingerprints file which is initially seeded with the fingerprints of the certificates in the lib/security/cacerts keystore." Also, add the following sentence: "If the cacerts constraint is not set, then all chains using the specified algorithm are restricted." 563 # All DisabledAlgorithms are processed in the order defined in the 564 # property. This requires lower keysize constraints to be specified 565 # before larger keysize constraints of the same algorithm. Is this still an issue? Constraints of the same algorithm are evaluated as an AND, so the order should not matter (I think). CACertsHasher ------------- I think it would be useful to emit the subject DN of the certificate as a comment (ex: "# CN=RootsRUs, ...") above each fingerprint, as it would help associate the fingerprint with the root. Then, you can ignore comments when you parse the file in AnchorCertificates. AnchorCertificates ------------------ 38 /** 39 * The purpose of this class is to determine if a trust anchor certificate 40 * is one of the default trust anchors that comes pre-installed with the JRE 41 * in the cacerts file. A locally installed trust anchor would not be a default 42 * trust anchor 43 */ The determination is based off the cacerts.fingerprints file, so maybe a better wording is: "The purpose of this class is to determine if a trust anchor certificate is in the cacerts.fingerprints file which is initially seeded with the fingerprints of the certificates in the cacerts file. A trust anchor that is subsequently added to the cacerts file but not the cacerts.fingerprints file would not be a match." 74 debug.println("Error parsing cacerts.md"); typo: cacerts.fingerprints 83 decomposer = new AlgorithmDecomposer(); Doesn't seem to be used, delete? 92 public static boolean isAnchor(X509Certificate cert) { A better name for this method might be contains(). CertificateParameters --------------------- 37 public class CertificateParameters { A better name might be CertConstraintParameters. 43 this(X509CertImpl.toImpl(c), anchor); It doesn't seem like you need to convert this to an X509CertImpl. In DisabledAlgorithmConstraints, you just call methods on X509Certificate. 46 public CertificateParameters(X509Certificate c) throws CertificateException { Doesn't seem to be used; remove? 50 public CertificateParameters(X509CertImpl c, boolean anchor) { Make private, or just combine with other ctor as it really isn't needed. 59 public boolean isTrustedChain() { A better name might be "isAnchoredToCaCert". 63 public X509CertImpl getCertificate() { Change return type to X509Certificate. AlgorithmChecker ---------------- 93 // True if trust anchor checking finds a match in the cacerts file 94 private boolean trustedMatch = false; This really means "true if the cacerts constraint enabled AND the chain is anchored by a cacert". Can you add that to the comment so it is more clear? Maybe the variable name should be changed to "caCertConstraintApplies". 97 private static final boolean checkerEnabled = 98 certPathDefaultConstraints.checkProperty("cacerts"); Call this cacertsEnabled to be more specific? 159 // Check if the 'cert' is in the trust anchor file (cacerts) 160 private static boolean isAnchor(X509Certificate cert) { Call this caCertConstraintApplies()? 161 if (!checkerEnabled) { 162 return false; 163 } I'm not sure I understand why 165 if (debug != null) debug.println("AlgorithmChecker.isAnchor: " + Suggest the following to improve readability: if (debug != null) { debug.println("AlgorithmChecker.isAnchor: " + cert.getSigAlgName()); } DisabledAlgorithmConstraints ---------------------------- 62 private final String propertyName; Doesn't seem to be used; delete? 138 public final void permits(Set primitives, 139 X509Certificate cert) throws CertPathValidatorException { Doesn't seem to be used; delete? 246 if (!constraintsMap.containsKey(algorithm)) { 247 constraintsMap.putIfAbsent(algorithm, new HashSet<>()); 248 } You can replace this with: constraintsMap.computeIfAbsent(algorithm, k -> new HashSet<>()); Same comment on lines 280-282. 251 algorithm.toUpperCase(Locale.ENGLISH); Shouldn't you also do this before adding it to the map on line 246-7? 253 if (debug != null) debug.println("Constraints len: " + 254 rComma.substring(space).split("&").length); I suspect this debugging is more useful for debugging your own code. But we shouldn't include it unless it is helpful for analyzing real issues, as the debug log files are long enough :) Same comment applies to other debugging statements (ex: lines 324-9). 287 lastConstraint = c; This seems like a bug since it is overwriting what was just done on line 285. Should this be moved to right after line 283? Also, if you had a constraint like: "RSA keySize < 1024, RSA keySize > 4096" it looks like the 2nd RSA constraint will replace the first constraint, which isn't what I think is intended. 293 public Set getConstraints(Key key) { I think you can remove this method and just change line 304 to: Set set = getConstraints(key.getAlgorithm()); 393 public boolean permits(Key key) { 403 public void permits(CertificateParameters cp) throws CertPathValidatorException { These should probably be abstract. 416 CertConstraint(String algo, String s) { Better name for "s"? --Sean From xuelei.fan at oracle.com Thu Mar 10 15:50:19 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Mar 2016 23:50:19 +0800 Subject: Code Review Request 8149017 Delayed provider selection broken in RSA client key exchange Message-ID: <56E197BB.7090800@oracle.com> Hi, Please review this update: http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ The problem is that calling Cipher.getProvider, or any method on Cipher, forces the Cipher instance to skip the delayed provider selection which is built into Cipher. In this update, Cipher.init() was changed to be the first call to an instance of Cipher. Thanks, Xuelei From joe.darcy at oracle.com Fri Mar 11 06:14:53 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 10 Mar 2016 22:14:53 -0800 Subject: JDK 9 RFR of JDK-8151679: Mark SignatureOffsets.java as intermittently failing. Message-ID: <56E2625D.3050603@oracle.com> Hello, The test sun/security/mscapi/SignatureOffsets.java has been observed to intermittently fail (JDK-8134265). Until the root cause is found, the test should be marked accordingly. Please review the patch below which does this. Thanks, -Joe diff -r 1c7bad079890 test/sun/security/mscapi/SignatureOffsets.java --- a/test/sun/security/mscapi/SignatureOffsets.java Mon Mar 07 12:10:55 2016 -0800 +++ b/test/sun/security/mscapi/SignatureOffsets.java Thu Mar 10 22:14:03 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,7 +28,7 @@ /* * @test * @bug 8050374 - * @key randomness + * @key randomness intermittent * @summary This test validates signature verification * Signature.verify(byte[], int, int). The test uses RandomFactory to * get random set of clear text data to sign. After the signature From anthony.scarpino at oracle.com Fri Mar 11 07:13:07 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 10 Mar 2016 23:13:07 -0800 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56DF4A4F.70603@oracle.com> References: <56D477F3.9030802@oracle.com> <56DF4A4F.70603@oracle.com> Message-ID: <56E27003.8090801@oracle.com> On 03/08/2016 01:55 PM, Sean Mullan wrote: > You should also copy build-dev on the next iteration since there are a > few Makefile changes. > > On 02/29/2016 11:55 AM, Anthony Scarpino wrote: >> I need a code review of this change: >> >> http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ >> >> Currently CertPath algorithm restrictions allow or deny all >> certificates. This change adds the ability to reject certificate chains >> that contain a restricted algorithm and the chain terminates at a root >> CA; therefore, allowing a self-signed or chain that does not terminate >> at a root CA. >> >> https://bugs.openjdk.java.net/browse/JDK-8140422 > > Looks good, but had a few comments as I went through ... > > java.security > ------------- > > 551 # "cacerts" prohibits the algorithm only if it is used in a > 552 # certificate chain that terminates at a distribution provided > 553 # trust anchor in the lib/security/cacerts keystore. All other > 554 # chains are not affected. Example: to apply this constraint > 555 # to SHA-1 certificates, include the following: "SHA1 cacerts" > > Suggest rewording in middle part: "... at a trust anchor in the > lib/security/cacerts.fingerprints file which is initially seeded with > the fingerprints of the certificates in the lib/security/cacerts keystore." ok > > Also, add the following sentence: "If the cacerts constraint is not set, > then all chains using the specified algorithm are restricted." ok > 563 # All DisabledAlgorithms are processed in the order defined in the > 564 # property. This requires lower keysize constraints to be specified > 565 # before larger keysize constraints of the same algorithm. > > Is this still an issue? Constraints of the same algorithm are evaluated > as an AND, so the order should not matter (I think). My usage of "DisabledAlgorithms" is the top level, comma delimited of the constraints as defined by the syntax at the top of the section. If a user says : "RSA keySize < 2048, RSA keySize < 1024 & cacerts", The first DisabledAlgorithm is going to trigger failures before the second DisabledAlgorithm can be evaluated Previous discussion of AND was referring to constraints inside of DisabledAlgorithm. "RSA keySize < 1024 & cacerts" is an AND operation as both constraints have to pass pass. > > CACertsHasher > ------------- > > I think it would be useful to emit the subject DN of the certificate as > a comment (ex: "# CN=RootsRUs, ...") above each fingerprint, as it would > help associate the fingerprint with the root. Then, you can ignore > comments when you parse the file in AnchorCertificates. ok > > AnchorCertificates > ------------------ > > 38 /** > 39 * The purpose of this class is to determine if a trust anchor > certificate > 40 * is one of the default trust anchors that comes pre-installed > with the JRE > 41 * in the cacerts file. A locally installed trust anchor would not > be a default > 42 * trust anchor > 43 */ > > The determination is based off the cacerts.fingerprints file, so maybe a > better wording is: "The purpose of this class is to determine if a trust > anchor certificate is in the cacerts.fingerprints file which is > initially seeded with the fingerprints of the certificates in the > cacerts file. A trust anchor that is subsequently added to the cacerts > file but not the cacerts.fingerprints file would not be a match." > ok > 74 debug.println("Error parsing cacerts.md"); > > typo: cacerts.fingerprints yep > > 83 decomposer = new AlgorithmDecomposer(); > > Doesn't seem to be used, delete? delete > > 92 public static boolean isAnchor(X509Certificate cert) { > > A better name for this method might be contains(). sure > > CertificateParameters > --------------------- disagreement inline, otherwise comment accepted > > 37 public class CertificateParameters { > > A better name might be CertConstraintParameters. > > 43 this(X509CertImpl.toImpl(c), anchor); > > It doesn't seem like you need to convert this to an X509CertImpl. In > DisabledAlgorithmConstraints, you just call methods on X509Certificate. > > 46 public CertificateParameters(X509Certificate c) throws > CertificateException { > > Doesn't seem to be used; remove? It's used in DisabledAlgorithmConstraints in 138 > > 50 public CertificateParameters(X509CertImpl c, boolean anchor) { > > Make private, or just combine with other Constructor as it really isn't needed. > > 59 public boolean isTrustedChain() { > > A better name might be "isAnchoredToCaCert". I'm changing this to isTrustedMatch to be consistent across AlgorithmChecker, CertConstraintsParameters, and DisabledAlgorithConstraints. > > 63 public X509CertImpl getCertificate() { > > Change return type to X509Certificate. > > AlgorithmChecker > ---------------- > > 93 // True if trust anchor checking finds a match in the cacerts > file > 94 private boolean trustedMatch = false; > > This really means "true if the cacerts constraint enabled AND the chain > is anchored by a cacert". Can you add that to the comment so it is more > clear? Maybe the variable name should be changed to > "caCertConstraintApplies". I added the comment, but left the variable name as I made it consistent through out as previous mentioned > > 97 private static final boolean checkerEnabled = > 98 certPathDefaultConstraints.checkProperty("cacerts"); > > Call this cacertsEnabled to be more specific? Sure > > 159 // Check if the 'cert' is in the trust anchor file (cacerts) > 160 private static boolean isAnchor(X509Certificate cert) { > > Call this caCertConstraintApplies()? I think checkFingerprint() is better. Trying to get cacerts into the name is too messy > > 165 if (debug != null) > debug.println("AlgorithmChecker.isAnchor: " + > > Suggest the following to improve readability: > > if (debug != null) { > debug.println("AlgorithmChecker.isAnchor: " + > cert.getSigAlgName()); > } ok > DisabledAlgorithmConstraints > ---------------------------- > > 62 private final String propertyName; > > Doesn't seem to be used; delete? yes > > 138 public final void permits(Set primitives, > 139 X509Certificate cert) throws CertPathValidatorException { > > Doesn't seem to be used; delete? it's used. > > 246 if (!constraintsMap.containsKey(algorithm)) { > 247 constraintsMap.putIfAbsent(algorithm, new > HashSet<>()); > 248 } > > You can replace this with: > > constraintsMap.computeIfAbsent(algorithm, k -> new HashSet<>()); ok > Same comment on lines 280-282. > > 251 algorithm.toUpperCase(Locale.ENGLISH); > > Shouldn't you also do this before adding it to the map on line 246-7? yes.. some other changes can be done around this > > 253 if (debug != null) debug.println("Constraints len: > " + > 254 rComma.substring(space).split("&").length); > > I suspect this debugging is more useful for debugging your own code. But > we shouldn't include it unless it is helpful for analyzing > real issues, as the debug log files are long enough :) Same comment > applies to other debugging statements (ex: lines 324-9). Sure.. I had been debating on removing these > > 287 lastConstraint = c; > > This seems like a bug since it is overwriting what was just done on line > 285. Should this be moved to right after line 283? I believe this is correct. lastConstraint is suppose to be the last one in the linked list. 285 is adding the new constraint to the next link in the linked list. 287 is setting the new constraint as the lastConstraint. If I changed it after 283, it would keep overwriting the next link the list. The linked is how I tell it's an AND operation vs a new constraint. > > Also, if you had a constraint like: "RSA keySize < 1024, RSA keySize > > 4096" it looks like the 2nd RSA constraint will replace the first > constraint, which isn't what I think is intended. The map is > So it looks like That is why getConstraints() returns a Set. > > 293 public Set getConstraints(Key key) { > > I think you can remove this method and just change line 304 to: > > Set set = getConstraints(key.getAlgorithm()); sure > > 393 public boolean permits(Key key) { > 403 public void permits(CertificateParameters cp) throws > CertPathValidatorException { > > These should probably be abstract. They meant to be inherited if the Constraint doesn't require the check. In the case of 393, it is used by CertConstraint. > > 416 CertConstraint(String algo, String s) { > > Better name for "s"? not applicable anymore. > > --Sean From xuelei.fan at oracle.com Fri Mar 11 07:54:10 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Mar 2016 15:54:10 +0800 Subject: JDK 9 RFR of JDK-8151679: Mark SignatureOffsets.java as intermittently failing. In-Reply-To: <56E2625D.3050603@oracle.com> References: <56E2625D.3050603@oracle.com> Message-ID: <56E279A2.4050704@oracle.com> Looks fine to me. Thanks! Xuelei On 3/11/2016 2:14 PM, joe darcy wrote: > Hello, > > The test > > sun/security/mscapi/SignatureOffsets.java > > has been observed to intermittently fail (JDK-8134265). Until the root > cause is found, the test should be marked accordingly. Please review the > patch below which does this. > > Thanks, > > -Joe > > diff -r 1c7bad079890 test/sun/security/mscapi/SignatureOffsets.java > --- a/test/sun/security/mscapi/SignatureOffsets.java Mon Mar 07 > 12:10:55 2016 -0800 > +++ b/test/sun/security/mscapi/SignatureOffsets.java Thu Mar 10 > 22:14:03 2016 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -28,7 +28,7 @@ > /* > * @test > * @bug 8050374 > - * @key randomness > + * @key randomness intermittent > * @summary This test validates signature verification > * Signature.verify(byte[], int, int). The test uses > RandomFactory to > * get random set of clear text data to sign. After the signature > From jamil.j.nimeh at oracle.com Fri Mar 11 08:39:25 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 11 Mar 2016 00:39:25 -0800 Subject: RFR [Update]: JDK-8132942: ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments In-Reply-To: <56D963B8.7090701@oracle.com> References: <56D71962.8090909@oracle.com> <56D963B8.7090701@oracle.com> Message-ID: <56E2843D.7010804@oracle.com> Hello all, This updated webrev switches from holding the stapling parameters as instance fields to local variables to the clientHello() routine where they are used. Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.02/ --Jamil On 03/04/2016 02:30 AM, Xuelei Fan wrote: > JDK-8132942: > > "The current implementation for OCSP stapling has ServerHandshaker > trying to construct a CertificateStatus message, but if the arguments > are invalid it throws SSLHandshakeException." > > In your webrev, looks like the exception get ignore before your update. > I may miss something. Can you have more details about this point. > > > On 3/3/2016 12:48 AM, Jamil Nimeh wrote: >> Hello all, this fixes a minor issue with OCSP stapling, where we now do >> the argument checking up-front before attempting to instantiate the >> CertificateStatus handshake message object. > I may miss something. I did not find the update related to this point. > Can you have more details? > >> Also I've pulled out the >> OCSP stapling processing from within the clientHello method since it >> already was really long and placed it in its own private method. >> > The price is there are three more new class variables. I would try to > avoid it. Looks like "staplingActive" should not be a class variable, too. > > Xuelei > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.01/ >> >> Thanks, >> --Jamil From j.p.cranendonk at gmail.com Fri Mar 11 10:03:55 2016 From: j.p.cranendonk at gmail.com (Jeroen Cranendonk) Date: Fri, 11 Mar 2016 11:03:55 +0100 Subject: Code Review Request 8149017 Delayed provider selection broken in RSA client key exchange In-Reply-To: <56E197BB.7090800@oracle.com> References: <56E197BB.7090800@oracle.com> Message-ID: Hmm, it looks like it should solve the problem I originally reported, so that's good :) If there's a testing Windows JRE/JDK somewhere I can test it here ;) It might be worth investigating other calls to KeyUtil.isOracleJCEProvider, I think I remember this not being the only place where this issue might occur, from when I investigated it. (But for us this is the only place that matters :) ). Looking at the fix, I wonder if there might be one (very) edge case left, but again not one that would affect us :) I'll refer to the numbers in the following code. When a non Oracle provider (4: results false) is available and has high priority, which supports UNWRAP with the given key, but does not support DECRYPT with the given key (Ok, this is a -very- hypothetical case.. :) ). The first init (3) will select that provider, which will be stored in the cipher instance, and the second init (5) will fail, resulting in the whole method to fail, even if another provider/cipher (with lower priority) is available which could've handled the request. TBH the fix for 'JDK-8081297' (issue which is sadly hidden to the public ;) ) feels like a bit of a kludge. Based on whether 'the' provider is an internal Oracle one or not either UNWRAP or DECRYPT is selected/used. But because of delayed provider selection, it's hard to say what 'the' provider is to base this choice on :) It feels like the choice would have to actually involve multiple providers in some cases. I'd make a recommendation, but I'm not sure what exactly is fixed by JDK-8081297 ;) 1> boolean needFailover = false; 2> Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1); try { 3> cipher.init(Cipher.UNWRAP_MODE, privateKey, new TlsRsaPremasterSecretParameterSpec( maxVersion.v, currentVersion.v), generator); 4> needFailover = !KeyUtil.isOracleJCEProvider( cipher.getProvider().getName()); } catch (InvalidKeyException | UnsupportedOperationException iue) { if (debug != null && Debug.isOn("handshake")) { System.out.println("The Cipher provider " + cipher.getProvider().getName() + " may not support TlsRsaPremasterSecretParameterSpec"); } needFailover = true; } if (needFailover) { 5> cipher.init(Cipher.DECRYPT_MODE, privateKey); boolean failed = false; try { encoded = cipher.doFinal(encrypted); } catch (BadPaddingException bpe) { failed = true; } encoded = KeyUtil.checkTlsPreMasterSecretKey( maxVersion.v, currentVersion.v, generator, encoded, failed); preMaster = generatePreMasterSecret( maxVersion.v, currentVersion.v, encoded, generator); } else { preMaster = (SecretKey)cipher.unwrap(encrypted, "TlsRsaPremasterSecret", Cipher.SECRET_KEY); } Cheers! Jeroen Cranendonk On Thu, Mar 10, 2016 at 4:50 PM, Xuelei Fan wrote: > Hi, > > Please review this update: > > http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ > > The problem is that calling Cipher.getProvider, or any method on Cipher, > forces the Cipher instance to skip the delayed provider selection which > is built into Cipher. > > In this update, Cipher.init() was changed to be the first call to an > instance of Cipher. > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Mar 11 10:30:29 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Mar 2016 18:30:29 +0800 Subject: Code Review Request 8149017 Delayed provider selection broken in RSA client key exchange In-Reply-To: References: <56E197BB.7090800@oracle.com> Message-ID: <56E29E45.3070101@oracle.com> On 3/11/2016 6:03 PM, Jeroen Cranendonk wrote: > Hmm, it looks like it should solve the problem I originally reported, > so that's good :) Yes, it is a fix for your reported issue. Thank you! > If there's a testing Windows JRE/JDK somewhere I can test it here ;) > > It might be worth investigating other calls to > KeyUtil.isOracleJCEProvider, I think I remember this not being the > only place where this issue might occur, from when I investigated it. > (But for us this is the only place that matters :) ). > I made a quick evaluation. So far, other uses of this method are not impacted. > > Looking at the fix, I wonder if there might be one (very) edge case > left, but again not one that would affect us :) > > I'll refer to the numbers in the following code. > When a non Oracle provider (4: results false) is available and has > high priority, which supports UNWRAP with the given key, but does not > support DECRYPT with the given key (Ok, this is a -very- hypothetical > case.. :) ). The first init (3) will select that provider, which will > be stored in the cipher instance, and the second init (5) will fail, > resulting in the whole method to fail, even if another provider/cipher > (with lower priority) is available which could've handled the request. > Yes. This is a potential problem. But as disposing the previous cipher instance and creating a new instance could be expensive, so I did not fix this issue this time. I will make the update if there is a real complain in practice in the future. Thanks for the quick response! Regards, Xuelei > TBH the fix for 'JDK-8081297' (issue which is sadly hidden to the > public ;) ) feels like a bit of a kludge. Based on whether 'the' > provider is an internal Oracle one or not either UNWRAP or DECRYPT is > selected/used. But because of delayed provider selection, it's hard to > say what 'the' provider is to base this choice on :) It feels like the > choice would have to actually involve multiple providers in some > cases. > I'd make a recommendation, but I'm not sure what exactly is fixed by > JDK-8081297 ;) > > 1> boolean needFailover = false; > 2> Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1); > try { > 3> cipher.init(Cipher.UNWRAP_MODE, privateKey, new > TlsRsaPremasterSecretParameterSpec( maxVersion.v, currentVersion.v), > generator); > 4> needFailover = !KeyUtil.isOracleJCEProvider( > cipher.getProvider().getName()); > } catch (InvalidKeyException | UnsupportedOperationException iue) { > if (debug != null && Debug.isOn("handshake")) { > System.out.println("The Cipher provider " + > cipher.getProvider().getName() + " may not support > TlsRsaPremasterSecretParameterSpec"); > } > needFailover = true; > } > > if (needFailover) { > 5> cipher.init(Cipher.DECRYPT_MODE, privateKey); > boolean failed = false; > try { > encoded = cipher.doFinal(encrypted); > } catch (BadPaddingException bpe) { > failed = true; > } > encoded = KeyUtil.checkTlsPreMasterSecretKey( maxVersion.v, > currentVersion.v, generator, encoded, failed); > preMaster = generatePreMasterSecret( maxVersion.v, > currentVersion.v, encoded, generator); > } else { > preMaster = (SecretKey)cipher.unwrap(encrypted, > "TlsRsaPremasterSecret", Cipher.SECRET_KEY); > } > > Cheers! > Jeroen Cranendonk > > > On Thu, Mar 10, 2016 at 4:50 PM, Xuelei Fan wrote: >> Hi, >> >> Please review this update: >> >> http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ >> >> The problem is that calling Cipher.getProvider, or any method on Cipher, >> forces the Cipher instance to skip the delayed provider selection which >> is built into Cipher. >> >> In this update, Cipher.init() was changed to be the first call to an >> instance of Cipher. >> >> Thanks, >> Xuelei From xuelei.fan at oracle.com Fri Mar 11 12:35:01 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Mar 2016 20:35:01 +0800 Subject: RFR [Update]: JDK-8132942: ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments In-Reply-To: <56E2843D.7010804@oracle.com> References: <56D71962.8090909@oracle.com> <56D963B8.7090701@oracle.com> <56E2843D.7010804@oracle.com> Message-ID: <56E2BB75.1020400@oracle.com> Looks fine to me. Thanks! Xuelei On 3/11/2016 4:39 PM, Jamil Nimeh wrote: > Hello all, > > This updated webrev switches from holding the stapling parameters as > instance fields to local variables to the clientHello() routine where > they are used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.02/ > > --Jamil > > > On 03/04/2016 02:30 AM, Xuelei Fan wrote: >> JDK-8132942: >> >> "The current implementation for OCSP stapling has ServerHandshaker >> trying to construct a CertificateStatus message, but if the arguments >> are invalid it throws SSLHandshakeException." >> >> In your webrev, looks like the exception get ignore before your update. >> I may miss something. Can you have more details about this point. >> >> >> On 3/3/2016 12:48 AM, Jamil Nimeh wrote: >>> Hello all, this fixes a minor issue with OCSP stapling, where we now do >>> the argument checking up-front before attempting to instantiate the >>> CertificateStatus handshake message object. >> I may miss something. I did not find the update related to this point. >> Can you have more details? >> >>> Also I've pulled out the >>> OCSP stapling processing from within the clientHello method since it >>> already was really long and placed it in its own private method. >>> >> The price is there are three more new class variables. I would try to >> avoid it. Looks like "staplingActive" should not be a class variable, >> too. >> >> Xuelei >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132942 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132942/webrev.01/ >>> >>> Thanks, >>> --Jamil > From anthony.scarpino at oracle.com Fri Mar 11 21:43:51 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 11 Mar 2016 13:43:51 -0800 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56D477F3.9030802@oracle.com> References: <56D477F3.9030802@oracle.com> Message-ID: <56E33C17.6020602@oracle.com> I updated the webrev and added the build-dev list as there are two makefile changes. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.01/ thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: > I need a code review of this change: > > Currently CertPath algorithm restrictions allow or deny all > certificates. This change adds the ability to reject certificate chains > that contain a restricted algorithm and the chain terminates at a root > CA; therefore, allowing a self-signed or chain that does not terminate > at a root CA. > > https://bugs.openjdk.java.net/browse/JDK-8140422 From artem.smotrakov at oracle.com Fri Mar 11 22:07:32 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 11 Mar 2016 14:07:32 -0800 Subject: [9] RFR: 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing Message-ID: <56E341A4.9060403@oracle.com> Hello, The following krb5 tests have been observed to intermittently fail: sun/security/krb5/auto/Unreachable.java sun/security/krb5/auto/MaxRetries.java Please see the following bugs for details: https://bugs.openjdk.java.net/browse/JDK-8087144 https://bugs.openjdk.java.net/browse/JDK-8015595 Until those bugs are fixed, the tests should be marked accordingly. Please review the webrev below which does this. Bug: https://bugs.openjdk.java.net/browse/JDK-8151734 Webrev: http://cr.openjdk.java.net/~asmotrak/8151734/webrev.00/ Artem From weijun.wang at oracle.com Sat Mar 12 00:45:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 12 Mar 2016 08:45:27 +0800 Subject: [9] RFR: 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing In-Reply-To: <56E341A4.9060403@oracle.com> References: <56E341A4.9060403@oracle.com> Message-ID: <74E0B91F-4879-4ADF-AC1A-0CEC48C6E4C2@oracle.com> The change looks fine. Thanks Max > On Mar 12, 2016, at 6:07 AM, Artem Smotrakov wrote: > > Hello, > > The following krb5 tests have been observed to intermittently fail: > > sun/security/krb5/auto/Unreachable.java > sun/security/krb5/auto/MaxRetries.java > > Please see the following bugs for details: > > https://bugs.openjdk.java.net/browse/JDK-8087144 > https://bugs.openjdk.java.net/browse/JDK-8015595 > > Until those bugs are fixed, the tests should be marked accordingly. Please review the webrev below which does this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151734 > Webrev: http://cr.openjdk.java.net/~asmotrak/8151734/webrev.00/ > > Artem From joe.darcy at oracle.com Sat Mar 12 03:28:15 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 11 Mar 2016 19:28:15 -0800 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list Message-ID: <56E38CCF.8080004@oracle.com> Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the webrev to adopt the revised format for the problem list: http://cr.openjdk.java.net/~darcy/8151763.0/ I've verified jtreg produces the same test list with the old and new versions of the problem list. Thanks, -Joe From Sergey.Bylokhov at oracle.com Sat Mar 12 16:05:51 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 12 Mar 2016 19:05:51 +0300 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E38CCF.8080004@oracle.com> References: <56E38CCF.8080004@oracle.com> Message-ID: <56E43E5F.80503@oracle.com> Looks fine. On 12.03.16 6:28, joe darcy wrote: > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can directly > include the bug number associated with the test in question, enabling > better reporting. This format should be used rather than the current > convention of putting the bug number in a comment. > > Please review the webrev to adopt the revised format for the problem list: > > http://cr.openjdk.java.net/~darcy/8151763.0/ > > I've verified jtreg produces the same test list with the old and new > versions of the problem list. > > Thanks, > > -Joe -- Best regards, Sergey. From chris.hegarty at oracle.com Sat Mar 12 21:28:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 12 Mar 2016 16:28:40 -0500 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E38CCF.8080004@oracle.com> References: <56E38CCF.8080004@oracle.com> Message-ID: Looks good Joe. -Chris > On 11 Mar 2016, at 22:28, joe darcy wrote: > > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. > > Please review the webrev to adopt the revised format for the problem list: > > http://cr.openjdk.java.net/~darcy/8151763.0/ > > I've verified jtreg produces the same test list with the old and new versions of the problem list. > > Thanks, > > -Joe From sean.mullan at oracle.com Mon Mar 14 12:49:50 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Mar 2016 08:49:50 -0400 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E38CCF.8080004@oracle.com> References: <56E38CCF.8080004@oracle.com> Message-ID: <56E6B36E.8090806@oracle.com> Looks good to me. --Sean On 03/11/2016 10:28 PM, joe darcy wrote: > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can directly > include the bug number associated with the test in question, enabling > better reporting. This format should be used rather than the current > convention of putting the bug number in a comment. > > Please review the webrev to adopt the revised format for the problem list: > > http://cr.openjdk.java.net/~darcy/8151763.0/ > > I've verified jtreg produces the same test list with the old and new > versions of the problem list. > > Thanks, > > -Joe From joe.darcy at oracle.com Mon Mar 14 17:31:58 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 14 Mar 2016 10:31:58 -0700 Subject: JDK 9 RFR of JDK-8151835: Mark SmallPrimeExponentP.java as intermittently failing Message-ID: <56E6F58E.3040506@oracle.com> Hello, The test sun/security/mscapi/SmallPrimeExponentP.java has been seen to timeout intermittently, bug JDK-8151834. The sources of the test should be marked accordingly; please review the corresponding patch below. Thanks, -Joe --- a/test/sun/security/mscapi/SmallPrimeExponentP.java Fri Mar 11 17:07:57 2016 -0800 +++ b/test/sun/security/mscapi/SmallPrimeExponentP.java Mon Mar 14 10:27:59 2016 -0700 @@ -32,6 +32,7 @@ /* * @test * @bug 8023546 + * @key intermittent * @modules java.base/sun.security.x509 * java.base/sun.security.tools.keytool * @summary sun/security/mscapi/ShortRSAKey1024.sh fails intermittently From vincent.x.ryan at oracle.com Mon Mar 14 17:39:39 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 14 Mar 2016 17:39:39 +0000 Subject: JDK 9 RFR of JDK-8151835: Mark SmallPrimeExponentP.java as intermittently failing In-Reply-To: <56E6F58E.3040506@oracle.com> References: <56E6F58E.3040506@oracle.com> Message-ID: <028461A2-1D9F-4080-87A2-090AF669B85F@oracle.com> Looks fine to me. Thanks. > On 14 Mar 2016, at 17:31, joe darcy wrote: > > Hello, > > The test > > sun/security/mscapi/SmallPrimeExponentP.java > > has been seen to timeout intermittently, bug JDK-8151834. > > The sources of the test should be marked accordingly; please review the corresponding patch below. > > Thanks, > > -Joe > > --- a/test/sun/security/mscapi/SmallPrimeExponentP.java Fri Mar 11 17:07:57 2016 -0800 > +++ b/test/sun/security/mscapi/SmallPrimeExponentP.java Mon Mar 14 10:27:59 2016 -0700 > @@ -32,6 +32,7 @@ > /* > * @test > * @bug 8023546 > + * @key intermittent > * @modules java.base/sun.security.x509 > * java.base/sun.security.tools.keytool > * @summary sun/security/mscapi/ShortRSAKey1024.sh fails intermittently > From xuelei.fan at oracle.com Tue Mar 15 09:51:50 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Mar 2016 17:51:50 +0800 Subject: Code Review Request 8149017 Delayed provider selection broken in RSA client key exchange In-Reply-To: <56E197BB.7090800@oracle.com> References: <56E197BB.7090800@oracle.com> Message-ID: <56E7DB36.60701@oracle.com> Ping ... On 3/10/2016 11:50 PM, Xuelei Fan wrote: > Hi, > > Please review this update: > > http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ > > The problem is that calling Cipher.getProvider, or any method on Cipher, > forces the Cipher instance to skip the delayed provider selection which > is built into Cipher. > > In this update, Cipher.init() was changed to be the first call to an > instance of Cipher. > > Thanks, > Xuelei > From sibabrata.sahoo at oracle.com Tue Mar 15 10:24:28 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 15 Mar 2016 03:24:28 -0700 (PDT) Subject: [9] RFR: 8150512:Update test for jdk.security.provider.preferred security property. In-Reply-To: <56D07778.9000409@oracle.com> References: <56D07778.9000409@oracle.com> Message-ID: <6652cc38-bd6c-45a2-b122-109700bde7e5@default> Hi Anthony, Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8150512/webrev.01/ Following comments associated. Thanks, Siba ------------------- Here are my comments... - PreferredProviderTest.java:62-70 You appear to be missing SHA1 and SHA-224. They should be added to the preferredProp variable, and the verifyDigestProvider DataTuple's. - PreferredProviderTest.java:75-76 This is calling MessageDigest with RSA as the algorithm, I would expect this to fail, but the test looks like it expects it to pass. The original code was creating a KeyFactory for RSA which would pass. thanks Tony From ecki at zusammenkunft.net Tue Mar 15 10:29:34 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 15 Mar 2016 11:29:34 +0100 Subject: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange In-Reply-To: <56E7DB36.60701@oracle.com> References: <56E197BB.7090800@oracle.com> <56E7DB36.60701@oracle.com> Message-ID: <56e7e40e.e853c20a.2952d.ffffc186@mx.google.com> BTW, the System.out is already in the existing code, but I wonder if this should use Debug.println instead? Gruss Bernd -- http://bernd.eckenfels.net Von: Xuelei Fan Gesendet: Dienstag, 15. M?rz 2016 11:02 An: OpenJDK Betreff: Re: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange Ping ... On 3/10/2016 11:50 PM, Xuelei Fan wrote: > Hi, > > Please review this update: > > http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ > > The problem is that calling Cipher.getProvider, or any method on Cipher, > forces the Cipher instance to skip the delayed provider selection which > is built into Cipher. > > In this update, Cipher.init() was changed to be the first call to an > instance of Cipher. > > Thanks, > Xuelei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Mar 15 10:34:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Mar 2016 18:34:37 +0800 Subject: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange In-Reply-To: <56e7e40e.e853c20a.2952d.ffffc186@mx.google.com> References: <56E197BB.7090800@oracle.com> <56E7DB36.60701@oracle.com> <56e7e40e.e853c20a.2952d.ffffc186@mx.google.com> Message-ID: <56E7E53D.5010702@oracle.com> On 3/15/2016 6:29 PM, Bernd Eckenfels wrote: > > > BTW, the System.out is already in the existing code, but I wonder if > this should use Debug.println instead? > Better to use Debug.println(). I will make the update in an separate debug log improvement enhancement. Thanks, Xuelei > > > Gruss > > Bernd > -- > http://bernd.eckenfels.net > > > > *Von: *Xuelei Fan > *Gesendet: *Dienstag, 15. M?rz 2016 11:02 > *An: *OpenJDK > *Betreff: *Re: Code Review Request 8149017 Delayed provider selection > broken inRSA client key exchange > > > > Ping ... > > > > On 3/10/2016 11:50 PM, Xuelei Fan wrote: > >> Hi, > >> > >> Please review this update: > >> > >> http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ > >> > >> The problem is that calling Cipher.getProvider, or any method on Cipher, > >> forces the Cipher instance to skip the delayed provider selection which > >> is built into Cipher. > >> > >> In this update, Cipher.init() was changed to be the first call to an > >> instance of Cipher. > >> > >> Thanks, > >> Xuelei > >> > > > > > From christoph.langer at sap.com Tue Mar 15 22:00:15 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Mar 2016 22:00:15 +0000 Subject: Regarding JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow Message-ID: Hi there, today I did some debugging regarding the TLS exception I've seen and reported in JDK-8149169: javax.net.ssl.SSLException: java.nio.BufferOverflowException at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:319) at com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.java:42) at com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) Caused by: java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) at sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:226) at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) ... 12 more I think the problem is with the logic in sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The read method calls the readRecord(buffer) method of the socket (SSLSocketImpl) and hands it the buffer to be eventually filled by SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with 4K and before readRecord is called, the packet length is verified (in line 144: int packetLen = socket.bytesInCompletePacket();) and the buffer reallocated if the incoming package would be larger than the buffer. However, in my case, the incoming package is a handshake package of a small size, so the buffer won't be adjusted. Then, after the handshake is done, the real data packet is read, still within SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this one has a length of more than 4K. So the buffer will be too small in decodeInputRecord and hence the exception is thrown. So, basically the issue will appear if the TLS data package following immediately after a server initiated handshake will be larger than the buffer of AppInputStream. I guess that should be easily recreatable in a small test case. Now the question how to fix? I can see 3 options: a) Just allocate the ByteBuffer in AppInputStream to SSLRecord.maxLargeRecordSize (about 32K) - easiest fix and removing the need to check the length for each record. But I guess this is not desired as the buffer is unnecessarily large for most cases? b) Extend SSLSocketInputRecord somehow to be able to not only read the length of the incoming packet but also the type, e.g. if it is a handshake. In that case the buffer would need to be extended to SSLRecord.maxLargeRecordSize. But why not do a) then?? c) Check the volume bytes returned from readRecord and redo the read in case the volume is larger than the buffer capacity Which way should I pursue? Do you see another option? Or am I getting something completely wrong running into an illegal case? Thanks in advance for your feedback, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Mar 16 00:19:35 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Mar 2016 08:19:35 +0800 Subject: [9] RFR: 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing In-Reply-To: <56E341A4.9060403@oracle.com> References: <56E341A4.9060403@oracle.com> Message-ID: <44931553-dbf9-7d6f-1045-cd6c85c24fa4@oracle.com> Hi Artem I thought I replied to this but seems haven't. Yes, the change looks fine. Thanks Max On 3/12/2016 6:07, Artem Smotrakov wrote: > Hello, > > The following krb5 tests have been observed to intermittently fail: > > sun/security/krb5/auto/Unreachable.java > sun/security/krb5/auto/MaxRetries.java > > Please see the following bugs for details: > > https://bugs.openjdk.java.net/browse/JDK-8087144 > https://bugs.openjdk.java.net/browse/JDK-8015595 > > Until those bugs are fixed, the tests should be marked accordingly. > Please review the webrev below which does this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151734 > Webrev: http://cr.openjdk.java.net/~asmotrak/8151734/webrev.00/ > > Artem From christoph.langer at sap.com Wed Mar 16 21:28:41 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 Mar 2016 21:28:41 +0000 Subject: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow Message-ID: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> Hi, I think I've found a way to fix the issue which looks quite reasonable to me. Would you please comment/review it? I've also included a test to reproduce the issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8149169.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8149169 Thanks and best regards Christoph From: Langer, Christoph Sent: Dienstag, 15. M?rz 2016 23:00 To: security-dev at openjdk.java.net Subject: Regarding JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow Hi there, today I did some debugging regarding the TLS exception I've seen and reported in JDK-8149169: javax.net.ssl.SSLException: java.nio.BufferOverflowException at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:319) at com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.java:42) at com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) Caused by: java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) at sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:226) at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) ... 12 more I think the problem is with the logic in sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The read method calls the readRecord(buffer) method of the socket (SSLSocketImpl) and hands it the buffer to be eventually filled by SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with 4K and before readRecord is called, the packet length is verified (in line 144: int packetLen = socket.bytesInCompletePacket();) and the buffer reallocated if the incoming package would be larger than the buffer. However, in my case, the incoming package is a handshake package of a small size, so the buffer won't be adjusted. Then, after the handshake is done, the real data packet is read, still within SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this one has a length of more than 4K. So the buffer will be too small in decodeInputRecord and hence the exception is thrown. So, basically the issue will appear if the TLS data package following immediately after a server initiated handshake will be larger than the buffer of AppInputStream. I guess that should be easily recreatable in a small test case. Now the question how to fix? I can see 3 options: a) Just allocate the ByteBuffer in AppInputStream to SSLRecord.maxLargeRecordSize (about 32K) - easiest fix and removing the need to check the length for each record. But I guess this is not desired as the buffer is unnecessarily large for most cases? b) Extend SSLSocketInputRecord somehow to be able to not only read the length of the incoming packet but also the type, e.g. if it is a handshake. In that case the buffer would need to be extended to SSLRecord.maxLargeRecordSize. But why not do a) then?? c) Check the volume bytes returned from readRecord and redo the read in case the volume is larger than the buffer capacity Which way should I pursue? Do you see another option? Or am I getting something completely wrong running into an illegal case? Thanks in advance for your feedback, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Mar 16 23:43:13 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Mar 2016 16:43:13 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: References: <56E38CCF.8080004@oracle.com> Message-ID: <56E9EF91.8050901@oracle.com> Just a follow-up, to avoid causing additional merge headaches, I'll revise the patch to make this change once the next round of Jigsaw changes get back in jdk9/dev (http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html). Thanks, -Joe On 3/12/2016 1:28 PM, Chris Hegarty wrote: > Looks good Joe. > > -Chris > >> On 11 Mar 2016, at 22:28, joe darcy wrote: >> >> Hello, >> >> As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. >> >> Please review the webrev to adopt the revised format for the problem list: >> >> http://cr.openjdk.java.net/~darcy/8151763.0/ >> >> I've verified jtreg produces the same test list with the old and new versions of the problem list. >> >> Thanks, >> >> -Joe From jonathan.gibbons at oracle.com Wed Mar 16 23:50:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Mar 2016 16:50:55 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E38CCF.8080004@oracle.com> References: <56E38CCF.8080004@oracle.com> Message-ID: <56E9F15F.2050002@oracle.com> On 03/11/2016 07:28 PM, joe darcy wrote: > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can > directly include the bug number associated with the test in question, > enabling better reporting. This format should be used rather than the > current convention of putting the bug number in a comment. > > Please review the webrev to adopt the revised format for the problem > list: > > http://cr.openjdk.java.net/~darcy/8151763.0/ > > I've verified jtreg produces the same test list with the old and new > versions of the problem list. > > Thanks, > > -Joe Joe, You can use a comma-separated list when multiple bugs are involved. The only restriction is, no embedded whitespace within the list 342 # Also 8080165 343 java/util/Arrays/ParallelPrefix.java 8085982 generic-all can be 343 java/util/Arrays/ParallelPrefix.java 8085982,8080165 generic-all -- Jon From joe.darcy at oracle.com Wed Mar 16 23:52:01 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Mar 2016 16:52:01 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E9F15F.2050002@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> Message-ID: <56E9F1A1.3040309@oracle.com> Hi Jon, Noted; I'll make that improvement in the next round. Thanks for pointing this out, -Joe On 3/16/2016 4:50 PM, Jonathan Gibbons wrote: > > > On 03/11/2016 07:28 PM, joe darcy wrote: >> Hello, >> >> As Jon Gibbons has noted off-list, the problem list entries can >> directly include the bug number associated with the test in question, >> enabling better reporting. This format should be used rather than the >> current convention of putting the bug number in a comment. >> >> Please review the webrev to adopt the revised format for the problem >> list: >> >> http://cr.openjdk.java.net/~darcy/8151763.0/ >> >> I've verified jtreg produces the same test list with the old and new >> versions of the problem list. >> >> Thanks, >> >> -Joe > > > Joe, > > You can use a comma-separated list when multiple bugs are involved. > The only restriction is, no embedded whitespace within the list > > 342 # Also 8080165 > 343 java/util/Arrays/ParallelPrefix.java 8085982 generic-all > > can be > > 343 java/util/Arrays/ParallelPrefix.java 8085982,8080165 generic-all > > > -- Jon From xuelei.fan at oracle.com Fri Mar 18 02:51:41 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 18 Mar 2016 10:51:41 +0800 Subject: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow In-Reply-To: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> References: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> Message-ID: <56EB6D3D.7000602@oracle.com> Hi Christoph, Thank you for taking care of this issue. Some minor comments: SSLSocketImpl.java ------------------ 1012 if (buffer != null && (buffer.limit() < inputRecord.bytesInCompletePacket(sockInput))) 1013 return 0; 1. It would be nice to keep the line less than 80 characters. 2. In general, braces ('{' and '}') should always be used for 'if' statement. 3. It is safer to replace buffer.limit() with buffer.remaining(). LargePacketAfterHandshakeTest.java ---------------------------------- See #1, too. 4. The client thread may try to connect to server before server ready. As may result in intermittent failure. In the template, test/javax/net/ssl/templates/SSLSocketTemplate.java, a serverReady variable is used to keep the pace of client and server. Just for your reference. Thanks, Xuelei On 3/17/2016 5:28 AM, Langer, Christoph wrote: > Hi, > > > > I think I?ve found a way to fix the issue which looks quite reasonable > to me. Would you please comment/review it? I?ve also included a test to > reproduce the issue. > > > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8149169.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149169 > > > > Thanks and best regards > > Christoph > > > > *From:*Langer, Christoph > *Sent:* Dienstag, 15. M?rz 2016 23:00 > *To:* security-dev at openjdk.java.net > *Subject:* Regarding JDK-8149169 - > SSLSocketInputRecord.decodeInputRecord buffer overflow > > > > Hi there, > > > > today I did some debugging regarding the TLS exception I?ve seen and > reported in JDK-8149169: > > > > javax.net.ssl.SSLException: java.nio.BufferOverflowException > at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) > at > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) > at > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) > at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) > at > sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) > > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) > > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439) > > at > java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:319) > > > at > com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.java:42) > > at > com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) > Caused by: java.nio.BufferOverflowException > at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) > at > sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:226) > > at > sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) > at > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) > at > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) > at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) > ... 12 more > > > > I think the problem is with the logic in > sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The > read method calls the readRecord(buffer) method of the socket > (SSLSocketImpl) and hands it the buffer to be eventually filled by > SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with > 4K and before readRecord is called, the packet length is verified (in > line 144: int packetLen = socket.bytesInCompletePacket();) and the > buffer reallocated if the incoming package would be larger than the > buffer. However, in my case, the incoming package is a handshake package > of a small size, so the buffer won?t be adjusted. Then, after the > handshake is done, the real data packet is read, still within > SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this > one has a length of more than 4K. So the buffer will be too small in > decodeInputRecord and hence the exception is thrown. > > > > So, basically the issue will appear if the TLS data package following > immediately after a server initiated handshake will be larger than the > buffer of AppInputStream. I guess that should be easily recreatable in a > small test case. > > > > Now the question how to fix? I can see 3 options: > > a) Just allocate the ByteBuffer in AppInputStream to > SSLRecord.maxLargeRecordSize (about 32K) ? easiest fix and removing the > need to check the length for each record. But I guess this is not > desired as the buffer is unnecessarily large for most cases? > > b) Extend SSLSocketInputRecord somehow to be able to not only read > the length of the incoming packet but also the type, e.g. if it is a > handshake. In that case the buffer would need to be extended to > SSLRecord.maxLargeRecordSize. But why not do a) then?? > > c) Check the volume bytes returned from readRecord and redo the > read in case the volume is larger than the buffer capacity > > > > Which way should I pursue? Do you see another option? Or am I getting > something completely wrong running into an illegal case? > > > > Thanks in advance for your feedback, > > Christoph > > > From christoph.langer at sap.com Fri Mar 18 09:29:19 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Mar 2016 09:29:19 +0000 Subject: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow In-Reply-To: <56EB6D3D.7000602@oracle.com> References: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> <56EB6D3D.7000602@oracle.com> Message-ID: Hi Xuelei, thanks for your feedback. I tried to address all your points and made the test case more robust. For SSLSocketImpl I also took the chance to remove 2 unused fields, hope that's ok. And I put the buffer length check in the block of handling non null buffer input. If you are satisfied with my adaptions, it would be great if you could push the change for me as I'm no committer yet. Thanks & Best regards Christoph > -----Original Message----- > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf > Of Xuelei Fan > Sent: Freitag, 18. M?rz 2016 03:52 > To: security-dev at openjdk.java.net > Subject: Re: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord > buffer overflow > > Hi Christoph, > > Thank you for taking care of this issue. Some minor comments: > > SSLSocketImpl.java > ------------------ > 1012 if (buffer != null && (buffer.limit() < > inputRecord.bytesInCompletePacket(sockInput))) > 1013 return 0; > > 1. It would be nice to keep the line less than 80 characters. > 2. In general, braces ('{' and '}') should always be used for 'if' > statement. > 3. It is safer to replace buffer.limit() with buffer.remaining(). > > LargePacketAfterHandshakeTest.java > ---------------------------------- > See #1, too. > > 4. The client thread may try to connect to server before server ready. > As may result in intermittent failure. > > In the template, test/javax/net/ssl/templates/SSLSocketTemplate.java, a > serverReady variable is used to keep the pace of client and server. > Just for your reference. > > Thanks, > Xuelei > > On 3/17/2016 5:28 AM, Langer, Christoph wrote: > > Hi, > > > > > > > > I think I've found a way to fix the issue which looks quite reasonable > > to me. Would you please comment/review it? I've also included a test to > > reproduce the issue. > > > > > > > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8149169.1/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149169 > > > > > > > > Thanks and best regards > > > > Christoph > > > > > > > > *From:*Langer, Christoph > > *Sent:* Dienstag, 15. M?rz 2016 23:00 > > *To:* security-dev at openjdk.java.net > > *Subject:* Regarding JDK-8149169 - > > SSLSocketInputRecord.decodeInputRecord buffer overflow > > > > > > > > Hi there, > > > > > > > > today I did some debugging regarding the TLS exception I've seen and > > reported in JDK-8149169: > > > > > > > > javax.net.ssl.SSLException: java.nio.BufferOverflowException > > at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) > > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) > > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) > > at > > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) > > at > > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) > > at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) > > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) > > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) > > at > > sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) > > > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) > > > > at > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConne > ction.java:1534) > > > nnection.java:1534%29> > > at > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec > tion.java:1439) > > > nection.java:1439%29> > > at > > java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) > > at > > > sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsU > RLConnectionImpl.java:319) > > > sURLConnectionImpl.java:319%29> > > > > at > > > com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.j > ava:42) > > > > at > > com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) > > Caused by: java.nio.BufferOverflowException > > at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) > > at > > > sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecor > d.java:226) > > > > at > > sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) > > at > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) > > at > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) > > at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) > > ... 12 more > > > > > > > > I think the problem is with the logic in > > sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The > > read method calls the readRecord(buffer) method of the socket > > (SSLSocketImpl) and hands it the buffer to be eventually filled by > > SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with > > 4K and before readRecord is called, the packet length is verified (in > > line 144: int packetLen = socket.bytesInCompletePacket();) and the > > buffer reallocated if the incoming package would be larger than the > > buffer. However, in my case, the incoming package is a handshake package > > of a small size, so the buffer won't be adjusted. Then, after the > > handshake is done, the real data packet is read, still within > > SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this > > one has a length of more than 4K. So the buffer will be too small in > > decodeInputRecord and hence the exception is thrown. > > > > > > > > So, basically the issue will appear if the TLS data package following > > immediately after a server initiated handshake will be larger than the > > buffer of AppInputStream. I guess that should be easily recreatable in a > > small test case. > > > > > > > > Now the question how to fix? I can see 3 options: > > > > a) Just allocate the ByteBuffer in AppInputStream to > > SSLRecord.maxLargeRecordSize (about 32K) - easiest fix and removing the > > need to check the length for each record. But I guess this is not > > desired as the buffer is unnecessarily large for most cases? > > > > b) Extend SSLSocketInputRecord somehow to be able to not only read > > the length of the incoming packet but also the type, e.g. if it is a > > handshake. In that case the buffer would need to be extended to > > SSLRecord.maxLargeRecordSize. But why not do a) then?? > > > > c) Check the volume bytes returned from readRecord and redo the > > read in case the volume is larger than the buffer capacity > > > > > > > > Which way should I pursue? Do you see another option? Or am I getting > > something completely wrong running into an illegal case? > > > > > > > > Thanks in advance for your feedback, > > > > Christoph > > > > > > From christoph.langer at sap.com Fri Mar 18 09:33:32 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Mar 2016 09:33:32 +0000 Subject: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow References: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> <56EB6D3D.7000602@oracle.com> Message-ID: Sorry, forgot the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8149169.2/ > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 18. M?rz 2016 10:29 > To: 'Xuelei Fan' > Cc: security-dev at openjdk.java.net > Subject: RE: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord > buffer overflow > > Hi Xuelei, > > thanks for your feedback. I tried to address all your points and made the test > case more robust. > > For SSLSocketImpl I also took the chance to remove 2 unused fields, hope that's > ok. And I put the buffer length check in the block of handling non null buffer > input. > > If you are satisfied with my adaptions, it would be great if you could push the > change for me as I'm no committer yet. > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On > Behalf > > Of Xuelei Fan > > Sent: Freitag, 18. M?rz 2016 03:52 > > To: security-dev at openjdk.java.net > > Subject: Re: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord > > buffer overflow > > > > Hi Christoph, > > > > Thank you for taking care of this issue. Some minor comments: > > > > SSLSocketImpl.java > > ------------------ > > 1012 if (buffer != null && (buffer.limit() < > > inputRecord.bytesInCompletePacket(sockInput))) > > 1013 return 0; > > > > 1. It would be nice to keep the line less than 80 characters. > > 2. In general, braces ('{' and '}') should always be used for 'if' > > statement. > > 3. It is safer to replace buffer.limit() with buffer.remaining(). > > > > LargePacketAfterHandshakeTest.java > > ---------------------------------- > > See #1, too. > > > > 4. The client thread may try to connect to server before server ready. > > As may result in intermittent failure. > > > > In the template, test/javax/net/ssl/templates/SSLSocketTemplate.java, a > > serverReady variable is used to keep the pace of client and server. > > Just for your reference. > > > > Thanks, > > Xuelei > > > > On 3/17/2016 5:28 AM, Langer, Christoph wrote: > > > Hi, > > > > > > > > > > > > I think I've found a way to fix the issue which looks quite reasonable > > > to me. Would you please comment/review it? I've also included a test to > > > reproduce the issue. > > > > > > > > > > > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8149169.1/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149169 > > > > > > > > > > > > Thanks and best regards > > > > > > Christoph > > > > > > > > > > > > *From:*Langer, Christoph > > > *Sent:* Dienstag, 15. M?rz 2016 23:00 > > > *To:* security-dev at openjdk.java.net > > > *Subject:* Regarding JDK-8149169 - > > > SSLSocketInputRecord.decodeInputRecord buffer overflow > > > > > > > > > > > > Hi there, > > > > > > > > > > > > today I did some debugging regarding the TLS exception I've seen and > > > reported in JDK-8149169: > > > > > > > > > > > > javax.net.ssl.SSLException: java.nio.BufferOverflowException > > > at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) > > > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) > > > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) > > > at > > > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) > > > at > > > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) > > > at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) > > > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > > > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) > > > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) > > > at > > > sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > > > > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) > > > > > > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) > > > > > > at > > > > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConne > > ction.java:1534) > > > > > > > nnection.java:1534%29> > > > at > > > > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec > > tion.java:1439) > > > > > > > nection.java:1439%29> > > > at > > > > java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) > > > at > > > > > > sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsU > > RLConnectionImpl.java:319) > > > > > > > sURLConnectionImpl.java:319%29> > > > > > > at > > > > > > com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.j > > ava:42) > > > > > > at > > > com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) > > > Caused by: java.nio.BufferOverflowException > > > at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) > > > at > > > > > > sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecor > > d.java:226) > > > > > > at > > > > sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) > > > at > > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) > > > at > > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) > > > at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) > > > ... 12 more > > > > > > > > > > > > I think the problem is with the logic in > > > sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The > > > read method calls the readRecord(buffer) method of the socket > > > (SSLSocketImpl) and hands it the buffer to be eventually filled by > > > SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with > > > 4K and before readRecord is called, the packet length is verified (in > > > line 144: int packetLen = socket.bytesInCompletePacket();) and the > > > buffer reallocated if the incoming package would be larger than the > > > buffer. However, in my case, the incoming package is a handshake package > > > of a small size, so the buffer won't be adjusted. Then, after the > > > handshake is done, the real data packet is read, still within > > > SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this > > > one has a length of more than 4K. So the buffer will be too small in > > > decodeInputRecord and hence the exception is thrown. > > > > > > > > > > > > So, basically the issue will appear if the TLS data package following > > > immediately after a server initiated handshake will be larger than the > > > buffer of AppInputStream. I guess that should be easily recreatable in a > > > small test case. > > > > > > > > > > > > Now the question how to fix? I can see 3 options: > > > > > > a) Just allocate the ByteBuffer in AppInputStream to > > > SSLRecord.maxLargeRecordSize (about 32K) - easiest fix and removing the > > > need to check the length for each record. But I guess this is not > > > desired as the buffer is unnecessarily large for most cases? > > > > > > b) Extend SSLSocketInputRecord somehow to be able to not only read > > > the length of the incoming packet but also the type, e.g. if it is a > > > handshake. In that case the buffer would need to be extended to > > > SSLRecord.maxLargeRecordSize. But why not do a) then?? > > > > > > c) Check the volume bytes returned from readRecord and redo the > > > read in case the volume is larger than the buffer capacity > > > > > > > > > > > > Which way should I pursue? Do you see another option? Or am I getting > > > something completely wrong running into an illegal case? > > > > > > > > > > > > Thanks in advance for your feedback, > > > > > > Christoph > > > > > > > > > From xuelei.fan at oracle.com Fri Mar 18 13:23:55 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 18 Mar 2016 21:23:55 +0800 Subject: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord buffer overflow In-Reply-To: References: <022658f870194ec5affdc4f57b7f1b04@DEWDFE13DE11.global.corp.sap> <56EB6D3D.7000602@oracle.com> Message-ID: <56EC016B.5080205@oracle.com> Looks fine to me. The test passed, and I pushed the changeset. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6a0479363ed Thanks, Xuelei On 3/18/2016 5:33 PM, Langer, Christoph wrote: > Sorry, forgot the new webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8149169.2/ > > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Freitag, 18. M?rz 2016 10:29 >> To: 'Xuelei Fan' >> Cc: security-dev at openjdk.java.net >> Subject: RE: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord >> buffer overflow >> >> Hi Xuelei, >> >> thanks for your feedback. I tried to address all your points and made the test >> case more robust. >> >> For SSLSocketImpl I also took the chance to remove 2 unused fields, hope that's >> ok. And I put the buffer length check in the block of handling non null buffer >> input. >> >> If you are satisfied with my adaptions, it would be great if you could push the >> change for me as I'm no committer yet. >> >> Thanks & Best regards >> Christoph >> >>> -----Original Message----- >>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On >> Behalf >>> Of Xuelei Fan >>> Sent: Freitag, 18. M?rz 2016 03:52 >>> To: security-dev at openjdk.java.net >>> Subject: Re: RFR (S): JDK-8149169 - SSLSocketInputRecord.decodeInputRecord >>> buffer overflow >>> >>> Hi Christoph, >>> >>> Thank you for taking care of this issue. Some minor comments: >>> >>> SSLSocketImpl.java >>> ------------------ >>> 1012 if (buffer != null && (buffer.limit() < >>> inputRecord.bytesInCompletePacket(sockInput))) >>> 1013 return 0; >>> >>> 1. It would be nice to keep the line less than 80 characters. >>> 2. In general, braces ('{' and '}') should always be used for 'if' >>> statement. >>> 3. It is safer to replace buffer.limit() with buffer.remaining(). >>> >>> LargePacketAfterHandshakeTest.java >>> ---------------------------------- >>> See #1, too. >>> >>> 4. The client thread may try to connect to server before server ready. >>> As may result in intermittent failure. >>> >>> In the template, test/javax/net/ssl/templates/SSLSocketTemplate.java, a >>> serverReady variable is used to keep the pace of client and server. >>> Just for your reference. >>> >>> Thanks, >>> Xuelei >>> >>> On 3/17/2016 5:28 AM, Langer, Christoph wrote: >>>> Hi, >>>> >>>> >>>> >>>> I think I've found a way to fix the issue which looks quite reasonable >>>> to me. Would you please comment/review it? I've also included a test to >>>> reproduce the issue. >>>> >>>> >>>> >>>> Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8149169.1/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149169 >>>> >>>> >>>> >>>> Thanks and best regards >>>> >>>> Christoph >>>> >>>> >>>> >>>> *From:*Langer, Christoph >>>> *Sent:* Dienstag, 15. M?rz 2016 23:00 >>>> *To:* security-dev at openjdk.java.net >>>> *Subject:* Regarding JDK-8149169 - >>>> SSLSocketInputRecord.decodeInputRecord buffer overflow >>>> >>>> >>>> >>>> Hi there, >>>> >>>> >>>> >>>> today I did some debugging regarding the TLS exception I've seen and >>>> reported in JDK-8149169: >>>> >>>> >>>> >>>> javax.net.ssl.SSLException: java.nio.BufferOverflowException >>>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214) >>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948) >>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900) >>>> at >>>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883) >>>> at >>>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809) >>>> at sun.security.ssl.AppInputStream.read(AppInputStream.java:173) >>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) >>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) >>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:345) >>>> at >>>> sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) >>>> >>>> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) >>>> >>>> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675) >>>> >>>> at >>>> >>> >> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConne >>> ction.java:1534) >>>> >>> >> >> nnection.java:1534%29> >>>> at >>>> >>> >> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec >>> tion.java:1439) >>>> >>> >> >> nection.java:1439%29> >>>> at >>>> >> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) >>>> at >>>> >>> >> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsU >>> RLConnectionImpl.java:319) >>>> >>> >> >> sURLConnectionImpl.java:319%29> >>>> >>>> at >>>> >>> >> com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.j >>> ava:42) >>>> >>>> at >>>> com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63) >>>> Caused by: java.nio.BufferOverflowException >>>> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206) >>>> at >>>> >>> >> sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecor >>> d.java:226) >>>> >>>> at >>>> >> sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178) >>>> at >>>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012) >>>> at >>>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957) >>>> at sun.security.ssl.AppInputStream.read(AppInputStream.java:159) >>>> ... 12 more >>>> >>>> >>>> >>>> I think the problem is with the logic in >>>> sun.security.ssl.AppInputStream. read(byte[] b, int off, int len). The >>>> read method calls the readRecord(buffer) method of the socket >>>> (SSLSocketImpl) and hands it the buffer to be eventually filled by >>>> SSLSocketInputRecord.decodeInputRecord(). The buffer is initialized with >>>> 4K and before readRecord is called, the packet length is verified (in >>>> line 144: int packetLen = socket.bytesInCompletePacket();) and the >>>> buffer reallocated if the incoming package would be larger than the >>>> buffer. However, in my case, the incoming package is a handshake package >>>> of a small size, so the buffer won't be adjusted. Then, after the >>>> handshake is done, the real data packet is read, still within >>>> SSLSocketImpl.readRecord() (e.g. line 1012 of SSLSocketImpl) and this >>>> one has a length of more than 4K. So the buffer will be too small in >>>> decodeInputRecord and hence the exception is thrown. >>>> >>>> >>>> >>>> So, basically the issue will appear if the TLS data package following >>>> immediately after a server initiated handshake will be larger than the >>>> buffer of AppInputStream. I guess that should be easily recreatable in a >>>> small test case. >>>> >>>> >>>> >>>> Now the question how to fix? I can see 3 options: >>>> >>>> a) Just allocate the ByteBuffer in AppInputStream to >>>> SSLRecord.maxLargeRecordSize (about 32K) - easiest fix and removing the >>>> need to check the length for each record. But I guess this is not >>>> desired as the buffer is unnecessarily large for most cases? >>>> >>>> b) Extend SSLSocketInputRecord somehow to be able to not only read >>>> the length of the incoming packet but also the type, e.g. if it is a >>>> handshake. In that case the buffer would need to be extended to >>>> SSLRecord.maxLargeRecordSize. But why not do a) then?? >>>> >>>> c) Check the volume bytes returned from readRecord and redo the >>>> read in case the volume is larger than the buffer capacity >>>> >>>> >>>> >>>> Which way should I pursue? Do you see another option? Or am I getting >>>> something completely wrong running into an illegal case? >>>> >>>> >>>> >>>> Thanks in advance for your feedback, >>>> >>>> Christoph >>>> >>>> >>>> > From anthony.scarpino at oracle.com Fri Mar 18 17:09:39 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 18 Mar 2016 10:09:39 -0700 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56D477F3.9030802@oracle.com> References: <56D477F3.9030802@oracle.com> Message-ID: <56EC3653.5080402@oracle.com> I believe I got everyone's comments. I've updated the webrev. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ Thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: > Currently CertPath algorithm restrictions allow or deny all > certificates. This change adds the ability to reject certificate chains > that contain a restricted algorithm and the chain terminates at a root > CA; therefore, allowing a self-signed or chain that does not terminate > at a root CA. > > https://bugs.openjdk.java.net/browse/JDK-8140422 > > Thanks > > Tony > From erik.joelsson at oracle.com Fri Mar 18 17:27:44 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Mar 2016 18:27:44 +0100 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56EC3653.5080402@oracle.com> References: <56D477F3.9030802@oracle.com> <56EC3653.5080402@oracle.com> Message-ID: <56EC3A90.80704@oracle.com> Much better, and thank you for fixing the existing mkdir/echo lines too. Just one nit, for this continuation: $(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \ -o $(GENDATA_CACERTSHASHER) please use tab+4spaces for the second line. No need to resend webrev for that. See [1] for our build system code conventions. [1] http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2016-03-18 18:09, Anthony Scarpino wrote: > I believe I got everyone's comments. I've updated the webrev. > > http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ > > Thanks > > Tony > > > On 02/29/2016 08:55 AM, Anthony Scarpino wrote: >> Currently CertPath algorithm restrictions allow or deny all >> certificates. This change adds the ability to reject certificate chains >> that contain a restricted algorithm and the chain terminates at a root >> CA; therefore, allowing a self-signed or chain that does not terminate >> at a root CA. >> >> https://bugs.openjdk.java.net/browse/JDK-8140422 >> >> Thanks >> >> Tony >> > From anthony.scarpino at oracle.com Fri Mar 18 17:34:39 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 18 Mar 2016 10:34:39 -0700 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56EC3A90.80704@oracle.com> References: <56D477F3.9030802@oracle.com> <56EC3653.5080402@oracle.com> <56EC3A90.80704@oracle.com> Message-ID: <56EC3C2F.1020000@oracle.com> ok.. thanks Tony On 03/18/2016 10:27 AM, Erik Joelsson wrote: > Much better, and thank you for fixing the existing mkdir/echo lines too. > Just one nit, for this continuation: > > $(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \ > -o $(GENDATA_CACERTSHASHER) > > please use tab+4spaces for the second line. No need to resend webrev for > that. See [1] for our build system code conventions. > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > /Erik > > On 2016-03-18 18:09, Anthony Scarpino wrote: >> I believe I got everyone's comments. I've updated the webrev. >> >> http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ >> >> Thanks >> >> Tony >> >> >> On 02/29/2016 08:55 AM, Anthony Scarpino wrote: >>> Currently CertPath algorithm restrictions allow or deny all >>> certificates. This change adds the ability to reject certificate chains >>> that contain a restricted algorithm and the chain terminates at a root >>> CA; therefore, allowing a self-signed or chain that does not terminate >>> at a root CA. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8140422 >>> >>> Thanks >>> >>> Tony >>> >> > From xuelei.fan at oracle.com Sat Mar 19 14:16:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 19 Mar 2016 22:16:06 +0800 Subject: Code Review Request, 8152221 Use try-with-resource in test templates Message-ID: <56ED5F26.4010200@oracle.com> Hi, Please review this test update for JDK-8152221: http://cr.openjdk.java.net/~xuelei/8152221/webrev.00/ The templates for SSL/TLS implementation testing are updated to use try-with-resource statements. Thanks, Xuelei From weijun.wang at oracle.com Sat Mar 19 15:03:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 19 Mar 2016 23:03:48 +0800 Subject: Code Review Request, 8152221 Use try-with-resource in test templates In-Reply-To: <56ED5F26.4010200@oracle.com> References: <56ED5F26.4010200@oracle.com> Message-ID: <45B5CCDD-A527-4482-914C-705900B65BCD@oracle.com> Great, looks fine. Thanks Max > On Mar 19, 2016, at 10:16 PM, Xuelei Fan wrote: > > Hi, > > Please review this test update for JDK-8152221: > > http://cr.openjdk.java.net/~xuelei/8152221/webrev.00/ > > The templates for SSL/TLS implementation testing are updated to use > try-with-resource statements. > > Thanks, > Xuelei From weijun.wang at oracle.com Mon Mar 21 05:15:51 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Mar 2016 13:15:51 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations Message-ID: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> Hi All Please take a review at the design and implementation of DRBG at: http://cr.openjdk.java.net/~weijun/8051408/webrev.07 http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html An example: SecureRandom drbg; byte[] buffer = new byte[32]; drbg = SecureRandom.getInstance("DRBG", DrbgParameters.instantiate(256, PR_ONLY, "hello".getBytes())); drbg.nextBytes(buffer, DrbgParameters.nextBytes(-1, false, "more".getBytes())); SecureRandomInstantiateParameters params = drbg.getParameters(); if (params instanceof DrbgParameters.Instantiate) { DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; if (ins.getCapability() != NONE) { drbg.reseed(DrbgParameters.reseed(false, "extra".getBytes())); } } Thanks Max From weijun.wang at oracle.com Mon Mar 21 05:23:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Mar 2016 13:23:52 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> Message-ID: > On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote: > > if (ins.getCapability() != NONE) { Ah, should be if (ins.getCapability() != NONE && ins.getCapability() != PR_ONLY) { --Max From anthony.scarpino at oracle.com Mon Mar 21 17:45:31 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 21 Mar 2016 10:45:31 -0700 Subject: [9] RFR: 8150512:Update test for jdk.security.provider.preferred security property. In-Reply-To: <6652cc38-bd6c-45a2-b122-109700bde7e5@default> References: <56D07778.9000409@oracle.com> <6652cc38-bd6c-45a2-b122-109700bde7e5@default> Message-ID: <56F0333B.4050205@oracle.com> Hi, The updated changes look fine. Thanks Tony On 03/15/2016 03:24 AM, Sibabrata Sahoo wrote: > Hi Anthony, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8150512/webrev.01/ > > Following comments associated. > > Thanks, > Siba > > > ------------------- > Here are my comments... > > - PreferredProviderTest.java:62-70 > You appear to be missing SHA1 and SHA-224. They should be added to the preferredProp variable, and the verifyDigestProvider DataTuple's. > > > - PreferredProviderTest.java:75-76 > This is calling MessageDigest with RSA as the algorithm, I would expect > this to fail, but the test looks like it expects it to pass. > The original code was creating a KeyFactory for RSA which would pass. > > thanks > > Tony > From sean.mullan at oracle.com Mon Mar 21 19:44:39 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Mar 2016 15:44:39 -0400 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56EC3653.5080402@oracle.com> References: <56D477F3.9030802@oracle.com> <56EC3653.5080402@oracle.com> Message-ID: <56F04F27.7080201@oracle.com> Looking good, mostly minor stuff: AlgorithmChecker ---------------- 151 if (trustedMatch && debug != null) debug.println("trustedMatch = true"); put braces around. java.security ------------- 553 # lib/security/cacerts.fingerprints file which is initially seeded with the lib/security/cacerts.properties file with a "restricted=yes" attribute which is ... 562 # chain that terminate at a distribution provided trust anchor and contain s/terminate/terminates/ s/contain/contains/ CaCertsHasher ------------- 40 * Fingerprint I recommend specifying a format for the attributes, and then defining a specific attribute that tags a cert as being restricted. This will make the properties file more generally useful if we want to add more attributes later. Ex: Fingerprint [attribute]{;attribute} 69 if (inFilename == null) { 70 System.err.println("Input file not defined."); 71 } 72 if (outFilename == null) { 73 System.err.println("Output file not defined."); 74 } You should not continue on error in these cases. I think you should just change these to: 69 if (inFilename == null) { 70 throw new Exception("Input file not defined."); 71 } 72 if (outFilename == null) { 73 throw new Exception("Output file not defined."); 74 } 81 PrintStream out = new PrintStream(outFilename); should use try-with-resources to avoid having to close the file. 88 if (verbose) { 89 System.out.println("No certificates in " + inFilename + 90 ". Hash file not created"); 91 } But you already created the file on line 81. 103 prop.store(out, c.getIssuerX500Principal().getName()); Maybe you should use the keystore alias here instead. DNs can be very long. AnchorCertificates ------------------ 40 * anchor certificate is in the cacerts.fingerprints file which is 43 * file but not the cacerts.fingerprints file would not be a match. s/cacerts.fingerprints/cacerts.properties/ --Sean On 03/18/2016 01:09 PM, Anthony Scarpino wrote: > I believe I got everyone's comments. I've updated the webrev. > > http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ > > Thanks > > Tony > > > On 02/29/2016 08:55 AM, Anthony Scarpino wrote: >> Currently CertPath algorithm restrictions allow or deny all >> certificates. This change adds the ability to reject certificate chains >> that contain a restricted algorithm and the chain terminates at a root >> CA; therefore, allowing a self-signed or chain that does not terminate >> at a root CA. >> >> https://bugs.openjdk.java.net/browse/JDK-8140422 >> >> Thanks >> >> Tony >> > From weijun.wang at oracle.com Tue Mar 22 01:01:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 22 Mar 2016 09:01:40 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> Message-ID: <3079167F-075B-4EEF-9EDE-DA966086689B@oracle.com> > On Mar 21, 2016, at 1:23 PM, Wang Weijun wrote: > > >> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote: >> >> if (ins.getCapability() != NONE) { > > Ah, should be > > if (ins.getCapability() != NONE && ins.getCapability() != PR_ONLY) { Oh, back to if (ins.getCapability() != NONE) { because I just removed PR_ONLY in the webrev. I was thinking about an existing provider, that claims it supports PR but only implements the old abstract methods, thus no reseed. Thinking again, since it also has not added the constructor with params, it will not be chosen by getInstance(alg,params) and also does not support getParameters(). Therefore it has nothing to do with the Capability class. --Max > > --Max > From Xuelei.Fan at Oracle.COM Wed Mar 23 03:26:34 2016 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Wed, 23 Mar 2016 11:26:34 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO Message-ID: <56F20CEA.9030105@Oracle.COM> Hi, Please review the update for the supporting of BigInteger.TWO: http://cr.openjdk.java.net/~xuelei/8152237/webrev/ BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. Thanks, Xuelei From weijun.wang at oracle.com Wed Mar 23 04:10:19 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 12:10:19 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F20CEA.9030105@Oracle.COM> References: <56F20CEA.9030105@Oracle.COM> Message-ID: <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? Thanks Max > On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: > > Hi, > > Please review the update for the supporting of BigInteger.TWO: > > http://cr.openjdk.java.net/~xuelei/8152237/webrev/ > > BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. > > Thanks, > Xuelei From Xuelei.Fan at Oracle.COM Wed Mar 23 04:48:14 2016 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Wed, 23 Mar 2016 12:48:14 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> Message-ID: <56F2200E.6030204@Oracle.COM> On 3/23/2016 12:10 PM, Wang Weijun wrote: > Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? > There are also uses in security components. I will make the update in another bug. Thanks, Xuelei > Thanks > Max > >> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >> >> Hi, >> >> Please review the update for the supporting of BigInteger.TWO: >> >> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >> >> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Wed Mar 23 07:34:38 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 15:34:38 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F2200E.6030204@Oracle.COM> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> Message-ID: <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> > On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: > > On 3/23/2016 12:10 PM, Wang Weijun wrote: >> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? >> > There are also uses in security components. I will make the update in another bug. I see. But why is ObjectIdentifier.java included in this fix? In you only keep BigInteger and BigDecimal, then I have no other comment. Thanks Max > > Thanks, > Xuelei > >> Thanks >> Max >> >>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Please review the update for the supporting of BigInteger.TWO: >>> >>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>> >>> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >>> >>> Thanks, >>> Xuelei >> > From weijun.wang at oracle.com Wed Mar 23 08:12:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 16:12:27 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <56C3381E.4070903@oracle.com> <9b8fd97d-852e-ec62-c481-f68d2e6be8da@oracle.com> <4E118FCE-0D69-4F32-B8FA-21DA9830AD23@oracle.com> <1A423858-F07C-4ECA-BD9B-14B78165407E@oracle.com> <2CFD24DE-8CE5-49AF-B3A2-E5EC9AB3D375@oracle.com> <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> Message-ID: <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> > >> The SunPKCS11 compatibility line will be add in a sub-patch for jake. >> > > You can send me the jake?s delta patch once you push the change to jdk9/dev. I've been busy recently on DRBG and will be back working on this one. Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related codes and directly push a single changeset to jdk9/dev. Right? Thanks Max > > Thanks > Mandy From Alan.Bateman at oracle.com Wed Mar 23 08:20:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 08:20:47 +0000 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> Message-ID: <56F251DF.3080208@oracle.com> On 23/03/2016 08:12, Wang Weijun wrote: > Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related codes and directly push a single changeset to jdk9/dev. Right? > Yes, changes like this this can be pushed via jdk9/dev. In the mean-time, we will continue to work in jigsaw/jake as there are many core areas where we'll need to prototype and iterate on. Some of these changes might be disruptive and/or require coordinated changes to the compiler and runtime so we'll work on them here before they go into jdk9/dev. -Alan From sean.coffey at oracle.com Wed Mar 23 08:43:37 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 23 Mar 2016 08:43:37 +0000 Subject: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange In-Reply-To: <56E7E53D.5010702@oracle.com> References: <56E197BB.7090800@oracle.com> <56E7DB36.60701@oracle.com> <56e7e40e.e853c20a.2952d.ffffc186@mx.google.com> <56E7E53D.5010702@oracle.com> Message-ID: <56F25739.1080203@oracle.com> Looks ok to me Xuelei - tricky one to test, we should ensure some 3rd party interoperability testing is run. Would it make sense to append to the exception message to the debug message on line 135 ? i.e. > 132 if (debug != null && Debug.isOn("handshake")) { > 133 System.out.println("The Cipher provider " + > 134 cipher.getProvider().getName() + > 135 " caused exception : " + iue.getMessage()); > 136 } Regards, Sean. On 15/03/2016 10:34, Xuelei Fan wrote: > On 3/15/2016 6:29 PM, Bernd Eckenfels wrote: >> >> >> BTW, the System.out is already in the existing code, but I wonder if >> this should use Debug.println instead? >> > Better to use Debug.println(). I will make the update in an separate > debug log improvement enhancement. > > Thanks, > Xuelei > >> >> >> Gruss >> >> Bernd >> -- >> http://bernd.eckenfels.net >> >> >> >> *Von: *Xuelei Fan >> *Gesendet: *Dienstag, 15. M?rz 2016 11:02 >> *An: *OpenJDK >> *Betreff: *Re: Code Review Request 8149017 Delayed provider selection >> broken inRSA client key exchange >> >> >> >> Ping ... >> >> >> >> On 3/10/2016 11:50 PM, Xuelei Fan wrote: >> >>> Hi, >>> Please review this update: >>> http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ >>> The problem is that calling Cipher.getProvider, or any method on Cipher, >>> forces the Cipher instance to skip the delayed provider selection which >>> is built into Cipher. >>> In this update, Cipher.init() was changed to be the first call to an >>> instance of Cipher. >>> Thanks, >>> Xuelei >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Mar 23 09:06:36 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Mar 2016 17:06:36 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> Message-ID: <56F25C9C.7080900@oracle.com> On 3/23/2016 3:34 PM, Wang Weijun wrote: > >> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >> >> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? >>> >> There are also uses in security components. I will make the update in another bug. > > I see. But why is ObjectIdentifier.java included in this fix? > It happens that the other bug touch those files, but ObjectIdentifier.java is not related to that bug. Does it make sense? Thanks, Xuelei > In you only keep BigInteger and BigDecimal, then I have no other comment. > > Thanks > Max > >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >>>> >>>> Hi, >>>> >>>> Please review the update for the supporting of BigInteger.TWO: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>>> >>>> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From xuelei.fan at oracle.com Wed Mar 23 09:20:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Mar 2016 17:20:16 +0800 Subject: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange In-Reply-To: <56F25739.1080203@oracle.com> References: <56E197BB.7090800@oracle.com> <56E7DB36.60701@oracle.com> <56e7e40e.e853c20a.2952d.ffffc186@mx.google.com> <56E7E53D.5010702@oracle.com> <56F25739.1080203@oracle.com> Message-ID: <56F25FD0.60200@oracle.com> On 3/23/2016 4:43 PM, Se?n Coffey wrote: > Looks ok to me Xuelei - tricky one to test, we should ensure some 3rd > party interoperability testing is run. > Would it make sense to append to the exception message to the debug > message on line 135 ? i.e. >> 132 if (debug != null && Debug.isOn("handshake")) { >> 133 System.out.println("The Cipher provider " + >> 134 cipher.getProvider().getName() + >> 135 " caused exception : " + iue.getMessage()); >> 136 } > Good point. I updated the webrev for the tracking of this change. http://cr.openjdk.java.net/~xuelei/8149017/webrev.01/ Thanks, Xuelei > Regards, > Sean. > > On 15/03/2016 10:34, Xuelei Fan wrote: >> On 3/15/2016 6:29 PM, Bernd Eckenfels wrote: >>> >>> >>> BTW, the System.out is already in the existing code, but I wonder if >>> this should use Debug.println instead? >>> >> Better to use Debug.println(). I will make the update in an separate >> debug log improvement enhancement. >> >> Thanks, >> Xuelei >> >>> >>> >>> Gruss >>> >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> >>> >>> >>> *Von: *Xuelei Fan >>> *Gesendet: *Dienstag, 15. M?rz 2016 11:02 >>> *An: *OpenJDK >>> *Betreff: *Re: Code Review Request 8149017 Delayed provider selection >>> broken inRSA client key exchange >>> >>> >>> >>> Ping ... >>> >>> >>> >>> On 3/10/2016 11:50 PM, Xuelei Fan wrote: >>> >>>> Hi, >>>> Please review this update: >>>> http://cr.openjdk.java.net/~xuelei/8149017/webrev.00/ >>>> The problem is that calling Cipher.getProvider, or any method on Cipher, >>>> forces the Cipher instance to skip the delayed provider selection which >>>> is built into Cipher. >>>> In this update, Cipher.init() was changed to be the first call to an >>>> instance of Cipher. >>>> Thanks, >>>> Xuelei >>> >>> >>> >>> > From weijun.wang at oracle.com Wed Mar 23 09:44:02 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 17:44:02 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F25C9C.7080900@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> Message-ID: Then why not fix the 2 bugs in a single changeset? --Max > ? 2016?3?23??17:06?Xuelei Fan ??? > >> On 3/23/2016 3:34 PM, Wang Weijun wrote: >> >>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >>> >>> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>>> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? >>> There are also uses in security components. I will make the update in another bug. >> >> I see. But why is ObjectIdentifier.java included in this fix? > It happens that the other bug touch those files, but > ObjectIdentifier.java is not related to that bug. > > Does it make sense? > > Thanks, > Xuelei > >> In you only keep BigInteger and BigDecimal, then I have no other comment. >> >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the update for the supporting of BigInteger.TWO: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>>>> >>>>> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >>>>> >>>>> Thanks, >>>>> Xuelei > From xuelei.fan at oracle.com Wed Mar 23 11:23:05 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Mar 2016 19:23:05 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> Message-ID: <56F27C99.8020709@oracle.com> On 3/23/2016 5:44 PM, Wang Weijun wrote: > Then why not fix the 2 bugs in a single changeset? > Both need spec update approval. As they are completely different spec update, better to update in 2 enhancements. As you have concerns here, I removed ObjectIdentifier.java from this update. See the new webrev: http://cr.openjdk.java.net/~xuelei/8152237/webrev.01/ Xuelei > --Max > >> ? 2016?3?23??17:06?Xuelei Fan ??? >> >>> On 3/23/2016 3:34 PM, Wang Weijun wrote: >>> >>>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >>>> >>>> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>>>> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? >>>> There are also uses in security components. I will make the update in another bug. >>> >>> I see. But why is ObjectIdentifier.java included in this fix? >> It happens that the other bug touch those files, but >> ObjectIdentifier.java is not related to that bug. >> >> Does it make sense? >> >> Thanks, >> Xuelei >> >>> In you only keep BigInteger and BigDecimal, then I have no other comment. >>> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the update for the supporting of BigInteger.TWO: >>>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>>>>> >>>>>> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >> > From xuelei.fan at oracle.com Wed Mar 23 13:27:10 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Mar 2016 21:27:10 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <0E34A6DD-1EEF-4EBC-9C92-A07AF0D4B5B9@gmail.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> <56F27C99.8020709@oracle.com> <0E34A6DD-1EEF-4EBC-9C92-A07AF0D4B5B9@gmail.com> Message-ID: <56F299AE.9040803@oracle.com> Hi Attila, Good catch about the comparing. I updated the code in my local workspace, and I would ask for code review in another enhancement update soon. Thanks, Xuelei On 3/23/2016 9:15 PM, Attila Szegedi wrote: > Sorry for beating the dead horse of ObjectIdentifier.java change, but > I?d suggest that if that code is later revisited, it be changed to > "first.compareTo(BigInteger.TWO) > 0" instead of ?? == 1?. > > Comparing the return value of compareTo to zero (instead of relying on > specific set of return values) is the ?suggested idiom for performing > these comparisons" as per BigInteger JavaDoc[1] and consistent with the > contract of Comparable.compareTo (even though same BigInteger JavaDoc > also explicitly specifies that the return values in this particular case > are indeed -1, 0, and 1). > > Attila. > > [1] http://docs.oracle.com/javase/8/docs/api/java/math/BigInteger.html#compareTo-java.math.BigInteger- > >> On 23 Mar 2016, at 12:23, Xuelei Fan > > wrote: >> >> On 3/23/2016 5:44 PM, Wang Weijun wrote: >>> Then why not fix the 2 bugs in a single changeset? >>> >> Both need spec update approval. As they are completely different spec >> update, better to update in 2 enhancements. >> >> As you have concerns here, I removed ObjectIdentifier.java from this >> update. See the new webrev: >> >> http://cr.openjdk.java.net/~xuelei/8152237/webrev.01/ >> >> Xuelei >> >>> --Max >>> >>>> ? 2016?3?23??17:06?Xuelei Fan >>> > ??? >>>> >>>>> On 3/23/2016 3:34 PM, Wang Weijun wrote: >>>>> >>>>>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan >>>>> > wrote: >>>>>> >>>>>> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>>>>>> Only 3 files touched. Are you going to make the >>>>>>> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files >>>>>>> with another bug fix? >>>>>> There are also uses in security components. I will make the >>>>>> update in another bug. >>>>> >>>>> I see. But why is ObjectIdentifier.java included in this fix? >>>> It happens that the other bug touch those files, but >>>> ObjectIdentifier.java is not related to that bug. >>>> >>>> Does it make sense? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> In you only keep BigInteger and BigDecimal, then I have no other >>>>> comment. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the update for the supporting of BigInteger.TWO: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>>>>>>> >>>>>>>> BigInteger.valueOf(2) is a common BigInteger value used in >>>>>>>> binary and cryptography operation calculation. The >>>>>>>> BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) >>>>>>>> is used instead in applications and JDK components. The export >>>>>>>> of static BigInteger.TWO can improve performance and simplify >>>>>>>> existing code. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>> >>> >> > From weijun.wang at oracle.com Wed Mar 23 13:44:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 21:44:08 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F27C99.8020709@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> <56F27C99.8020709@oracle.com> Message-ID: <23FDECF6-41D2-474F-AA97-EE7072BE1FC2@oracle.com> > On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote: > > On 3/23/2016 5:44 PM, Wang Weijun wrote: >> Then why not fix the 2 bugs in a single changeset? >> > Both need spec update approval. As they are completely different spec > update, better to update in 2 enhancements. > > As you have concerns here, I removed ObjectIdentifier.java from this > update. See the new webrev: > > http://cr.openjdk.java.net/~xuelei/8152237/webrev.01/ Looks good to me. --Max > > Xuelei From xuelei.fan at oracle.com Wed Mar 23 14:02:30 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 23 Mar 2016 22:02:30 +0800 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <23FDECF6-41D2-474F-AA97-EE7072BE1FC2@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> <56F27C99.8020709@oracle.com> <23FDECF6-41D2-474F-AA97-EE7072BE1FC2@oracle.com> Message-ID: <56F2A1F6.3060800@oracle.com> Thanks! Xuelei On 3/23/2016 9:44 PM, Wang Weijun wrote: > >> On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote: >> >> On 3/23/2016 5:44 PM, Wang Weijun wrote: >>> Then why not fix the 2 bugs in a single changeset? >>> >> Both need spec update approval. As they are completely different spec >> update, better to update in 2 enhancements. >> >> As you have concerns here, I removed ObjectIdentifier.java from this >> update. See the new webrev: >> >> http://cr.openjdk.java.net/~xuelei/8152237/webrev.01/ > > Looks good to me. > > --Max > >> >> Xuelei > From szegedia at gmail.com Wed Mar 23 13:15:57 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 23 Mar 2016 14:15:57 +0100 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F27C99.8020709@oracle.com> References: <56F20CEA.9030105@Oracle.COM> <596176BE-F825-4134-A528-28B22352B9E0@oracle.com> <56F2200E.6030204@Oracle.COM> <5B1C194C-40A8-45BA-8192-5179637E0794@oracle.com> <56F25C9C.7080900@oracle.com> <56F27C99.8020709@oracle.com> Message-ID: <0E34A6DD-1EEF-4EBC-9C92-A07AF0D4B5B9@gmail.com> Sorry for beating the dead horse of ObjectIdentifier.java change, but I?d suggest that if that code is later revisited, it be changed to "first.compareTo(BigInteger.TWO) > 0" instead of ?? == 1?. Comparing the return value of compareTo to zero (instead of relying on specific set of return values) is the ?suggested idiom for performing these comparisons" as per BigInteger JavaDoc[1] and consistent with the contract of Comparable.compareTo (even though same BigInteger JavaDoc also explicitly specifies that the return values in this particular case are indeed -1, 0, and 1). Attila. [1] http://docs.oracle.com/javase/8/docs/api/java/math/BigInteger.html#compareTo-java.math.BigInteger- > On 23 Mar 2016, at 12:23, Xuelei Fan wrote: > > On 3/23/2016 5:44 PM, Wang Weijun wrote: >> Then why not fix the 2 bugs in a single changeset? >> > Both need spec update approval. As they are completely different spec > update, better to update in 2 enhancements. > > As you have concerns here, I removed ObjectIdentifier.java from this > update. See the new webrev: > > http://cr.openjdk.java.net/~xuelei/8152237/webrev.01/ > > Xuelei > >> --Max >> >>> ? 2016?3?23??17:06?Xuelei Fan ??? >>> >>>> On 3/23/2016 3:34 PM, Wang Weijun wrote: >>>> >>>>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote: >>>>> >>>>> On 3/23/2016 12:10 PM, Wang Weijun wrote: >>>>>> Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? >>>>> There are also uses in security components. I will make the update in another bug. >>>> >>>> I see. But why is ObjectIdentifier.java included in this fix? >>> It happens that the other bug touch those files, but >>> ObjectIdentifier.java is not related to that bug. >>> >>> Does it make sense? >>> >>> Thanks, >>> Xuelei >>> >>>> In you only keep BigInteger and BigDecimal, then I have no other comment. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the update for the supporting of BigInteger.TWO: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >>>>>>> >>>>>>> BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Mar 23 18:01:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 23 Mar 2016 19:01:09 +0100 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F20CEA.9030105@Oracle.COM> References: <56F20CEA.9030105@Oracle.COM> Message-ID: <56F2D9E5.9050400@gmail.com> Hi Xuelei, On 03/23/2016 04:26 AM, Xuelei Fan wrote: > Hi, > > Please review the update for the supporting of BigInteger.TWO: > > http://cr.openjdk.java.net/~xuelei/8152237/webrev/ > > BigInteger.valueOf(2) is a common BigInteger value used in binary and > cryptography operation calculation. The BigInteger.TWO is not > exported, and hence BigInteger.valueOf(2) is used instead in > applications and JDK components. The export of static BigInteger.TWO > can improve performance and simplify existing code. > > Thanks, > Xuelei I think (haven't tried, just speculate) you could achieve the same performance by: - adding final qualifier to static BigInteger.[posConst|negConst] fields - annotating those fields with @jdk.internal.vm.annotation.Stable annotation This way BigInteger.valueOf(-MAX_CONSTANT <= i <= MAX_CONSTANT) when called with a constant argument should fold into a constant when compiled by JIT. The same optimization could be performed for valueOf methods of java.lang.Byte, Character, Short, Integer & Long. @Stable annotation was a package-private annotation in java.lang.invoke, reserved for method handles infrastructure, but has since been made public and moved to a concealed package of java.base. There is already a precedent for its use outside in java.lang.invoke: in java.lang.String. For example: static final String s = "....."; s.charAt(0); // is folded into a constant by JIT Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Mar 23 18:58:42 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 23 Mar 2016 19:58:42 +0100 Subject: Code Review Request, 8152237 Support BigInteger.TWO In-Reply-To: <56F2D9E5.9050400@gmail.com> References: <56F20CEA.9030105@Oracle.COM> <56F2D9E5.9050400@gmail.com> Message-ID: <56F2E762.6050903@gmail.com> Ok, here's a test... with just the following change: diff -r 9ea9fb3c0c88 src/java.base/share/classes/java/math/BigInteger.java --- a/src/java.base/share/classes/java/math/BigInteger.java Wed Mar 23 18:24:35 2016 +0100 +++ b/src/java.base/share/classes/java/math/BigInteger.java Wed Mar 23 19:55:01 2016 +0100 @@ -41,6 +41,7 @@ import jdk.internal.math.DoubleConsts; import jdk.internal.math.FloatConsts; import jdk.internal.HotSpotIntrinsicCandidate; +import jdk.internal.vm.annotation.Stable; /** * Immutable arbitrary-precision integers. All operations behave as if @@ -1213,8 +1214,10 @@ * Initialize static constant array when class is loaded. */ private static final int MAX_CONSTANT = 16; - private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; - private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; + @Stable + private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; + @Stable + private static final BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; /** * The cache of powers of each radix. This allows us to not have to The results of simple benchmark: /* Original: Benchmark Mode Cnt Score Error Units BigIntegerBench.ONE avgt 10 2.396 ? 0.232 ns/op BigIntegerBench.valueOf_1 avgt 10 2.846 ? 0.233 ns/op BigIntegerBench.valueOf_2 avgt 10 2.808 ? 0.054 ns/op Patched: Benchmark Mode Cnt Score Error Units BigIntegerBench.ONE avgt 10 2.381 ? 0.126 ns/op BigIntegerBench.valueOf_1 avgt 10 2.347 ? 0.089 ns/op BigIntegerBench.valueOf_2 avgt 10 2.323 ? 0.022 ns/op */ package jdk.test; import org.openjdk.jmh.annotations.*; import java.math.BigInteger; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.AverageTime) @Fork(1) @Warmup(iterations = 5) @Measurement(iterations = 10) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class BigIntegerBench { @Benchmark public BigInteger ONE() { return BigInteger.ONE; } @Benchmark public BigInteger valueOf_1() { return BigInteger.valueOf(1); } @Benchmark public BigInteger valueOf_2() { return BigInteger.valueOf(2); } } So, no need to change the API and all uses of valueOf(-MAX_CONSTANT <= i <= MAX_CONSTANT) for constant 'i' will be faster a bit. Regards, Peter On 03/23/2016 07:01 PM, Peter Levart wrote: > Hi Xuelei, > > On 03/23/2016 04:26 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the update for the supporting of BigInteger.TWO: >> >> http://cr.openjdk.java.net/~xuelei/8152237/webrev/ >> >> BigInteger.valueOf(2) is a common BigInteger value used in binary and >> cryptography operation calculation. The BigInteger.TWO is not >> exported, and hence BigInteger.valueOf(2) is used instead in >> applications and JDK components. The export of static BigInteger.TWO >> can improve performance and simplify existing code. >> >> Thanks, >> Xuelei > > I think (haven't tried, just speculate) you could achieve the same > performance by: > > - adding final qualifier to static BigInteger.[posConst|negConst] fields > - annotating those fields with @jdk.internal.vm.annotation.Stable > annotation > > This way BigInteger.valueOf(-MAX_CONSTANT <= i <= MAX_CONSTANT) when > called with a constant argument should fold into a constant when > compiled by JIT. > > The same optimization could be performed for valueOf methods of > java.lang.Byte, Character, Short, Integer & Long. > > @Stable annotation was a package-private annotation in > java.lang.invoke, reserved for method handles infrastructure, but has > since been made public and moved to a concealed package of java.base. > There is already a precedent for its use outside in java.lang.invoke: > in java.lang.String. For example: > > static final String s = "....."; > > s.charAt(0); // is folded into a constant by JIT > > > > Regards, Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Fri Mar 25 21:40:06 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 25 Mar 2016 14:40:06 -0700 Subject: [9] RFR: 8152798: Mark WeakCipherSuite.java as intermittently failing Message-ID: <56F5B036.1080506@oracle.com> Hello, The following DTLS test has been observed to intermittently fail: javax/net/ssl/DTLS/WeakCipherSuite.java Please see https://bugs.openjdk.java.net/browse/JDK-8138877 for details. Until this bug is fixed, the test should be marked accordingly. Please review the patch below which does this. diff -r 00d704eff42f test/javax/net/ssl/DTLS/WeakCipherSuite.java --- a/test/javax/net/ssl/DTLS/WeakCipherSuite.java Fri Mar 25 12:30:13 2016 -0700 +++ b/test/javax/net/ssl/DTLS/WeakCipherSuite.java Fri Mar 25 14:36:14 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ /* * @test * @bug 8043758 + * @key intermittent * @summary Datagram Transport Layer Security (DTLS) * @modules java.base/sun.security.util * @build DTLSOverDatagram Bug: https://bugs.openjdk.java.net/browse/JDK-8152798 Artem From Xuelei.Fan at Oracle.COM Fri Mar 25 22:05:54 2016 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Sat, 26 Mar 2016 06:05:54 +0800 Subject: [9] RFR: 8152798: Mark WeakCipherSuite.java as intermittently failing In-Reply-To: <56F5B036.1080506@oracle.com> References: <56F5B036.1080506@oracle.com> Message-ID: <56F5B642.9080204@Oracle.COM> It's fine. Thanks, Xuelei On 3/26/2016 5:40 AM, Artem Smotrakov wrote: > Hello, > > The following DTLS test has been observed to intermittently fail: > > javax/net/ssl/DTLS/WeakCipherSuite.java > > Please see https://bugs.openjdk.java.net/browse/JDK-8138877 for details. > > Until this bug is fixed, the test should be marked accordingly. Please > review the patch below which does this. > > diff -r 00d704eff42f test/javax/net/ssl/DTLS/WeakCipherSuite.java > --- a/test/javax/net/ssl/DTLS/WeakCipherSuite.java Fri Mar 25 > 12:30:13 2016 -0700 > +++ b/test/javax/net/ssl/DTLS/WeakCipherSuite.java Fri Mar 25 > 14:36:14 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -27,6 +27,7 @@ > /* > * @test > * @bug 8043758 > + * @key intermittent > * @summary Datagram Transport Layer Security (DTLS) > * @modules java.base/sun.security.util > * @build DTLSOverDatagram > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152798 > > Artem From anthony.scarpino at oracle.com Mon Mar 28 17:41:22 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 28 Mar 2016 10:41:22 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: <56F5C2F4.3040205@oracle.com> References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> Message-ID: <56F96CC2.9010506@oracle.com> [Switching to security-dev, core-lib-dev was bcc'ed] I don't see any problem changing it to int[][]. Being an Object[] is odd in my opinion. Tony On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: > This question is for core libs. > > For JIT to generate optimal code we want to change type of > AESCrypt::sessionK from Object[] to int[][]. > Otherwise JIT have to generate checkcast code to make sure that elements > of sessionK array are int[]. > I see that sessionK field is private so we are not changing public API. > > Thanks, > Vladimir > > On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >> Hi Vladimir, >> >> Thank you for your reviewing. >> >> Is it possible to modify the type of sessionK from Object[] to int[][]? >> >> We can guess, the type was designed for flexibility. However, only >> int[] is used >> to store elements of sessionK, so far. In addition, this field is >> private. >> Though adding checkcast is another solution, it produces overheads. >> >> I attached an additional patch (generated with hg diff -g) to jdk >> directory. >> I would like to ask thoughts about this change of java code. >> >> >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, >> IBM Research - Tokyo >> >> >> Vladimir Kozlov wrote on 03/24/2016 >> 09:09:11: >> >> > From: Vladimir Kozlov >> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >> > dev at openjdk.java.net" >> > Cc: "Doerr, Martin" , Tim Ellison >> > , "Simonis, Volker" >> > Date: 03/24/2016 09:19 >> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >> > >> > I think we need to add gen_checkcast for objAESCryptKey node since >> > java code has no guarantee that sessionK array elements are >> > initialized with int[]. Or we should modify java code to declare >> sessionK >> > as int[][]. >> > >> > Thanks, >> > Vladimir >> > >> > Note, intrinsics are correctly handle case when >> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >> > > Dear all: >> > > >> > > Can I please request reviews for the following change? >> > > This change was created for JDK 9 to enable POWER8's AES >> > > instructions for AES calculation. >> > > >> > > This request follows this discussion. >> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >> > March/021926.html >> > > >> > > Description: >> > > This change adds stub routines support for single-block AES >> > > encryption and decryption operations on the POWER8 platform. >> > > They are available only when the application is configured to >> > > use SunJCE crypto provider on little endian. >> > > >> > > These stubs make use of efficient hardware AES instructions >> > > and thus offer significant performance improvements over >> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >> > > are enabled by default on POWER8 platforms that support AES >> > > instructions (vcipher). They can be explicitly enabled or >> > > disabled on the command-line using UseAES and >> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >> > > and vnchiper of POWER8 need the same round keys of AES. >> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >> > > stub with AESCrypt.sessionK[0] as round keys. >> > > >> > > Summary of source code changes: >> > > >> > > *src/cpu/ppc/vm/assembler_ppc.hpp >> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >> > > - Adds support for vrld instruction to rotate vector register >> values >> > > with left doubleword. >> > > >> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >> > > - Defines stubs for single-block AES encryption and decryption >> > > routines supporting all key sizes (128, 192 and 256-bit). >> > > - Current POWER AES decryption instructions are not compatible >> > > with SunJCE expanded decryption key format. Thus decryption >> > > stubs read the expanded encryption keys (sessionK[0]) with >> > > descendant order. >> > > - Encryption stubs use SunJCE expanded encryption key as their >> > > is no incompatibility issue between POWER8 AES encryption >> > > instructions and SunJCE expanded encryption keys. >> > > >> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >> > > - Detects AES capabilities of the underlying CPU by using >> > > has_vcipher(). >> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >> > > CPU supports AES instructions and neither of them is >> explicitly >> > > disabled on the command-line. Generate warning message if >> > > either of these flags are enabled on the command-line >> > > whereas the underlying CPU does not support AES instructions. >> > > >> > > *src/share/vm/opto/library_call.cpp >> > > - Passes the first input parameter, reference to sessionK[0] >> to the >> > > AES stubs only on the POWER platform. >> > > >> > > *src/share/vm/opto/graphKit.cpp >> > > - Supports T_NARROWOOP type for GraphKit::load_array_element. >> > > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >> > > Webrev: >> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >> > > >> > > >> > > Regards, >> > > Hiroshi >> > > ----------------------- >> > > Hiroshi Horii, >> > > IBM Research - Tokyo >> > > >> > >> From joe.darcy at oracle.com Tue Mar 29 00:03:49 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 28 Mar 2016 17:03:49 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56E9F1A1.3040309@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> Message-ID: <56F9C665.7070706@oracle.com> Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 Thanks, -Joe On 3/16/2016 4:52 PM, Joseph D. Darcy wrote: > Hi Jon, > > Noted; I'll make that improvement in the next round. > > Thanks for pointing this out, > > -Joe > > On 3/16/2016 4:50 PM, Jonathan Gibbons wrote: >> >> >> On 03/11/2016 07:28 PM, joe darcy wrote: >>> Hello, >>> >>> As Jon Gibbons has noted off-list, the problem list entries can >>> directly include the bug number associated with the test in >>> question, enabling better reporting. This format should be used >>> rather than the current convention of putting the bug number in a >>> comment. >>> >>> Please review the webrev to adopt the revised format for the problem >>> list: >>> >>> http://cr.openjdk.java.net/~darcy/8151763.0/ >>> >>> I've verified jtreg produces the same test list with the old and new >>> versions of the problem list. >>> >>> Thanks, >>> >>> -Joe >> >> >> Joe, >> >> You can use a comma-separated list when multiple bugs are involved. >> The only restriction is, no embedded whitespace within the list >> >> 342 # Also 8080165 >> 343 java/util/Arrays/ParallelPrefix.java 8085982 generic-all >> >> can be >> >> 343 java/util/Arrays/ParallelPrefix.java 8085982,8080165 generic-all >> >> >> -- Jon > From mandy.chung at oracle.com Tue Mar 29 03:48:34 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Mar 2016 20:48:34 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56F9C665.7070706@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> Message-ID: > On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: > > Hello, > > New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. > > http://cr.openjdk.java.net/~darcy/8151763.1 > # tools/jimage/JImageTest.java linux-i586,windows-i586 Is this test accidentally removed? Other than this, looks okay. Nit: it?d be good to have most of bug ids aligned in the same column start. Here are a few ones: 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all Mandy From weijun.wang at oracle.com Tue Mar 29 08:47:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Mar 2016 16:47:46 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> Message-ID: Ping again. No comment? --Max > On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote: > > Hi All > > Please take a review at the design and implementation of DRBG at: > > http://cr.openjdk.java.net/~weijun/8051408/webrev.07 > http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html > > An example: > > SecureRandom drbg; > byte[] buffer = new byte[32]; > > drbg = SecureRandom.getInstance("DRBG", > DrbgParameters.instantiate(256, PR_ONLY, "hello".getBytes())); > > drbg.nextBytes(buffer, > DrbgParameters.nextBytes(-1, false, "more".getBytes())); > > SecureRandomInstantiateParameters params = drbg.getParameters(); > if (params instanceof DrbgParameters.Instantiate) { > DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; > if (ins.getCapability() != NONE) { > drbg.reseed(DrbgParameters.reseed(false, "extra".getBytes())); > } > } > > Thanks > Max > From volker.simonis at gmail.com Tue Mar 29 13:05:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Mar 2016 15:05:25 +0200 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: <56F96CC2.9010506@oracle.com> References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> Message-ID: Hi Anthony, Vladimir, thanks for your evaluation. Should I open a new bug for the change in AESCrypt or can we do it under the same bug id like the ppc-specific AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? I also think that the AESCrypt::sessionK type change change, although it is a class library change, should be done right in hs-comp together with the new ppc64 AES intrinsics. Do you agree? Regards, Volker On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino wrote: > [Switching to security-dev, core-lib-dev was bcc'ed] > > I don't see any problem changing it to int[][]. Being an Object[] is odd in > my opinion. > > Tony > > > On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >> >> This question is for core libs. >> >> For JIT to generate optimal code we want to change type of >> AESCrypt::sessionK from Object[] to int[][]. >> Otherwise JIT have to generate checkcast code to make sure that elements >> of sessionK array are int[]. >> I see that sessionK field is private so we are not changing public API. >> >> Thanks, >> Vladimir >> >> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>> >>> Hi Vladimir, >>> >>> Thank you for your reviewing. >>> >>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>> >>> We can guess, the type was designed for flexibility. However, only >>> int[] is used >>> to store elements of sessionK, so far. In addition, this field is >>> private. >>> Though adding checkcast is another solution, it produces overheads. >>> >>> I attached an additional patch (generated with hg diff -g) to jdk >>> directory. >>> I would like to ask thoughts about this change of java code. >>> >>> >>> >>> Regards, >>> Hiroshi >>> ----------------------- >>> Hiroshi Horii, >>> IBM Research - Tokyo >>> >>> >>> Vladimir Kozlov wrote on 03/24/2016 >>> 09:09:11: >>> >>> > From: Vladimir Kozlov >>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>> > dev at openjdk.java.net" >>> > Cc: "Doerr, Martin" , Tim Ellison >>> > , "Simonis, Volker" >>> > Date: 03/24/2016 09:19 >>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>> > >>> > I think we need to add gen_checkcast for objAESCryptKey node since >>> > java code has no guarantee that sessionK array elements are >>> > initialized with int[]. Or we should modify java code to declare >>> sessionK >>> > as int[][]. >>> > >>> > Thanks, >>> > Vladimir >>> > >>> > Note, intrinsics are correctly handle case when >>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>> > > Dear all: >>> > > >>> > > Can I please request reviews for the following change? >>> > > This change was created for JDK 9 to enable POWER8's AES >>> > > instructions for AES calculation. >>> > > >>> > > This request follows this discussion. >>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>> > March/021926.html >>> > > >>> > > Description: >>> > > This change adds stub routines support for single-block AES >>> > > encryption and decryption operations on the POWER8 platform. >>> > > They are available only when the application is configured to >>> > > use SunJCE crypto provider on little endian. >>> > > >>> > > These stubs make use of efficient hardware AES instructions >>> > > and thus offer significant performance improvements over >>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>> > > are enabled by default on POWER8 platforms that support AES >>> > > instructions (vcipher). They can be explicitly enabled or >>> > > disabled on the command-line using UseAES and >>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>> > > and vnchiper of POWER8 need the same round keys of AES. >>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>> > > stub with AESCrypt.sessionK[0] as round keys. >>> > > >>> > > Summary of source code changes: >>> > > >>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>> > > - Adds support for vrld instruction to rotate vector register >>> values >>> > > with left doubleword. >>> > > >>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>> > > - Defines stubs for single-block AES encryption and decryption >>> > > routines supporting all key sizes (128, 192 and 256-bit). >>> > > - Current POWER AES decryption instructions are not compatible >>> > > with SunJCE expanded decryption key format. Thus decryption >>> > > stubs read the expanded encryption keys (sessionK[0]) with >>> > > descendant order. >>> > > - Encryption stubs use SunJCE expanded encryption key as their >>> > > is no incompatibility issue between POWER8 AES encryption >>> > > instructions and SunJCE expanded encryption keys. >>> > > >>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>> > > - Detects AES capabilities of the underlying CPU by using >>> > > has_vcipher(). >>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>> > > CPU supports AES instructions and neither of them is >>> explicitly >>> > > disabled on the command-line. Generate warning message if >>> > > either of these flags are enabled on the command-line >>> > > whereas the underlying CPU does not support AES instructions. >>> > > >>> > > *src/share/vm/opto/library_call.cpp >>> > > - Passes the first input parameter, reference to sessionK[0] >>> to the >>> > > AES stubs only on the POWER platform. >>> > > >>> > > *src/share/vm/opto/graphKit.cpp >>> > > - Supports T_NARROWOOP type for GraphKit::load_array_element. >>> > > >>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>> > > Webrev: >>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>> > > >>> > > >>> > > Regards, >>> > > Hiroshi >>> > > ----------------------- >>> > > Hiroshi Horii, >>> > > IBM Research - Tokyo >>> > > >>> > >>> > From vladimir.kozlov at oracle.com Tue Mar 29 15:59:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2016 08:59:10 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> Message-ID: <56FAA64E.4040804@oracle.com> It could be done under the same bug id 8152172. It will be clear why we did that. Regards, Vladimir On 3/29/16 6:05 AM, Volker Simonis wrote: > Hi Anthony, Vladimir, > > thanks for your evaluation. Should I open a new bug for the change in > AESCrypt or can we do it under the same bug id like the ppc-specific > AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? > > I also think that the AESCrypt::sessionK type change change, although > it is a class library change, should be done right in hs-comp together > with the new ppc64 AES intrinsics. Do you agree? > > Regards, > Volker > > > On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino > wrote: >> [Switching to security-dev, core-lib-dev was bcc'ed] >> >> I don't see any problem changing it to int[][]. Being an Object[] is odd in >> my opinion. >> >> Tony >> >> >> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>> >>> This question is for core libs. >>> >>> For JIT to generate optimal code we want to change type of >>> AESCrypt::sessionK from Object[] to int[][]. >>> Otherwise JIT have to generate checkcast code to make sure that elements >>> of sessionK array are int[]. >>> I see that sessionK field is private so we are not changing public API. >>> >>> Thanks, >>> Vladimir >>> >>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>> >>>> Hi Vladimir, >>>> >>>> Thank you for your reviewing. >>>> >>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>> >>>> We can guess, the type was designed for flexibility. However, only >>>> int[] is used >>>> to store elements of sessionK, so far. In addition, this field is >>>> private. >>>> Though adding checkcast is another solution, it produces overheads. >>>> >>>> I attached an additional patch (generated with hg diff -g) to jdk >>>> directory. >>>> I would like to ask thoughts about this change of java code. >>>> >>>> >>>> >>>> Regards, >>>> Hiroshi >>>> ----------------------- >>>> Hiroshi Horii, >>>> IBM Research - Tokyo >>>> >>>> >>>> Vladimir Kozlov wrote on 03/24/2016 >>>> 09:09:11: >>>> >>>> > From: Vladimir Kozlov >>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>> > dev at openjdk.java.net" >>>> > Cc: "Doerr, Martin" , Tim Ellison >>>> > , "Simonis, Volker" >>>> > Date: 03/24/2016 09:19 >>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>> > >>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>> > java code has no guarantee that sessionK array elements are >>>> > initialized with int[]. Or we should modify java code to declare >>>> sessionK >>>> > as int[][]. >>>> > >>>> > Thanks, >>>> > Vladimir >>>> > >>>> > Note, intrinsics are correctly handle case when >>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>> > > Dear all: >>>> > > >>>> > > Can I please request reviews for the following change? >>>> > > This change was created for JDK 9 to enable POWER8's AES >>>> > > instructions for AES calculation. >>>> > > >>>> > > This request follows this discussion. >>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>> > March/021926.html >>>> > > >>>> > > Description: >>>> > > This change adds stub routines support for single-block AES >>>> > > encryption and decryption operations on the POWER8 platform. >>>> > > They are available only when the application is configured to >>>> > > use SunJCE crypto provider on little endian. >>>> > > >>>> > > These stubs make use of efficient hardware AES instructions >>>> > > and thus offer significant performance improvements over >>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>> > > are enabled by default on POWER8 platforms that support AES >>>> > > instructions (vcipher). They can be explicitly enabled or >>>> > > disabled on the command-line using UseAES and >>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>> > > >>>> > > Summary of source code changes: >>>> > > >>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>> > > - Adds support for vrld instruction to rotate vector register >>>> values >>>> > > with left doubleword. >>>> > > >>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>> > > - Defines stubs for single-block AES encryption and decryption >>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>> > > - Current POWER AES decryption instructions are not compatible >>>> > > with SunJCE expanded decryption key format. Thus decryption >>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>> > > descendant order. >>>> > > - Encryption stubs use SunJCE expanded encryption key as their >>>> > > is no incompatibility issue between POWER8 AES encryption >>>> > > instructions and SunJCE expanded encryption keys. >>>> > > >>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>> > > - Detects AES capabilities of the underlying CPU by using >>>> > > has_vcipher(). >>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>> > > CPU supports AES instructions and neither of them is >>>> explicitly >>>> > > disabled on the command-line. Generate warning message if >>>> > > either of these flags are enabled on the command-line >>>> > > whereas the underlying CPU does not support AES instructions. >>>> > > >>>> > > *src/share/vm/opto/library_call.cpp >>>> > > - Passes the first input parameter, reference to sessionK[0] >>>> to the >>>> > > AES stubs only on the POWER platform. >>>> > > >>>> > > *src/share/vm/opto/graphKit.cpp >>>> > > - Supports T_NARROWOOP type for GraphKit::load_array_element. >>>> > > >>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>> > > Webrev: >>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>> > > >>>> > > >>>> > > Regards, >>>> > > Hiroshi >>>> > > ----------------------- >>>> > > Hiroshi Horii, >>>> > > IBM Research - Tokyo >>>> > > >>>> > >>>> >> From valerie.peng at oracle.com Tue Mar 29 18:08:04 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 29 Mar 2016 11:08:04 -0700 Subject: RFR 8098580: drainRefQueueBounds() puts pressure on pool.size() In-Reply-To: <56D617C9.1040905@oracle.com> References: <56D617C9.1040905@oracle.com> Message-ID: <56FAC484.8030007@oracle.com> Hi, Tony, - line 243, 'be' should be "by"? - line 271, why use SESSION_MAX - 1 instead of just SESSION_MAX? The check on line 286 make sure that the queue will not be empty. Actually, the comment has "until only one is left", but the condition is ">1", so shouldn't it be "until 2 left"? This is not what u changed, just noticed it and wonder if I read the code wrong. - line 1114 and 1115, can we rename these 2 variables? The terms session and token are all over this SessionKeyRef class. Some are local, some are member fields. It'd make the code much more easier to follow if they are named something less common, say "sess" or "tok". - line 1126 - 1127, it's clearer to have {} to clearly separate the code. - After the while-true loop (line 1116 - 1134), don't you have to call token.releaseSession(session) again? Otherwise, the most recently allocated op session seems to not released back to the pool. - There was a session.token.isValid() check in the older dispose() method but not in the new one. Shouldn't we still check before getting a new op session? - The two dispose methods do entirely different things, it'd be better to name them differently. Thanks, Valerie On 3/1/2016 2:29 PM, Anthony Scarpino wrote: > Hi, > > I need a review of this change to SunPKCS11 where it's a bit smarter > in disposing of native library object by reusing the same pkcs11 > session is possible. Additionally changes to the session pool to fix > a performance bottleneck. > > http://cr.openjdk.java.net/~ascarpino/8098580/webrev/ > > thanks > > Tony > From joe.darcy at oracle.com Tue Mar 29 19:15:54 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 29 Mar 2016 12:15:54 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> Message-ID: <56FAD46A.4080803@oracle.com> Hi Mandy, On 3/28/2016 8:48 PM, Mandy Chung wrote: >> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: >> >> Hello, >> >> New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. >> >> http://cr.openjdk.java.net/~darcy/8151763.1 >> > # tools/jimage/JImageTest.java linux-i586,windows-i586 > > Is this test accidentally removed? Other than this, looks okay. The "#" lines are comments so I was removing a commented out line. (I assumed, but did not verify, the line for this test was a leftover artifact of the recent Jigsaw merge.) > > Nit: it?d be good to have most of bug ids aligned in the same column start. > Here are a few ones: > > 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac > 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug > 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug > 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all > 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all > 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all > > I was trying to avoid introducing lots of spacing changes in an attempt to make the patch easier to review, but I can look over these cases again. Thanks, -Joe From mandy.chung at oracle.com Tue Mar 29 19:31:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 Mar 2016 12:31:21 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56FAD46A.4080803@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> Message-ID: <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> > On Mar 29, 2016, at 12:15 PM, joe darcy wrote: > > Hi Mandy, > > On 3/28/2016 8:48 PM, Mandy Chung wrote: >>> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: >>> >>> Hello, >>> >>> New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. >>> >>> http://cr.openjdk.java.net/~darcy/8151763.1 >>> >> # tools/jimage/JImageTest.java linux-i586,windows-i586 >> >> Is this test accidentally removed? Other than this, looks okay. > > The "#" lines are comments so I was removing a commented out line. (I assumed, but did not verify, the line for this test was a leftover artifact of the recent Jigsaw merge.) I missed ?#? since this test should be excluded (some error might have been creeped in before the integration) This test needs to be added back in the problem list. I?ll create a changeset. > >> >> Nit: it?d be good to have most of bug ids aligned in the same column start. >> Here are a few ones: >> >> 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac >> 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug >> 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug >> 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all >> 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >> 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all >> 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all >> >> > > I was trying to avoid introducing lots of spacing changes in an attempt to make the patch easier to review, but I can look over these cases again. That?d be good. Thanks Mandy From anthony.scarpino at oracle.com Tue Mar 29 20:58:14 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 29 Mar 2016 13:58:14 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> Message-ID: <56FAEC66.9060606@oracle.com> Volker, Changing this with your other changes in hs-comp repo is best.. Just let me know when you are ready for code review on this piece. thanks Tony On 03/29/2016 06:05 AM, Volker Simonis wrote: > Hi Anthony, Vladimir, > > thanks for your evaluation. Should I open a new bug for the change in > AESCrypt or can we do it under the same bug id like the ppc-specific > AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? > > I also think that the AESCrypt::sessionK type change change, although > it is a class library change, should be done right in hs-comp together > with the new ppc64 AES intrinsics. Do you agree? > > Regards, > Volker > > > On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino > wrote: >> [Switching to security-dev, core-lib-dev was bcc'ed] >> >> I don't see any problem changing it to int[][]. Being an Object[] is odd in >> my opinion. >> >> Tony >> >> >> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>> >>> This question is for core libs. >>> >>> For JIT to generate optimal code we want to change type of >>> AESCrypt::sessionK from Object[] to int[][]. >>> Otherwise JIT have to generate checkcast code to make sure that elements >>> of sessionK array are int[]. >>> I see that sessionK field is private so we are not changing public API. >>> >>> Thanks, >>> Vladimir >>> >>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>> >>>> Hi Vladimir, >>>> >>>> Thank you for your reviewing. >>>> >>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>> >>>> We can guess, the type was designed for flexibility. However, only >>>> int[] is used >>>> to store elements of sessionK, so far. In addition, this field is >>>> private. >>>> Though adding checkcast is another solution, it produces overheads. >>>> >>>> I attached an additional patch (generated with hg diff -g) to jdk >>>> directory. >>>> I would like to ask thoughts about this change of java code. >>>> >>>> >>>> >>>> Regards, >>>> Hiroshi >>>> ----------------------- >>>> Hiroshi Horii, >>>> IBM Research - Tokyo >>>> >>>> >>>> Vladimir Kozlov wrote on 03/24/2016 >>>> 09:09:11: >>>> >>>> > From: Vladimir Kozlov >>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>> > dev at openjdk.java.net" >>>> > Cc: "Doerr, Martin" , Tim Ellison >>>> > , "Simonis, Volker" >>>> > Date: 03/24/2016 09:19 >>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>> > >>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>> > java code has no guarantee that sessionK array elements are >>>> > initialized with int[]. Or we should modify java code to declare >>>> sessionK >>>> > as int[][]. >>>> > >>>> > Thanks, >>>> > Vladimir >>>> > >>>> > Note, intrinsics are correctly handle case when >>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>> > > Dear all: >>>> > > >>>> > > Can I please request reviews for the following change? >>>> > > This change was created for JDK 9 to enable POWER8's AES >>>> > > instructions for AES calculation. >>>> > > >>>> > > This request follows this discussion. >>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>> > March/021926.html >>>> > > >>>> > > Description: >>>> > > This change adds stub routines support for single-block AES >>>> > > encryption and decryption operations on the POWER8 platform. >>>> > > They are available only when the application is configured to >>>> > > use SunJCE crypto provider on little endian. >>>> > > >>>> > > These stubs make use of efficient hardware AES instructions >>>> > > and thus offer significant performance improvements over >>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>> > > are enabled by default on POWER8 platforms that support AES >>>> > > instructions (vcipher). They can be explicitly enabled or >>>> > > disabled on the command-line using UseAES and >>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>> > > >>>> > > Summary of source code changes: >>>> > > >>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>> > > - Adds support for vrld instruction to rotate vector register >>>> values >>>> > > with left doubleword. >>>> > > >>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>> > > - Defines stubs for single-block AES encryption and decryption >>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>> > > - Current POWER AES decryption instructions are not compatible >>>> > > with SunJCE expanded decryption key format. Thus decryption >>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>> > > descendant order. >>>> > > - Encryption stubs use SunJCE expanded encryption key as their >>>> > > is no incompatibility issue between POWER8 AES encryption >>>> > > instructions and SunJCE expanded encryption keys. >>>> > > >>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>> > > - Detects AES capabilities of the underlying CPU by using >>>> > > has_vcipher(). >>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>> > > CPU supports AES instructions and neither of them is >>>> explicitly >>>> > > disabled on the command-line. Generate warning message if >>>> > > either of these flags are enabled on the command-line >>>> > > whereas the underlying CPU does not support AES instructions. >>>> > > >>>> > > *src/share/vm/opto/library_call.cpp >>>> > > - Passes the first input parameter, reference to sessionK[0] >>>> to the >>>> > > AES stubs only on the POWER platform. >>>> > > >>>> > > *src/share/vm/opto/graphKit.cpp >>>> > > - Supports T_NARROWOOP type for GraphKit::load_array_element. >>>> > > >>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>> > > Webrev: >>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>> > > >>>> > > >>>> > > Regards, >>>> > > Hiroshi >>>> > > ----------------------- >>>> > > Hiroshi Horii, >>>> > > IBM Research - Tokyo >>>> > > >>>> > >>>> >> From volker.simonis at gmail.com Wed Mar 30 10:29:31 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Mar 2016 12:29:31 +0200 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: <56FAEC66.9060606@oracle.com> References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> <56FAEC66.9060606@oracle.com> Message-ID: Hi everybody, here finally comes the updated version of Hiroshi's change (sorry for the delay): http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.hs/ http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.jdk/ With regard to the previous version it contains three small updates: - changed the type of AESCrypt::sessionK from Object[] to int[][] - also updated the type of the AESCrypt::sessionK field to "[[I" in LibraryCallKit::get_key_start_from_aescrypt_object() where it gets loaded. - protected the generation of the AES-stubs by "if (UseAES)" tp prevent them from beeing generated on ppc64 big endian. We need a sponsor to push these two changes in sync to hs-comp. Thank you and best regards, Volker On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino wrote: > Volker, > > Changing this with your other changes in hs-comp repo is best.. Just let me > know when you are ready for code review on this piece. > > thanks > > Tony > > > > > On 03/29/2016 06:05 AM, Volker Simonis wrote: >> >> Hi Anthony, Vladimir, >> >> thanks for your evaluation. Should I open a new bug for the change in >> AESCrypt or can we do it under the same bug id like the ppc-specific >> AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? >> >> I also think that the AESCrypt::sessionK type change change, although >> it is a class library change, should be done right in hs-comp together >> with the new ppc64 AES intrinsics. Do you agree? >> >> Regards, >> Volker >> >> >> On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino >> wrote: >>> >>> [Switching to security-dev, core-lib-dev was bcc'ed] >>> >>> I don't see any problem changing it to int[][]. Being an Object[] is odd >>> in >>> my opinion. >>> >>> Tony >>> >>> >>> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>>> >>>> >>>> This question is for core libs. >>>> >>>> For JIT to generate optimal code we want to change type of >>>> AESCrypt::sessionK from Object[] to int[][]. >>>> Otherwise JIT have to generate checkcast code to make sure that elements >>>> of sessionK array are int[]. >>>> I see that sessionK field is private so we are not changing public API. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>>> >>>>> >>>>> Hi Vladimir, >>>>> >>>>> Thank you for your reviewing. >>>>> >>>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>>> >>>>> We can guess, the type was designed for flexibility. However, only >>>>> int[] is used >>>>> to store elements of sessionK, so far. In addition, this field is >>>>> private. >>>>> Though adding checkcast is another solution, it produces overheads. >>>>> >>>>> I attached an additional patch (generated with hg diff -g) to jdk >>>>> directory. >>>>> I would like to ask thoughts about this change of java code. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Hiroshi >>>>> ----------------------- >>>>> Hiroshi Horii, >>>>> IBM Research - Tokyo >>>>> >>>>> >>>>> Vladimir Kozlov wrote on 03/24/2016 >>>>> 09:09:11: >>>>> >>>>> > From: Vladimir Kozlov >>>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>>> > dev at openjdk.java.net" >>>>> > Cc: "Doerr, Martin" , Tim Ellison >>>>> > , "Simonis, Volker" >>>>> >>>>> > Date: 03/24/2016 09:19 >>>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>>> > >>>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>>> > java code has no guarantee that sessionK array elements are >>>>> > initialized with int[]. Or we should modify java code to declare >>>>> sessionK >>>>> > as int[][]. >>>>> > >>>>> > Thanks, >>>>> > Vladimir >>>>> > >>>>> > Note, intrinsics are correctly handle case when >>>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>>> > > Dear all: >>>>> > > >>>>> > > Can I please request reviews for the following change? >>>>> > > This change was created for JDK 9 to enable POWER8's AES >>>>> > > instructions for AES calculation. >>>>> > > >>>>> > > This request follows this discussion. >>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>>> > March/021926.html >>>>> > > >>>>> > > Description: >>>>> > > This change adds stub routines support for single-block AES >>>>> > > encryption and decryption operations on the POWER8 platform. >>>>> > > They are available only when the application is configured to >>>>> > > use SunJCE crypto provider on little endian. >>>>> > > >>>>> > > These stubs make use of efficient hardware AES instructions >>>>> > > and thus offer significant performance improvements over >>>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>>> > > are enabled by default on POWER8 platforms that support AES >>>>> > > instructions (vcipher). They can be explicitly enabled or >>>>> > > disabled on the command-line using UseAES and >>>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>>> > > >>>>> > > Summary of source code changes: >>>>> > > >>>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>>> > > - Adds support for vrld instruction to rotate vector register >>>>> values >>>>> > > with left doubleword. >>>>> > > >>>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>> > > - Defines stubs for single-block AES encryption and >>>>> decryption >>>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>>> > > - Current POWER AES decryption instructions are not >>>>> compatible >>>>> > > with SunJCE expanded decryption key format. Thus >>>>> decryption >>>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>>> > > descendant order. >>>>> > > - Encryption stubs use SunJCE expanded encryption key as >>>>> their >>>>> > > is no incompatibility issue between POWER8 AES encryption >>>>> > > instructions and SunJCE expanded encryption keys. >>>>> > > >>>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>>> > > - Detects AES capabilities of the underlying CPU by using >>>>> > > has_vcipher(). >>>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>>> > > CPU supports AES instructions and neither of them is >>>>> explicitly >>>>> > > disabled on the command-line. Generate warning message if >>>>> > > either of these flags are enabled on the command-line >>>>> > > whereas the underlying CPU does not support AES >>>>> instructions. >>>>> > > >>>>> > > *src/share/vm/opto/library_call.cpp >>>>> > > - Passes the first input parameter, reference to sessionK[0] >>>>> to the >>>>> > > AES stubs only on the POWER platform. >>>>> > > >>>>> > > *src/share/vm/opto/graphKit.cpp >>>>> > > - Supports T_NARROWOOP type for >>>>> GraphKit::load_array_element. >>>>> > > >>>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>>> > > Webrev: >>>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>>> > > >>>>> > > >>>>> > > Regards, >>>>> > > Hiroshi >>>>> > > ----------------------- >>>>> > > Hiroshi Horii, >>>>> > > IBM Research - Tokyo >>>>> > > >>>>> > >>>>> >>> > From vladimir.kozlov at oracle.com Wed Mar 30 16:39:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2016 09:39:01 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> <56FAEC66.9060606@oracle.com> Message-ID: <56FC0125.7020700@oracle.com> Looks good. I will run hotspot compiler pre-integration testing and let you know results. Thanks, Vladimir On 3/30/16 3:29 AM, Volker Simonis wrote: > Hi everybody, > > here finally comes the updated version of Hiroshi's change (sorry for > the delay): > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.hs/ > http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.jdk/ > > With regard to the previous version it contains three small updates: > - changed the type of AESCrypt::sessionK from Object[] to int[][] > - also updated the type of the AESCrypt::sessionK field to "[[I" in > LibraryCallKit::get_key_start_from_aescrypt_object() where it gets > loaded. > - protected the generation of the AES-stubs by "if (UseAES)" tp > prevent them from beeing generated on ppc64 big endian. > > We need a sponsor to push these two changes in sync to hs-comp. > > Thank you and best regards, > Volker > > > On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino > wrote: >> Volker, >> >> Changing this with your other changes in hs-comp repo is best.. Just let me >> know when you are ready for code review on this piece. >> >> thanks >> >> Tony >> >> >> >> >> On 03/29/2016 06:05 AM, Volker Simonis wrote: >>> >>> Hi Anthony, Vladimir, >>> >>> thanks for your evaluation. Should I open a new bug for the change in >>> AESCrypt or can we do it under the same bug id like the ppc-specific >>> AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? >>> >>> I also think that the AESCrypt::sessionK type change change, although >>> it is a class library change, should be done right in hs-comp together >>> with the new ppc64 AES intrinsics. Do you agree? >>> >>> Regards, >>> Volker >>> >>> >>> On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino >>> wrote: >>>> >>>> [Switching to security-dev, core-lib-dev was bcc'ed] >>>> >>>> I don't see any problem changing it to int[][]. Being an Object[] is odd >>>> in >>>> my opinion. >>>> >>>> Tony >>>> >>>> >>>> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>>>> >>>>> >>>>> This question is for core libs. >>>>> >>>>> For JIT to generate optimal code we want to change type of >>>>> AESCrypt::sessionK from Object[] to int[][]. >>>>> Otherwise JIT have to generate checkcast code to make sure that elements >>>>> of sessionK array are int[]. >>>>> I see that sessionK field is private so we are not changing public API. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>>>> >>>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> Thank you for your reviewing. >>>>>> >>>>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>>>> >>>>>> We can guess, the type was designed for flexibility. However, only >>>>>> int[] is used >>>>>> to store elements of sessionK, so far. In addition, this field is >>>>>> private. >>>>>> Though adding checkcast is another solution, it produces overheads. >>>>>> >>>>>> I attached an additional patch (generated with hg diff -g) to jdk >>>>>> directory. >>>>>> I would like to ask thoughts about this change of java code. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Hiroshi >>>>>> ----------------------- >>>>>> Hiroshi Horii, >>>>>> IBM Research - Tokyo >>>>>> >>>>>> >>>>>> Vladimir Kozlov wrote on 03/24/2016 >>>>>> 09:09:11: >>>>>> >>>>>> > From: Vladimir Kozlov >>>>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>>>> > dev at openjdk.java.net" >>>>>> > Cc: "Doerr, Martin" , Tim Ellison >>>>>> > , "Simonis, Volker" >>>>>> >>>>>> > Date: 03/24/2016 09:19 >>>>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>>>> > >>>>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>>>> > java code has no guarantee that sessionK array elements are >>>>>> > initialized with int[]. Or we should modify java code to declare >>>>>> sessionK >>>>>> > as int[][]. >>>>>> > >>>>>> > Thanks, >>>>>> > Vladimir >>>>>> > >>>>>> > Note, intrinsics are correctly handle case when >>>>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>>>> > > Dear all: >>>>>> > > >>>>>> > > Can I please request reviews for the following change? >>>>>> > > This change was created for JDK 9 to enable POWER8's AES >>>>>> > > instructions for AES calculation. >>>>>> > > >>>>>> > > This request follows this discussion. >>>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>>>> > March/021926.html >>>>>> > > >>>>>> > > Description: >>>>>> > > This change adds stub routines support for single-block AES >>>>>> > > encryption and decryption operations on the POWER8 platform. >>>>>> > > They are available only when the application is configured to >>>>>> > > use SunJCE crypto provider on little endian. >>>>>> > > >>>>>> > > These stubs make use of efficient hardware AES instructions >>>>>> > > and thus offer significant performance improvements over >>>>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>>>> > > are enabled by default on POWER8 platforms that support AES >>>>>> > > instructions (vcipher). They can be explicitly enabled or >>>>>> > > disabled on the command-line using UseAES and >>>>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>>>> > > >>>>>> > > Summary of source code changes: >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>>>> > > - Adds support for vrld instruction to rotate vector register >>>>>> values >>>>>> > > with left doubleword. >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>> > > - Defines stubs for single-block AES encryption and >>>>>> decryption >>>>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>>>> > > - Current POWER AES decryption instructions are not >>>>>> compatible >>>>>> > > with SunJCE expanded decryption key format. Thus >>>>>> decryption >>>>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>>>> > > descendant order. >>>>>> > > - Encryption stubs use SunJCE expanded encryption key as >>>>>> their >>>>>> > > is no incompatibility issue between POWER8 AES encryption >>>>>> > > instructions and SunJCE expanded encryption keys. >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>>>> > > - Detects AES capabilities of the underlying CPU by using >>>>>> > > has_vcipher(). >>>>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>>>> > > CPU supports AES instructions and neither of them is >>>>>> explicitly >>>>>> > > disabled on the command-line. Generate warning message if >>>>>> > > either of these flags are enabled on the command-line >>>>>> > > whereas the underlying CPU does not support AES >>>>>> instructions. >>>>>> > > >>>>>> > > *src/share/vm/opto/library_call.cpp >>>>>> > > - Passes the first input parameter, reference to sessionK[0] >>>>>> to the >>>>>> > > AES stubs only on the POWER platform. >>>>>> > > >>>>>> > > *src/share/vm/opto/graphKit.cpp >>>>>> > > - Supports T_NARROWOOP type for >>>>>> GraphKit::load_array_element. >>>>>> > > >>>>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>>>> > > Webrev: >>>>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>>>> > > >>>>>> > > >>>>>> > > Regards, >>>>>> > > Hiroshi >>>>>> > > ----------------------- >>>>>> > > Hiroshi Horii, >>>>>> > > IBM Research - Tokyo >>>>>> > > >>>>>> > >>>>>> >>>> >> From vladimir.kozlov at oracle.com Wed Mar 30 16:43:57 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2016 09:43:57 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: <56FC0125.7020700@oracle.com> References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> <56FAEC66.9060606@oracle.com> <56FC0125.7020700@oracle.com> Message-ID: <56FC024D.2070302@oracle.com> BTW, I am changing UseAES check in stubs generation with UseAESIntrinsics check as we do for other intrinsics. Thanks, Vladimir On 3/30/16 9:39 AM, Vladimir Kozlov wrote: > Looks good. I will run hotspot compiler pre-integration testing and let you know results. > > Thanks, > Vladimir > > On 3/30/16 3:29 AM, Volker Simonis wrote: >> Hi everybody, >> >> here finally comes the updated version of Hiroshi's change (sorry for >> the delay): >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.hs/ >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.jdk/ >> >> With regard to the previous version it contains three small updates: >> - changed the type of AESCrypt::sessionK from Object[] to int[][] >> - also updated the type of the AESCrypt::sessionK field to "[[I" in >> LibraryCallKit::get_key_start_from_aescrypt_object() where it gets >> loaded. >> - protected the generation of the AES-stubs by "if (UseAES)" tp >> prevent them from beeing generated on ppc64 big endian. >> >> We need a sponsor to push these two changes in sync to hs-comp. >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino >> wrote: >>> Volker, >>> >>> Changing this with your other changes in hs-comp repo is best.. Just let me >>> know when you are ready for code review on this piece. >>> >>> thanks >>> >>> Tony >>> >>> >>> >>> >>> On 03/29/2016 06:05 AM, Volker Simonis wrote: >>>> >>>> Hi Anthony, Vladimir, >>>> >>>> thanks for your evaluation. Should I open a new bug for the change in >>>> AESCrypt or can we do it under the same bug id like the ppc-specific >>>> AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? >>>> >>>> I also think that the AESCrypt::sessionK type change change, although >>>> it is a class library change, should be done right in hs-comp together >>>> with the new ppc64 AES intrinsics. Do you agree? >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino >>>> wrote: >>>>> >>>>> [Switching to security-dev, core-lib-dev was bcc'ed] >>>>> >>>>> I don't see any problem changing it to int[][]. Being an Object[] is odd >>>>> in >>>>> my opinion. >>>>> >>>>> Tony >>>>> >>>>> >>>>> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>>>>> >>>>>> >>>>>> This question is for core libs. >>>>>> >>>>>> For JIT to generate optimal code we want to change type of >>>>>> AESCrypt::sessionK from Object[] to int[][]. >>>>>> Otherwise JIT have to generate checkcast code to make sure that elements >>>>>> of sessionK array are int[]. >>>>>> I see that sessionK field is private so we are not changing public API. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>>>>> >>>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thank you for your reviewing. >>>>>>> >>>>>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>>>>> >>>>>>> We can guess, the type was designed for flexibility. However, only >>>>>>> int[] is used >>>>>>> to store elements of sessionK, so far. In addition, this field is >>>>>>> private. >>>>>>> Though adding checkcast is another solution, it produces overheads. >>>>>>> >>>>>>> I attached an additional patch (generated with hg diff -g) to jdk >>>>>>> directory. >>>>>>> I would like to ask thoughts about this change of java code. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Hiroshi >>>>>>> ----------------------- >>>>>>> Hiroshi Horii, >>>>>>> IBM Research - Tokyo >>>>>>> >>>>>>> >>>>>>> Vladimir Kozlov wrote on 03/24/2016 >>>>>>> 09:09:11: >>>>>>> >>>>>>> > From: Vladimir Kozlov >>>>>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>>>>> > dev at openjdk.java.net" >>>>>>> > Cc: "Doerr, Martin" , Tim Ellison >>>>>>> > , "Simonis, Volker" >>>>>>> >>>>>>> > Date: 03/24/2016 09:19 >>>>>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>>>>> > >>>>>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>>>>> > java code has no guarantee that sessionK array elements are >>>>>>> > initialized with int[]. Or we should modify java code to declare >>>>>>> sessionK >>>>>>> > as int[][]. >>>>>>> > >>>>>>> > Thanks, >>>>>>> > Vladimir >>>>>>> > >>>>>>> > Note, intrinsics are correctly handle case when >>>>>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>>>>> > > Dear all: >>>>>>> > > >>>>>>> > > Can I please request reviews for the following change? >>>>>>> > > This change was created for JDK 9 to enable POWER8's AES >>>>>>> > > instructions for AES calculation. >>>>>>> > > >>>>>>> > > This request follows this discussion. >>>>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>>>>> > March/021926.html >>>>>>> > > >>>>>>> > > Description: >>>>>>> > > This change adds stub routines support for single-block AES >>>>>>> > > encryption and decryption operations on the POWER8 platform. >>>>>>> > > They are available only when the application is configured to >>>>>>> > > use SunJCE crypto provider on little endian. >>>>>>> > > >>>>>>> > > These stubs make use of efficient hardware AES instructions >>>>>>> > > and thus offer significant performance improvements over >>>>>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>>>>> > > are enabled by default on POWER8 platforms that support AES >>>>>>> > > instructions (vcipher). They can be explicitly enabled or >>>>>>> > > disabled on the command-line using UseAES and >>>>>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>>>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>>>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>>>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>>>>> > > >>>>>>> > > Summary of source code changes: >>>>>>> > > >>>>>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>>>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>>>>> > > - Adds support for vrld instruction to rotate vector register >>>>>>> values >>>>>>> > > with left doubleword. >>>>>>> > > >>>>>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>> > > - Defines stubs for single-block AES encryption and >>>>>>> decryption >>>>>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>>>>> > > - Current POWER AES decryption instructions are not >>>>>>> compatible >>>>>>> > > with SunJCE expanded decryption key format. Thus >>>>>>> decryption >>>>>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>>>>> > > descendant order. >>>>>>> > > - Encryption stubs use SunJCE expanded encryption key as >>>>>>> their >>>>>>> > > is no incompatibility issue between POWER8 AES encryption >>>>>>> > > instructions and SunJCE expanded encryption keys. >>>>>>> > > >>>>>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>>>>> > > - Detects AES capabilities of the underlying CPU by using >>>>>>> > > has_vcipher(). >>>>>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>>>>> > > CPU supports AES instructions and neither of them is >>>>>>> explicitly >>>>>>> > > disabled on the command-line. Generate warning message if >>>>>>> > > either of these flags are enabled on the command-line >>>>>>> > > whereas the underlying CPU does not support AES >>>>>>> instructions. >>>>>>> > > >>>>>>> > > *src/share/vm/opto/library_call.cpp >>>>>>> > > - Passes the first input parameter, reference to sessionK[0] >>>>>>> to the >>>>>>> > > AES stubs only on the POWER platform. >>>>>>> > > >>>>>>> > > *src/share/vm/opto/graphKit.cpp >>>>>>> > > - Supports T_NARROWOOP type for >>>>>>> GraphKit::load_array_element. >>>>>>> > > >>>>>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>>>>> > > Webrev: >>>>>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>>>>> > > >>>>>>> > > >>>>>>> > > Regards, >>>>>>> > > Hiroshi >>>>>>> > > ----------------------- >>>>>>> > > Hiroshi Horii, >>>>>>> > > IBM Research - Tokyo >>>>>>> > > >>>>>>> > >>>>>>> >>>>> >>> From anthony.scarpino at oracle.com Wed Mar 30 17:22:42 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 30 Mar 2016 10:22:42 -0700 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> <56FAEC66.9060606@oracle.com> Message-ID: <56FC0B62.3080502@oracle.com> The jdk part looks good. Tony On 03/30/2016 03:29 AM, Volker Simonis wrote: > Hi everybody, > > here finally comes the updated version of Hiroshi's change (sorry for > the delay): > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.hs/ > http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.jdk/ > > With regard to the previous version it contains three small updates: > - changed the type of AESCrypt::sessionK from Object[] to int[][] > - also updated the type of the AESCrypt::sessionK field to "[[I" in > LibraryCallKit::get_key_start_from_aescrypt_object() where it gets > loaded. > - protected the generation of the AES-stubs by "if (UseAES)" tp > prevent them from beeing generated on ppc64 big endian. > > We need a sponsor to push these two changes in sync to hs-comp. > > Thank you and best regards, > Volker > > > On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino > wrote: >> Volker, >> >> Changing this with your other changes in hs-comp repo is best.. Just let me >> know when you are ready for code review on this piece. >> >> thanks >> >> Tony >> >> >> >> >> On 03/29/2016 06:05 AM, Volker Simonis wrote: >>> >>> Hi Anthony, Vladimir, >>> >>> thanks for your evaluation. Should I open a new bug for the change in >>> AESCrypt or can we do it under the same bug id like the ppc-specific >>> AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? >>> >>> I also think that the AESCrypt::sessionK type change change, although >>> it is a class library change, should be done right in hs-comp together >>> with the new ppc64 AES intrinsics. Do you agree? >>> >>> Regards, >>> Volker >>> >>> >>> On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino >>> wrote: >>>> >>>> [Switching to security-dev, core-lib-dev was bcc'ed] >>>> >>>> I don't see any problem changing it to int[][]. Being an Object[] is odd >>>> in >>>> my opinion. >>>> >>>> Tony >>>> >>>> >>>> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>>>> >>>>> >>>>> This question is for core libs. >>>>> >>>>> For JIT to generate optimal code we want to change type of >>>>> AESCrypt::sessionK from Object[] to int[][]. >>>>> Otherwise JIT have to generate checkcast code to make sure that elements >>>>> of sessionK array are int[]. >>>>> I see that sessionK field is private so we are not changing public API. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>>>> >>>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> Thank you for your reviewing. >>>>>> >>>>>> Is it possible to modify the type of sessionK from Object[] to int[][]? >>>>>> >>>>>> We can guess, the type was designed for flexibility. However, only >>>>>> int[] is used >>>>>> to store elements of sessionK, so far. In addition, this field is >>>>>> private. >>>>>> Though adding checkcast is another solution, it produces overheads. >>>>>> >>>>>> I attached an additional patch (generated with hg diff -g) to jdk >>>>>> directory. >>>>>> I would like to ask thoughts about this change of java code. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Hiroshi >>>>>> ----------------------- >>>>>> Hiroshi Horii, >>>>>> IBM Research - Tokyo >>>>>> >>>>>> >>>>>> Vladimir Kozlov wrote on 03/24/2016 >>>>>> 09:09:11: >>>>>> >>>>>> > From: Vladimir Kozlov >>>>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>>>> > dev at openjdk.java.net" >>>>>> > Cc: "Doerr, Martin" , Tim Ellison >>>>>> > , "Simonis, Volker" >>>>>> >>>>>> > Date: 03/24/2016 09:19 >>>>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>>>> > >>>>>> > I think we need to add gen_checkcast for objAESCryptKey node since >>>>>> > java code has no guarantee that sessionK array elements are >>>>>> > initialized with int[]. Or we should modify java code to declare >>>>>> sessionK >>>>>> > as int[][]. >>>>>> > >>>>>> > Thanks, >>>>>> > Vladimir >>>>>> > >>>>>> > Note, intrinsics are correctly handle case when >>>>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>>>> > > Dear all: >>>>>> > > >>>>>> > > Can I please request reviews for the following change? >>>>>> > > This change was created for JDK 9 to enable POWER8's AES >>>>>> > > instructions for AES calculation. >>>>>> > > >>>>>> > > This request follows this discussion. >>>>>> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>>>> > March/021926.html >>>>>> > > >>>>>> > > Description: >>>>>> > > This change adds stub routines support for single-block AES >>>>>> > > encryption and decryption operations on the POWER8 platform. >>>>>> > > They are available only when the application is configured to >>>>>> > > use SunJCE crypto provider on little endian. >>>>>> > > >>>>>> > > These stubs make use of efficient hardware AES instructions >>>>>> > > and thus offer significant performance improvements over >>>>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>>>> > > are enabled by default on POWER8 platforms that support AES >>>>>> > > instructions (vcipher). They can be explicitly enabled or >>>>>> > > disabled on the command-line using UseAES and >>>>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls the >>>>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>>>> > > >>>>>> > > Summary of source code changes: >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>>>> > > - Adds support for vrld instruction to rotate vector register >>>>>> values >>>>>> > > with left doubleword. >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>> > > - Defines stubs for single-block AES encryption and >>>>>> decryption >>>>>> > > routines supporting all key sizes (128, 192 and 256-bit). >>>>>> > > - Current POWER AES decryption instructions are not >>>>>> compatible >>>>>> > > with SunJCE expanded decryption key format. Thus >>>>>> decryption >>>>>> > > stubs read the expanded encryption keys (sessionK[0]) with >>>>>> > > descendant order. >>>>>> > > - Encryption stubs use SunJCE expanded encryption key as >>>>>> their >>>>>> > > is no incompatibility issue between POWER8 AES encryption >>>>>> > > instructions and SunJCE expanded encryption keys. >>>>>> > > >>>>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>>>> > > - Detects AES capabilities of the underlying CPU by using >>>>>> > > has_vcipher(). >>>>>> > > - Enables UseAES and UseAESIntrinsics flags if the underlying >>>>>> > > CPU supports AES instructions and neither of them is >>>>>> explicitly >>>>>> > > disabled on the command-line. Generate warning message if >>>>>> > > either of these flags are enabled on the command-line >>>>>> > > whereas the underlying CPU does not support AES >>>>>> instructions. >>>>>> > > >>>>>> > > *src/share/vm/opto/library_call.cpp >>>>>> > > - Passes the first input parameter, reference to sessionK[0] >>>>>> to the >>>>>> > > AES stubs only on the POWER platform. >>>>>> > > >>>>>> > > *src/share/vm/opto/graphKit.cpp >>>>>> > > - Supports T_NARROWOOP type for >>>>>> GraphKit::load_array_element. >>>>>> > > >>>>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>>>> > > Webrev: >>>>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>>>> > > >>>>>> > > >>>>>> > > Regards, >>>>>> > > Hiroshi >>>>>> > > ----------------------- >>>>>> > > Hiroshi Horii, >>>>>> > > IBM Research - Tokyo >>>>>> > > >>>>>> > >>>>>> >>>> >> From joe.darcy at oracle.com Wed Mar 30 23:48:27 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 30 Mar 2016 16:48:27 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> Message-ID: <56FC65CB.2060904@oracle.com> Hi Mandy, Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: http://cr.openjdk.java.net/~darcy/8151763.2 I aligned the bug number in column 64 unless the test name took more characters. (This isn't as evident in the webrev since the tab expansion is different than in a text editor.) Thanks, -Joe On 3/29/2016 12:31 PM, Mandy Chung wrote: >> On Mar 29, 2016, at 12:15 PM, joe darcy wrote: >> >> Hi Mandy, >> >> On 3/28/2016 8:48 PM, Mandy Chung wrote: >>>> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: >>>> >>>> Hello, >>>> >>>> New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. >>>> >>>> http://cr.openjdk.java.net/~darcy/8151763.1 >>>> >>> # tools/jimage/JImageTest.java linux-i586,windows-i586 >>> >>> Is this test accidentally removed? Other than this, looks okay. >> The "#" lines are comments so I was removing a commented out line. (I assumed, but did not verify, the line for this test was a leftover artifact of the recent Jigsaw merge.) > I missed ?#? since this test should be excluded (some error might have been creeped in before the integration) > > This test needs to be added back in the problem list. I?ll create a changeset. > >>> Nit: it?d be good to have most of bug ids aligned in the same column start. >>> Here are a few ones: >>> >>> 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac >>> 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug >>> 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug >>> 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all >>> 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >>> 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all >>> 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all >>> >>> >> I was trying to avoid introducing lots of spacing changes in an attempt to make the patch easier to review, but I can look over these cases again. > That?d be good. Thanks > Mandy From Sergey.Bylokhov at oracle.com Thu Mar 31 00:02:09 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 Mar 2016 03:02:09 +0300 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56FC65CB.2060904@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> <56FC65CB.2060904@oracle.com> Message-ID: <56FC6901.7050106@oracle.com> The fix looks fine to me. can you please clarify what "enabling better reporting" from the bug description means? Where this information will be reported? On 31.03.16 2:48, Joseph D. Darcy wrote: > Hi Mandy, > > Hopefully the third time will be the charm for this changeset after your > correction to the commented-out test: > > http://cr.openjdk.java.net/~darcy/8151763.2 > > I aligned the bug number in column 64 unless the test name took more > characters. (This isn't as evident in the webrev since the tab expansion > is different than in a text editor.) > > Thanks, > > -Joe > > On 3/29/2016 12:31 PM, Mandy Chung wrote: >>> On Mar 29, 2016, at 12:15 PM, joe darcy wrote: >>> >>> Hi Mandy, >>> >>> On 3/28/2016 8:48 PM, Mandy Chung wrote: >>>>> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> New iteration of the webrev updated after the Jigsaw integration >>>>> and incorporating the earlier feedback. >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8151763.1 >>>>> >>>> # tools/jimage/JImageTest.java >>>> linux-i586,windows-i586 >>>> >>>> Is this test accidentally removed? Other than this, looks okay. >>> The "#" lines are comments so I was removing a commented out line. (I >>> assumed, but did not verify, the line for this test was a leftover >>> artifact of the recent Jigsaw merge.) >> I missed ?#? since this test should be excluded (some error might have >> been creeped in before the integration) >> >> This test needs to be added back in the problem list. I?ll create a >> changeset. >> >>>> Nit: it?d be good to have most of bug ids aligned in the same column >>>> start. >>>> Here are a few ones: >>>> >>>> 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all >>>> no PortUnreachableException on Mac >>>> 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 >>>> solaris-all Solaris DSA keypair generation bug >>>> 213 sun/security/tools/keytool/standard.sh 7041639 >>>> solaris-all Solaris DSA keypair generation bug >>>> 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all >>>> 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >>>> 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java >>>> 8072131,8132452 generic-all >>>> 370 sun/tools/jinfo/JInfoSanityTest.java >>>> 8059035 generic-all >>>> >>>> >>> I was trying to avoid introducing lots of spacing changes in an >>> attempt to make the patch easier to review, but I can look over these >>> cases again. >> That?d be good. Thanks >> Mandy > -- Best regards, Sergey. From joe.darcy at oracle.com Thu Mar 31 00:06:40 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 30 Mar 2016 17:06:40 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56FC6901.7050106@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> <56FC65CB.2060904@oracle.com> <56FC6901.7050106@oracle.com> Message-ID: <56FC6A10.4000406@oracle.com> Hi Sergey, The thinking is the reformatted file, with the bug on the same line as the test, will allow in the future better reporting and analysis of problem list entries with information from the bug database. Thanks for the review; HTH, -Joe On 3/30/2016 5:02 PM, Sergey Bylokhov wrote: > The fix looks fine to me. can you please clarify what "enabling better > reporting" from the bug description means? Where this information will > be reported? > > On 31.03.16 2:48, Joseph D. Darcy wrote: >> Hi Mandy, >> >> Hopefully the third time will be the charm for this changeset after your >> correction to the commented-out test: >> >> http://cr.openjdk.java.net/~darcy/8151763.2 >> >> I aligned the bug number in column 64 unless the test name took more >> characters. (This isn't as evident in the webrev since the tab expansion >> is different than in a text editor.) >> >> Thanks, >> >> -Joe >> >> On 3/29/2016 12:31 PM, Mandy Chung wrote: >>>> On Mar 29, 2016, at 12:15 PM, joe darcy wrote: >>>> >>>> Hi Mandy, >>>> >>>> On 3/28/2016 8:48 PM, Mandy Chung wrote: >>>>>> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> New iteration of the webrev updated after the Jigsaw integration >>>>>> and incorporating the earlier feedback. >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/8151763.1 >>>>>> >>>>> # tools/jimage/JImageTest.java >>>>> linux-i586,windows-i586 >>>>> >>>>> Is this test accidentally removed? Other than this, looks okay. >>>> The "#" lines are comments so I was removing a commented out line. (I >>>> assumed, but did not verify, the line for this test was a leftover >>>> artifact of the recent Jigsaw merge.) >>> I missed ?#? since this test should be excluded (some error might have >>> been creeped in before the integration) >>> >>> This test needs to be added back in the problem list. I?ll create a >>> changeset. >>> >>>>> Nit: it?d be good to have most of bug ids aligned in the same column >>>>> start. >>>>> Here are a few ones: >>>>> >>>>> 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all >>>>> no PortUnreachableException on Mac >>>>> 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 >>>>> solaris-all Solaris DSA keypair generation bug >>>>> 213 sun/security/tools/keytool/standard.sh 7041639 >>>>> solaris-all Solaris DSA keypair generation bug >>>>> 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 >>>>> generic-all >>>>> 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >>>>> 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java >>>>> 8072131,8132452 generic-all >>>>> 370 sun/tools/jinfo/JInfoSanityTest.java >>>>> 8059035 generic-all >>>>> >>>>> >>>> I was trying to avoid introducing lots of spacing changes in an >>>> attempt to make the patch easier to review, but I can look over these >>>> cases again. >>> That?d be good. Thanks >>> Mandy >> > > From mandy.chung at oracle.com Thu Mar 31 00:34:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Mar 2016 17:34:09 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56FC65CB.2060904@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> <56FC65CB.2060904@oracle.com> Message-ID: > On Mar 30, 2016, at 4:48 PM, Joseph D. Darcy wrote: > > Hi Mandy, > > Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: > > http://cr.openjdk.java.net/~darcy/8151763.2 > > I aligned the bug number in column 64 unless the test name took more characters. (This isn't as evident in the webrev since the tab expansion is different than in a text editor.) > Thanks for doing it. Looks fine with me. Just to mention it: these few lines are somewhat strange (shorter test name has more whitespace) that you may want to double check. Ok to push what you have. ! java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 ! java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 ! java/nio/file/WatchService/LotsOfEvents.java 7158947 solaris-all Solaris 11 Mandy From joe.darcy at oracle.com Thu Mar 31 01:15:29 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 30 Mar 2016 18:15:29 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> <56FC65CB.2060904@oracle.com> Message-ID: <56FC7A31.7090802@oracle.com> On 3/30/2016 5:34 PM, Mandy Chung wrote: >> On Mar 30, 2016, at 4:48 PM, Joseph D. Darcy wrote: >> >> Hi Mandy, >> >> Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: >> >> http://cr.openjdk.java.net/~darcy/8151763.2 >> >> I aligned the bug number in column 64 unless the test name took more characters. (This isn't as evident in the webrev since the tab expansion is different than in a text editor.) >> > Thanks for doing it. Looks fine with me. > > Just to mention it: these few lines are somewhat strange (shorter test name has more whitespace) that you may want to double check. Ok to push what you have. > > ! java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 > ! java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 > ! java/nio/file/WatchService/LotsOfEvents.java 7158947 solaris-all Solaris 11 > Pushed after a de-tabbification and verifying the set of tests to run was the same before and after the update. Thanks, -Joe From mandy.chung at oracle.com Thu Mar 31 01:24:44 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Mar 2016 18:24:44 -0700 Subject: JDK 9 RFR of JDK-8151763; Use more informative format for problem list In-Reply-To: <56FC7A31.7090802@oracle.com> References: <56E38CCF.8080004@oracle.com> <56E9F15F.2050002@oracle.com> <56E9F1A1.3040309@oracle.com> <56F9C665.7070706@oracle.com> <56FAD46A.4080803@oracle.com> <45FA671B-7243-46ED-8772-10818F3276F6@oracle.com> <56FC65CB.2060904@oracle.com> <56FC7A31.7090802@oracle.com> Message-ID: > On Mar 30, 2016, at 6:15 PM, joe darcy wrote: > > Pushed after a de-tabbification and verifying the set of tests to run was the same before and after the update. It looks good. Mandy From volker.simonis at gmail.com Thu Mar 31 09:11:55 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Mar 2016 11:11:55 +0200 Subject: RFR(M): 8152172: PPC64: Support AES intrinsics In-Reply-To: <56FC024D.2070302@oracle.com> References: <201603221547.u2MFlk3Q026590@d19av06.sagamino.japan.ibm.com> <56F33027.2070704@oracle.com> <201603250117.u2P1HMxM023918@d19av08.sagamino.japan.ibm.com> <56F5C2F4.3040205@oracle.com> <56F96CC2.9010506@oracle.com> <56FAEC66.9060606@oracle.com> <56FC0125.7020700@oracle.com> <56FC024D.2070302@oracle.com> Message-ID: That's fine. Thanks, Volker On Wed, Mar 30, 2016 at 6:43 PM, Vladimir Kozlov wrote: > BTW, I am changing UseAES check in stubs generation with UseAESIntrinsics > check as we do for other intrinsics. > > Thanks, > Vladimir > > > On 3/30/16 9:39 AM, Vladimir Kozlov wrote: >> >> Looks good. I will run hotspot compiler pre-integration testing and let >> you know results. >> >> Thanks, >> Vladimir >> >> On 3/30/16 3:29 AM, Volker Simonis wrote: >>> >>> Hi everybody, >>> >>> here finally comes the updated version of Hiroshi's change (sorry for >>> the delay): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.hs/ >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172.jdk/ >>> >>> With regard to the previous version it contains three small updates: >>> - changed the type of AESCrypt::sessionK from Object[] to int[][] >>> - also updated the type of the AESCrypt::sessionK field to "[[I" in >>> LibraryCallKit::get_key_start_from_aescrypt_object() where it gets >>> loaded. >>> - protected the generation of the AES-stubs by "if (UseAES)" tp >>> prevent them from beeing generated on ppc64 big endian. >>> >>> We need a sponsor to push these two changes in sync to hs-comp. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino >>> wrote: >>>> >>>> Volker, >>>> >>>> Changing this with your other changes in hs-comp repo is best.. Just let >>>> me >>>> know when you are ready for code review on this piece. >>>> >>>> thanks >>>> >>>> Tony >>>> >>>> >>>> >>>> >>>> On 03/29/2016 06:05 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi Anthony, Vladimir, >>>>> >>>>> thanks for your evaluation. Should I open a new bug for the change in >>>>> AESCrypt or can we do it under the same bug id like the ppc-specific >>>>> AES intrinisc (i.e. "8152172: PPC64: Support AES intrinsics") ? >>>>> >>>>> I also think that the AESCrypt::sessionK type change change, although >>>>> it is a class library change, should be done right in hs-comp together >>>>> with the new ppc64 AES intrinsics. Do you agree? >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino >>>>> wrote: >>>>>> >>>>>> >>>>>> [Switching to security-dev, core-lib-dev was bcc'ed] >>>>>> >>>>>> I don't see any problem changing it to int[][]. Being an Object[] is >>>>>> odd >>>>>> in >>>>>> my opinion. >>>>>> >>>>>> Tony >>>>>> >>>>>> >>>>>> On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> This question is for core libs. >>>>>>> >>>>>>> For JIT to generate optimal code we want to change type of >>>>>>> AESCrypt::sessionK from Object[] to int[][]. >>>>>>> Otherwise JIT have to generate checkcast code to make sure that >>>>>>> elements >>>>>>> of sessionK array are int[]. >>>>>>> I see that sessionK field is private so we are not changing public >>>>>>> API. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 3/24/16 6:17 PM, Hiroshi H Horii wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thank you for your reviewing. >>>>>>>> >>>>>>>> Is it possible to modify the type of sessionK from Object[] to >>>>>>>> int[][]? >>>>>>>> >>>>>>>> We can guess, the type was designed for flexibility. However, only >>>>>>>> int[] is used >>>>>>>> to store elements of sessionK, so far. In addition, this field is >>>>>>>> private. >>>>>>>> Though adding checkcast is another solution, it produces overheads. >>>>>>>> >>>>>>>> I attached an additional patch (generated with hg diff -g) to jdk >>>>>>>> directory. >>>>>>>> I would like to ask thoughts about this change of java code. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hiroshi >>>>>>>> ----------------------- >>>>>>>> Hiroshi Horii, >>>>>>>> IBM Research - Tokyo >>>>>>>> >>>>>>>> >>>>>>>> Vladimir Kozlov wrote on 03/24/2016 >>>>>>>> 09:09:11: >>>>>>>> >>>>>>>> > From: Vladimir Kozlov >>>>>>>> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler- >>>>>>>> > dev at openjdk.java.net" >>>>>>>> > Cc: "Doerr, Martin" , Tim Ellison >>>>>>>> > , "Simonis, Volker" >>>>>>>> >>>>>>>> > Date: 03/24/2016 09:19 >>>>>>>> > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics >>>>>>>> > >>>>>>>> > I think we need to add gen_checkcast for objAESCryptKey node >>>>>>>> since >>>>>>>> > java code has no guarantee that sessionK array elements are >>>>>>>> > initialized with int[]. Or we should modify java code to >>>>>>>> declare >>>>>>>> sessionK >>>>>>>> > as int[][]. >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Vladimir >>>>>>>> > >>>>>>>> > Note, intrinsics are correctly handle case when >>>>>>>> > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: >>>>>>>> > > Dear all: >>>>>>>> > > >>>>>>>> > > Can I please request reviews for the following change? >>>>>>>> > > This change was created for JDK 9 to enable POWER8's AES >>>>>>>> > > instructions for AES calculation. >>>>>>>> > > >>>>>>>> > > This request follows this discussion. >>>>>>>> > > >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- >>>>>>>> > March/021926.html >>>>>>>> > > >>>>>>>> > > Description: >>>>>>>> > > This change adds stub routines support for single-block AES >>>>>>>> > > encryption and decryption operations on the POWER8 platform. >>>>>>>> > > They are available only when the application is configured to >>>>>>>> > > use SunJCE crypto provider on little endian. >>>>>>>> > > >>>>>>>> > > These stubs make use of efficient hardware AES instructions >>>>>>>> > > and thus offer significant performance improvements over >>>>>>>> > > JITed code on POWER8 as on x86 and SPARC. AES stub routines >>>>>>>> > > are enabled by default on POWER8 platforms that support AES >>>>>>>> > > instructions (vcipher). They can be explicitly enabled or >>>>>>>> > > disabled on the command-line using UseAES and >>>>>>>> > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher >>>>>>>> > > and vnchiper of POWER8 need the same round keys of AES. >>>>>>>> > > Therefore, inline_aescrypt_Block in library_call.cpp calls >>>>>>>> the >>>>>>>> > > stub with AESCrypt.sessionK[0] as round keys. >>>>>>>> > > >>>>>>>> > > Summary of source code changes: >>>>>>>> > > >>>>>>>> > > *src/cpu/ppc/vm/assembler_ppc.hpp >>>>>>>> > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp >>>>>>>> > > - Adds support for vrld instruction to rotate vector >>>>>>>> register >>>>>>>> values >>>>>>>> > > with left doubleword. >>>>>>>> > > >>>>>>>> > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp >>>>>>>> > > - Defines stubs for single-block AES encryption and >>>>>>>> decryption >>>>>>>> > > routines supporting all key sizes (128, 192 and >>>>>>>> 256-bit). >>>>>>>> > > - Current POWER AES decryption instructions are not >>>>>>>> compatible >>>>>>>> > > with SunJCE expanded decryption key format. Thus >>>>>>>> decryption >>>>>>>> > > stubs read the expanded encryption keys (sessionK[0]) >>>>>>>> with >>>>>>>> > > descendant order. >>>>>>>> > > - Encryption stubs use SunJCE expanded encryption key as >>>>>>>> their >>>>>>>> > > is no incompatibility issue between POWER8 AES >>>>>>>> encryption >>>>>>>> > > instructions and SunJCE expanded encryption keys. >>>>>>>> > > >>>>>>>> > > *src/cpu/ppc/vm/vm_version_ppc.cpp >>>>>>>> > > - Detects AES capabilities of the underlying CPU by using >>>>>>>> > > has_vcipher(). >>>>>>>> > > - Enables UseAES and UseAESIntrinsics flags if the >>>>>>>> underlying >>>>>>>> > > CPU supports AES instructions and neither of them is >>>>>>>> explicitly >>>>>>>> > > disabled on the command-line. Generate warning message >>>>>>>> if >>>>>>>> > > either of these flags are enabled on the command-line >>>>>>>> > > whereas the underlying CPU does not support AES >>>>>>>> instructions. >>>>>>>> > > >>>>>>>> > > *src/share/vm/opto/library_call.cpp >>>>>>>> > > - Passes the first input parameter, reference to >>>>>>>> sessionK[0] >>>>>>>> to the >>>>>>>> > > AES stubs only on the POWER platform. >>>>>>>> > > >>>>>>>> > > *src/share/vm/opto/graphKit.cpp >>>>>>>> > > - Supports T_NARROWOOP type for >>>>>>>> GraphKit::load_array_element. >>>>>>>> > > >>>>>>>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>>>>>> > > Webrev: >>>>>>>> http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > Regards, >>>>>>>> > > Hiroshi >>>>>>>> > > ----------------------- >>>>>>>> > > Hiroshi Horii, >>>>>>>> > > IBM Research - Tokyo >>>>>>>> > > >>>>>>>> > >>>>>>>> >>>>>> >>>> > From ivan.gerasimov at oracle.com Thu Mar 31 15:57:09 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 31 Mar 2016 18:57:09 +0300 Subject: RFR 6483657: MSCAPI provider does not create unique alias names Message-ID: <56FD48D5.3050404@oracle.com> Hello! Could you please help review the fix for this long standing issue? Windows-MY allows non-unique aliases, but our implementation of KeyStore does not take it into account. To help to deal with such keystores with multiple same-named aliases it is proposed to internally remap the keystore entries to aliases that artificially made unique. I was meaning to create a regression test, but found no easy way to test this behavior, as the keytool program doesn't allow creating same-named aliases. All existing regression tests pass well however. BUGURL: https://bugs.openjdk.java.net/browse/JDK-6483657 WEBREV: http://cr.openjdk.java.net/~igerasim/6483657/00/webrev/ With kind regards, Ivan From sean.mullan at oracle.com Thu Mar 31 19:24:05 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 31 Mar 2016 15:24:05 -0400 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> Message-ID: <56FD7955.7060202@oracle.com> Just a few comments: - SunJCE 707 // TODO: aliases with OIDs leftover TODO. - SecureRandom 604 * @implSpec The default implementation returns {@code null}. Technically, I don't think that is correct, since it is really dependent on what the underlying Spi is doing. The same comment applies to the other @implSpec sections in this class. 683 * @throws UnsupportedOperationException if the implementation 684 * has not overridden this method. Would it be more accurate to say "if the underlying provider implementation (SecureRandomSpi) has not overridden this method". Same comment applies to other UOEs in this class. - SecureRandomSpi 86 protected SecureRandomSpi(SecureRandomInstantiateParameters params) { 87 // ignored 88 } If you changed this to: protected SecureRandomSpi(SecureRandomInstantiateParameters params) { this(); } couldn't you avoid the code which catchs a NoSuchMethodExc and retries, etc? It would be nice to not have these extra rules about calling this constructor or that constructor, and instead you could just always call the constructor above and it would do the right thing. Just thinking out loud here, not sure if it is the right thing to do. - java.security what happens if you have parsing/syntax errors in the drbg property? Also, does the order of the aspects matter? - DrbgParameters 249 * @return If used in {@code getInstance}, returns the minimum strength s/If/if/ 253 * strengh requested. s/strengh/strength/ 290 * @return If used in {@code getInstance}, returns the minimum capability 301 * @return If used in {@code getInstance}, returns the requested a/If/if/ 428 public static Instantiate instantiate(int strength, 429 Capability capability, 430 byte[] personalizationString) { Should this throw NPE if capability is null? Should it throw IllegalArgExc if strength < -1? - EntropySource Is this interface used anywhere? Should getEntropy throw IllegalArgumentExceptions if int params are less than a certain value or if maxLength < minLength? Does it return a new byte array each time it is invoked? --Sean On 03/29/2016 04:47 AM, Wang Weijun wrote: > Ping again. No comment? > > --Max > >> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote: >> >> Hi All >> >> Please take a review at the design and implementation of DRBG at: >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.07 >> http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html >> >> An example: >> >> SecureRandom drbg; >> byte[] buffer = new byte[32]; >> >> drbg = SecureRandom.getInstance("DRBG", >> DrbgParameters.instantiate(256, PR_ONLY, "hello".getBytes())); >> >> drbg.nextBytes(buffer, >> DrbgParameters.nextBytes(-1, false, "more".getBytes())); >> >> SecureRandomInstantiateParameters params = drbg.getParameters(); >> if (params instanceof DrbgParameters.Instantiate) { >> DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; >> if (ins.getCapability() != NONE) { >> drbg.reseed(DrbgParameters.reseed(false, "extra".getBytes())); >> } >> } >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Mar 31 23:44:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Apr 2016 07:44:40 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <56FD7955.7060202@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> Message-ID: > On Apr 1, 2016, at 3:24 AM, Sean Mullan wrote: > > Just a few comments: > > - SunJCE > > 707 // TODO: aliases with OIDs > > leftover TODO. Every other HMAC algorithm has an OID that can be used as an Alg.Alias.***, but the 2 new algorithms do not have. I expect one day they will have. > > - SecureRandom > > 604 * @implSpec The default implementation returns {@code null}. > > Technically, I don't think that is correct, since it is really dependent on what the underlying Spi is doing. The same comment applies to the other @implSpec sections in this class. I see. So @implSpec should only appear in SecureRandomSpi. > > > 683 * @throws UnsupportedOperationException if the implementation > 684 * has not overridden this method. > > Would it be more accurate to say "if the underlying provider implementation (SecureRandomSpi) has not overridden this method". Same comment applies to other UOEs in this class. Yes. > - SecureRandomSpi > > 86 protected SecureRandomSpi(SecureRandomInstantiateParameters params) { > 87 // ignored > 88 } > > If you changed this to: > > protected SecureRandomSpi(SecureRandomInstantiateParameters params) { > this(); > } > > couldn't you avoid the code which catchs a NoSuchMethodExc and retries, etc? It would be nice to not have these extra rules about calling this constructor or that constructor, and instead you could just always call the constructor above and it would do the right thing. Just thinking out loud here, not sure if it is the right thing to do. I'll think about it. I assume you are talking about my change in Provider.java. The problem is that old and new SecureRandom implementations do not have the same constructors and I need them both working. > > - java.security > > what happens if you have parsing/syntax errors in the drbg property? Well, there is no parsing error now since I treat everything non-parseable as algorithm and it will be caught later. Said that, maybe I should at least check if one aspect is provided 2 times and if there is an empty aspect, and if an integer is non-positive. > Also, does the order of the aspects matter? No. The only non-literals are algorithm name and strength. The strength should always be an integer and the algorithm name should not be the same as other aspects. > > - DrbgParameters > > 249 * @return If used in {@code getInstance}, returns the minimum strength > > s/If/if/ > > 253 * strengh requested. > > s/strengh/strength/ > > 290 * @return If used in {@code getInstance}, returns the minimum capability > 301 * @return If used in {@code getInstance}, returns the requested > > a/If/if/ > > 428 public static Instantiate instantiate(int strength, > 429 Capability capability, > 430 byte[] personalizationString) { > > Should this throw NPE if capability is null? Yes. > Should it throw IllegalArgExc if strength < -1? I can, but necessary? > > - EntropySource > > Is this interface used anywhere? In AbstractDrbg.SeedHolder, as the default entropy sources for pr_true and pr_false are different. And in tests. > > Should getEntropy throw IllegalArgumentExceptions if int params are less than a certain value or if maxLength < minLength? Does it return a new byte array each time it is invoked? Yes and yes, but I haven't checked/documented it since it's not a public API yet. Thanks Max > > --Sean > > On 03/29/2016 04:47 AM, Wang Weijun wrote: >> Ping again. No comment? >> >> --Max >> >>> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please take a review at the design and implementation of DRBG at: >>> >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.07 >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html >>> >>> An example: >>> >>> SecureRandom drbg; >>> byte[] buffer = new byte[32]; >>> >>> drbg = SecureRandom.getInstance("DRBG", >>> DrbgParameters.instantiate(256, PR_ONLY, "hello".getBytes())); >>> >>> drbg.nextBytes(buffer, >>> DrbgParameters.nextBytes(-1, false, "more".getBytes())); >>> >>> SecureRandomInstantiateParameters params = drbg.getParameters(); >>> if (params instanceof DrbgParameters.Instantiate) { >>> DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; >>> if (ins.getCapability() != NONE) { >>> drbg.reseed(DrbgParameters.reseed(false, "extra".getBytes())); >>> } >>> } >>> >>> Thanks >>> Max >>> >> From weijun.wang at oracle.com Thu Mar 31 23:47:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Apr 2016 07:47:27 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> Message-ID: <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> Oops. I suddenly realize something wrong about the drbg security property. Hash_DRBG can use SHA-512/224 and it includes a slash. --Max