From weijun.wang at oracle.com Sun Dec 2 11:23:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 2 Dec 2018 19:23:52 +0800 Subject: RFR 8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8214513/webrev.00/ It's now able to read the wrong PBES2-params encoding created by JDK before JDK 11. Thanks Max From weijun.wang at oracle.com Sun Dec 2 11:48:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 2 Dec 2018 19:48:21 +0800 Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow In-Reply-To: References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com> <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com> <56387755-fb82-3285-7682-d48a77efd14e@oracle.com> <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com> Message-ID: <60E3168A-D623-4A7D-944B-305C767B7101@oracle.com> Thanks for your support. Here is the updated webrev: https://cr.openjdk.java.net/~weijun/8210476/webrev.02/ I've made ctxt transient and added a readObject method, and a new test for this. The cleaner action is now implemented as a named inner class. Thanks Max > On Dec 1, 2018, at 2:03 AM, Xue-Lei Fan wrote: > > Hi Weijun, > > I think you made a significant improvement of the performance, with less timing and resources. I don't think my concerns are strong enough to prevent this fix from moving forward. > > I'm fine with your update. You can move forward as it is, or using finalize() instead. > > For my concerns, if you go with Cleaner, we can open a new RFE for the tracking if we have a good idea in the future. > > Thanks, > Xuelei > > On 11/30/2018 3:47 AM, Weijun Wang wrote: >> Hi Xuelei, and Ivan who replied in another mail, >>> On Nov 29, 2018, at 4:31 AM, Xue-Lei Fan wrote: >>> >>> Do you know, is there any other way except Cleaner and finalize() to clean up the allocated resources? >> I don't know any other automatic mechanisms. There is AutoClosable but SecureRandom has not implemented it and we cannot expect people using try-with-resources on it. >>> >>> I'm not very sure of the use of static Cleaner: >>> 1. a daemon thread will run underlying. >>> 2. the number of registered actions could be huge in some circumstances. >> Anyway, I think any fix that reuses the context is to change a time performance issue into a resource performance issue because we cannot precisely control the resource cleanup. >> I don't have enough data on how often people use Windows-PRNG, how many objects they create, how many nextBytes they call on a single object, and how they use it in multiple threads. So it's quite clueless to determine which solution is the best. >> Both this bug and the previous one (JDK-6449335) are not reported by external customers. Therefore I prefer retargeting the bug to the next release and problem list the test at the moment. In the last 1700 mach5 jobs with this test, there were 4 timeouts. >> Thanks >> Max >> p.s. We might reimplement using CNG but CNG also has its own problem (no easy way to implement setSeed). >>> >>> I'm not very sure if it could be a scalability bottleneck or not. >>> >>> Xuelei >>> >>> >>> On 11/26/2018 5:33 PM, Weijun Wang wrote: >>>> Ping again >>>>> On Nov 20, 2018, at 5:33 PM, Weijun Wang wrote: >>>>> >>>>> Webrev updated at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8210476/webrev.01/ >>>>> >>>>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang wrote: >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> https://cr.openjdk.java.net/~weijun/8210476/webrev.00/ >>>>>> >>>>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom. >>>>>> >>>>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false. >>>>>> >>>>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter. >>>>>> >>>>>> Before After >>>>>> ------ ----- >>>>>> Count 897 74 >>>>>> Min 0.38 0.008 >>>>>> Ave 0.97 0.011 >>>>>> Max 5.81 0.021 >>>>>> >>>>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called. >>>>>> >>>>>> + Cleaner.create().register(this, >>>>>> + () -> releaseContext(ctxt)); >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>> From weijun.wang at oracle.com Sun Dec 2 11:58:38 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 2 Dec 2018 19:58:38 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181130163756.GD13826@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181129164456.GC13826@twosigma.com> <20181130163756.GD13826@twosigma.com> Message-ID: <8C2233AC-1FA1-46B5-95A3-A005DAECF4C3@oracle.com> > On Dec 1, 2018, at 12:37 AM, Nico Williams wrote: > > I don't see where that allows something like this property to be set via > some configuration file in /etc or via the registry on Windows. conf/security/java.security is our supported place for these per-installation settings. It's not perfect because reinstalll JDK will wipe it. Maybe you can create your own launcher wrapper to read settings from /etc or registry first and then translate them into system properties before starting the JVM. --Max From Kasper.Janssens at wdc.com Mon Dec 3 08:09:50 2018 From: Kasper.Janssens at wdc.com (Kasper Janssens) Date: Mon, 3 Dec 2018 08:09:50 +0000 Subject: AES ctr benchmark performance Message-ID: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> Hello, I've been measuring the performance of the java 11 built in AES-NI instructions and, with NI switched on through JAVA_TOOL_OPTIONS = ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. I run the benchmarks that are present in the open jdk itself through ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p algorithm=AES/CTR/NoPadding?. When I compare the results and calculate the throughput in GB/s, for 16k encoding blocks, I get about 40% of the throughput when compared to the openssl performance test through ?openssl speed -evp aes-128-ctr?. I don't seem to find a decent comparison/benchmark that describes which percentage of the maximum performance to expect with jdk 11, but 40 % seems rather low. Does anybody know of a comparison (or might have an idea where I go wrong, because, as these are off the shelf perf tools I would think not a lot can be tweaked there). For reference, the openssl test reports this: The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-ctr 583576.76k 1907072.21k 4144141.40k 5612174.68k 6252751.53k 6258371.24k So, for 16k blocks, 6258371k bytes per second The openjdk benchmark reports this Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units AESBench.encrypt AES/CTR/NoPadding 16384 128 thrpt 100 168066.873 ? 488.873 ops/s Out of which I conclude that, for 16k blocks, the perf here is 168066 * 16k or about 2689056k bytes per second or about 40 % of the openssl number, taking some liberty with rounding the numbers. Is that expected or am I drawing the wrong conclusions? Or am I missing something? When I print the options, the jvm reports that the AES intrinsics are being used : java -XX:+PrintFlagsFinal | grep -i AES intx MaxBCEAEstimateLevel = 5 {product} {default} intx MaxBCEAEstimateSize = 150 {product} {default} bool UseAES = true {product} {default} System specs : Ubuntu 18.04 openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) Kasper -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Dec 3 15:14:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 3 Dec 2018 23:14:26 +0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. Not supported: 1. No EC KeyPairGenerator yet. 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. 4. NONEwithECDSA not supported. Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. Thanks Max From xuelei.fan at oracle.com Mon Dec 3 15:52:42 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 3 Dec 2018 07:52:42 -0800 Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow In-Reply-To: <60E3168A-D623-4A7D-944B-305C767B7101@oracle.com> References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com> <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com> <56387755-fb82-3285-7682-d48a77efd14e@oracle.com> <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com> <60E3168A-D623-4A7D-944B-305C767B7101@oracle.com> Message-ID: <6b517487-02a3-326a-af3b-07c78e840c1d@oracle.com> Looks fine to me. Thanks, Xuelei On 12/2/2018 3:48 AM, Weijun Wang wrote: > Thanks for your support. Here is the updated webrev: > > https://cr.openjdk.java.net/~weijun/8210476/webrev.02/ > > I've made ctxt transient and added a readObject method, and a new test for this. > > The cleaner action is now implemented as a named inner class. > > Thanks > Max > >> On Dec 1, 2018, at 2:03 AM, Xue-Lei Fan wrote: >> >> Hi Weijun, >> >> I think you made a significant improvement of the performance, with less timing and resources. I don't think my concerns are strong enough to prevent this fix from moving forward. >> >> I'm fine with your update. You can move forward as it is, or using finalize() instead. >> >> For my concerns, if you go with Cleaner, we can open a new RFE for the tracking if we have a good idea in the future. >> >> Thanks, >> Xuelei >> >> On 11/30/2018 3:47 AM, Weijun Wang wrote: >>> Hi Xuelei, and Ivan who replied in another mail, >>>> On Nov 29, 2018, at 4:31 AM, Xue-Lei Fan wrote: >>>> >>>> Do you know, is there any other way except Cleaner and finalize() to clean up the allocated resources? >>> I don't know any other automatic mechanisms. There is AutoClosable but SecureRandom has not implemented it and we cannot expect people using try-with-resources on it. >>>> >>>> I'm not very sure of the use of static Cleaner: >>>> 1. a daemon thread will run underlying. >>>> 2. the number of registered actions could be huge in some circumstances. >>> Anyway, I think any fix that reuses the context is to change a time performance issue into a resource performance issue because we cannot precisely control the resource cleanup. >>> I don't have enough data on how often people use Windows-PRNG, how many objects they create, how many nextBytes they call on a single object, and how they use it in multiple threads. So it's quite clueless to determine which solution is the best. >>> Both this bug and the previous one (JDK-6449335) are not reported by external customers. Therefore I prefer retargeting the bug to the next release and problem list the test at the moment. In the last 1700 mach5 jobs with this test, there were 4 timeouts. >>> Thanks >>> Max >>> p.s. We might reimplement using CNG but CNG also has its own problem (no easy way to implement setSeed). >>>> >>>> I'm not very sure if it could be a scalability bottleneck or not. >>>> >>>> Xuelei >>>> >>>> >>>> On 11/26/2018 5:33 PM, Weijun Wang wrote: >>>>> Ping again >>>>>> On Nov 20, 2018, at 5:33 PM, Weijun Wang wrote: >>>>>> >>>>>> Webrev updated at >>>>>> >>>>>> https://cr.openjdk.java.net/~weijun/8210476/webrev.01/ >>>>>> >>>>>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang wrote: >>>>>>> >>>>>>> Please take a review at >>>>>>> >>>>>>> https://cr.openjdk.java.net/~weijun/8210476/webrev.00/ >>>>>>> >>>>>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom. >>>>>>> >>>>>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false. >>>>>>> >>>>>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter. >>>>>>> >>>>>>> Before After >>>>>>> ------ ----- >>>>>>> Count 897 74 >>>>>>> Min 0.38 0.008 >>>>>>> Ave 0.97 0.011 >>>>>>> Max 5.81 0.021 >>>>>>> >>>>>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called. >>>>>>> >>>>>>> + Cleaner.create().register(this, >>>>>>> + () -> releaseContext(ctxt)); >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>> > From sean.coffey at oracle.com Mon Dec 3 17:10:26 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 3 Dec 2018 17:10:26 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> Message-ID: <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> The CSR related to this change has been approved. I made further edits to update the DNSName comment code to reference RFC 5280 rather than the obsoleted RFC 2459. I also updated the test case with a few extra tests per suggestion from Chris and others. Moved the dataprovider into a good and bad data set also. A follow on bug has been logged to update all references of RFC 2459 to RFC 5280 (JDK-8214532) Regards, Sean. On 27/11/18 14:27, Se?n Coffey wrote: > Thanks for the feedback Max. I'll ping Joe Darcy and check if a CSR is > required for this type of change. I'll revert back to this list once I > have an answer. > > keytool works well with the new change. I've modified the test as per > your suggestion : > > --- a/test/jdk/sun/security/tools/keytool/KeyToolTest.java > +++ b/test/jdk/sun/security/tools/keytool/KeyToolTest.java > @@ -1436,6 +1436,7 @@ > testOK("", pre+"san3 -ext san=dns:me.org"); > testOK("", pre+"san4 -ext san=ip:192.168.0.1"); > testOK("", pre+"san5 -ext san=oid:1.2.3.4"); > + testOK("", pre+"san6 -ext san=dns:1abc.com"); //begin with digit > testOK("", pre+"san235 -ext > san=uri:http://me.org,dns:me.org,oid:1.2.3.4"); > > Regards, > Sean. > > On 27/11/18 01:29, Weijun Wang wrote: >> >>> On Nov 26, 2018, at 11:15 AM, Weijun Wang >>> wrote: >>> >>> >>> >>>> On Nov 24, 2018, at 12:45 AM, Se?n Coffey >>>> wrote: >>>> >>>> Thanks for your review Max. I've made the suggested edits. >>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/ >>> The change looks fine. Thanks. >>> >>>> I've also submitted a CSR for this change just to cover the >>>> behavioural aspect of the edit. Will push if/once that's approved >>>> by CSR team. >>> The CSR focuses on keytool but this is actually a library change. >>> There is no change with "add/remove/modify command line option" at all. >>> >>> I would suggest talking about the DNSName class instead of keytool. >>> I understand it's internal but we can describe this change as a >>> non-minimal change on behavior so it's still worth a CSR. Or, you >>> can consult Joe what the best way is. Maybe he can spare you from >>> filing a CSR at all. >>> >>> BTW, you did try out keytool after this code change and "-ext >>> dns=1abc.com" is working now, right? >> You can add an extra line after line 1437 of >> test/jdk/sun/security/tools/keytool/KeyToolTest.java. >> >>> Thanks >>> Max >>> >>>> Regards, >>>> Sean. >>>> >>>> On 22/11/18 14:49, Weijun Wang wrote: >>>>> * DNSName.java: >>>>> >>>>> 91 if ((endIndex - startIndex) < 1) >>>>> >>>>> No need for inner parentheses. >>>>> >>>>> And, is there really a need to define alphaDigitsAndHyphen? How >>>>> about just (== '-' || inside alphaDigits)? >>>>> >>>>> * DNSNameTest.java: >>>>> >>>>> Space cannot appear anywhere, please add a test case like "a c.com". >>>>> >>>>> BTW, I assume you want to reuse this test for other sub-tasks of >>>>> JDK-8054380? I see the @summary is more general. >>>>> >>>>> No other comments. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey >>>>>> wrote: >>>>>> >>>>>> p.s I've updated the testcase to test the IOException message for >>>>>> presence of "DNSName". Webrev updated in place. >>>>>> >>>>>> Regards, >>>>>> Sean. >>>>>> >>>>>> On 21/11/18 15:42, Se?n Coffey wrote: >>>>>>> Thanks for the comments Bernd. Comments inline.. >>>>>>> >>>>>>> On 16/11/18 21:27, Bernd Eckenfels wrote: >>>>>>>> Hello Sean, >>>>>>>> >>>>>>>> I was only looking at the inspected DNSName class, it still has >>>>>>>> some variations (but start now with DNSNames which is good >>>>>>>> already): >>>>>>>> >>>>>>>> 76 throw new IOException("DNSName must not be null or empty"); >>>>>>>> 78 throw new IOException("DNSNames or NameConstraints with >>>>>>>> blank components are not permitted"); >>>>>>>> 80 throw new IOException("DNSNames or NameConstraints may not >>>>>>>> begin or end with a ."); >>>>>>>> 92 throw new IOException("DNSName SubjectAltNames with empty >>>>>>>> components are not permitted"); >>>>>>>> 96 throw new IOException("DNSName components must begin with a >>>>>>>> letter or digit"); >>>>>>>> 101 throw new IOException("DNSName components must consist of >>>>>>>> letters, digits, and hyphens"); >>>>>>>> >>>>>>>> I did not check if those exceptions are catched and rethrown >>>>>>>> with something like ?while validating the SubjectAltName >>>>>>>> Extension of certificate ...?, in my experience >>>>>>>> it helps if you do not have to find and review the actual >>>>>>>> certificates (in this case it might not be a problem if SAN is >>>>>>>> only in the end entity). You can probably remove ?or >>>>>>>> NameConstraints? and ?SubjectAltNames? from lines 78-92 (this >>>>>>>> is good if DNsNa >>>>>>> Ok - I've cleaned up the exception messages on line 78, 80, 92. >>>>>>> webrev updated in place : >>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>>>>> >>>>>>> >>>>>>>> me applies to SAN or NameConstrained context and the validation >>>>>>>> logic does not know ? so it?s not only more unified but also >>>>>>>> less missleading) >>>>>>>> >>>>>>>> BTW: probably not inthe scope of this fix but a subtype for >>>>>>>> validation errors which have getters for context/location and >>>>>>>> maybe error code and getValue() would allow callers to print >>>>>>>> nicer validation reports without relying on the message or >>>>>>>> Stacktraces. >>>>>>> That's a nice idea and one that should be followed up in >>>>>>> separate enhancement. We could lean on the new >>>>>>> `jdk.includeInExceptions` Security property which other >>>>>>> component areas have started to use lately. >>>>>>> >>>>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>>> Gruss >>>>>>>> Bernd >>>>>>>> -- >>>>>>>> http://bernd.eckenfels.net >>>>>>>> Von: Se?n Coffey >>>>>>>> Gesendet: Freitag, November 16, 2018 5:15 PM >>>>>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net >>>>>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC >>>>>>>> 1123 >>>>>>>> Thanks for the comments Bernd. comments inline.. >>>>>>>> >>>>>>>> On 16/11/18 12:40, Bernd Eckenfels wrote: >>>>>>>>> You could also add (a..b, false) and (.a, false), (a., false) >>>>>>>>> to the testcases. >>>>>>>> good point. test updated. >>>>>>>>> I noticed that there are different types of Exception messages >>>>>>>>> (DNS name, DNSName, DNS Name or name constrained, DNS name and >>>>>>>>> SAN), would be good if all of them have the same keyword? >>>>>>>> I cleaned up some other references to DNSName in the >>>>>>>> sun.security.x509 package. I'm not sure what classes you were >>>>>>>> referencing the above examples from. >>>>>>>> >>>>>>>> new webrev : >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>>> Gruss >>>>>>>>> Bernd >>>>>>>>> -- >>>>>>>>> http://bernd.eckenfels.net >>>>>>>>> Von: security-dev im >>>>>>>>> Auftrag von Se?n Coffey >>>>>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM >>>>>>>>> An: OpenJDK Dev list >>>>>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>>>>>>> Looking to make an adjustment to DNSName constructor to help >>>>>>>>> comply with >>>>>>>>> RFC 1123 >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Sean. >>>>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon Dec 3 17:11:27 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 3 Dec 2018 17:11:27 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> Message-ID: whoops: latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v4/webrev/ Regards, Sean. On 03/12/18 17:10, Se?n Coffey wrote: > > The CSR related to this change has been approved. > > I made further edits to update the DNSName comment code to reference > RFC 5280 rather than the obsoleted RFC 2459. I also updated the test > case with a few extra tests per suggestion from Chris and others. > Moved the dataprovider into a good and bad data set also. > > A follow on bug has been logged to update all references of RFC 2459 > to RFC 5280 (JDK-8214532) > > Regards, > Sean. > On 27/11/18 14:27, Se?n Coffey wrote: >> Thanks for the feedback Max. I'll ping Joe Darcy and check if a CSR >> is required for this type of change. I'll revert back to this list >> once I have an answer. >> >> keytool works well with the new change. I've modified the test as per >> your suggestion : >> >> --- a/test/jdk/sun/security/tools/keytool/KeyToolTest.java >> +++ b/test/jdk/sun/security/tools/keytool/KeyToolTest.java >> @@ -1436,6 +1436,7 @@ >> testOK("", pre+"san3 -ext san=dns:me.org"); >> testOK("", pre+"san4 -ext san=ip:192.168.0.1"); >> testOK("", pre+"san5 -ext san=oid:1.2.3.4"); >> + testOK("", pre+"san6 -ext san=dns:1abc.com"); //begin with >> digit >> testOK("", pre+"san235 -ext >> san=uri:http://me.org,dns:me.org,oid:1.2.3.4"); >> >> Regards, >> Sean. >> >> On 27/11/18 01:29, Weijun Wang wrote: >>> >>>> On Nov 26, 2018, at 11:15 AM, Weijun Wang >>>> wrote: >>>> >>>> >>>> >>>>> On Nov 24, 2018, at 12:45 AM, Se?n Coffey >>>>> wrote: >>>>> >>>>> Thanks for your review Max. I've made the suggested edits. >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/ >>>> The change looks fine. Thanks. >>>> >>>>> I've also submitted a CSR for this change just to cover the >>>>> behavioural aspect of the edit. Will push if/once that's approved >>>>> by CSR team. >>>> The CSR focuses on keytool but this is actually a library change. >>>> There is no change with "add/remove/modify command line option" at >>>> all. >>>> >>>> I would suggest talking about the DNSName class instead of keytool. >>>> I understand it's internal but we can describe this change as a >>>> non-minimal change on behavior so it's still worth a CSR. Or, you >>>> can consult Joe what the best way is. Maybe he can spare you from >>>> filing a CSR at all. >>>> >>>> BTW, you did try out keytool after this code change and "-ext >>>> dns=1abc.com" is working now, right? >>> You can add an extra line after line 1437 of >>> test/jdk/sun/security/tools/keytool/KeyToolTest.java. >>> >>>> Thanks >>>> Max >>>> >>>>> Regards, >>>>> Sean. >>>>> >>>>> On 22/11/18 14:49, Weijun Wang wrote: >>>>>> * DNSName.java: >>>>>> >>>>>> 91 if ((endIndex - startIndex) < 1) >>>>>> >>>>>> No need for inner parentheses. >>>>>> >>>>>> And, is there really a need to define alphaDigitsAndHyphen? How >>>>>> about just (== '-' || inside alphaDigits)? >>>>>> >>>>>> * DNSNameTest.java: >>>>>> >>>>>> Space cannot appear anywhere, please add a test case like "a c.com". >>>>>> >>>>>> BTW, I assume you want to reuse this test for other sub-tasks of >>>>>> JDK-8054380? I see the @summary is more general. >>>>>> >>>>>> No other comments. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey >>>>>>> wrote: >>>>>>> >>>>>>> p.s I've updated the testcase to test the IOException message >>>>>>> for presence of "DNSName". Webrev updated in place. >>>>>>> >>>>>>> Regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 21/11/18 15:42, Se?n Coffey wrote: >>>>>>>> Thanks for the comments Bernd. Comments inline.. >>>>>>>> >>>>>>>> On 16/11/18 21:27, Bernd Eckenfels wrote: >>>>>>>>> Hello Sean, >>>>>>>>> >>>>>>>>> I was only looking at the inspected DNSName class, it still >>>>>>>>> has some variations (but start now with DNSNames which is good >>>>>>>>> already): >>>>>>>>> >>>>>>>>> 76 throw new IOException("DNSName must not be null or empty"); >>>>>>>>> 78 throw new IOException("DNSNames or NameConstraints with >>>>>>>>> blank components are not permitted"); >>>>>>>>> 80 throw new IOException("DNSNames or NameConstraints may >>>>>>>>> not begin or end with a ."); >>>>>>>>> 92 throw new IOException("DNSName SubjectAltNames with empty >>>>>>>>> components are not permitted"); >>>>>>>>> 96 throw new IOException("DNSName components must begin with a >>>>>>>>> letter or digit"); >>>>>>>>> 101 throw new IOException("DNSName components must consist of >>>>>>>>> letters, digits, and hyphens"); >>>>>>>>> >>>>>>>>> I did not check if those exceptions are catched and rethrown >>>>>>>>> with something like ?while validating the SubjectAltName >>>>>>>>> Extension of certificate ...?, in my experience >>>>>>>>> it helps if you do not have to find and review the actual >>>>>>>>> certificates (in this case it might not be a problem if SAN is >>>>>>>>> only in the end entity). You can probably remove ?or >>>>>>>>> NameConstraints? and ?SubjectAltNames? from lines 78-92 (this >>>>>>>>> is good if DNsNa >>>>>>>> Ok - I've cleaned up the exception messages on line 78, 80, 92. >>>>>>>> webrev updated in place : >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>>>>>> >>>>>>>> >>>>>>>>> me applies to SAN or NameConstrained context and the >>>>>>>>> validation logic does not know ? so it?s not only more unified >>>>>>>>> but also less missleading) >>>>>>>>> >>>>>>>>> BTW: probably not inthe scope of this fix but a subtype for >>>>>>>>> validation errors which have getters for context/location and >>>>>>>>> maybe error code and getValue() would allow callers to print >>>>>>>>> nicer validation reports without relying on the message or >>>>>>>>> Stacktraces. >>>>>>>> That's a nice idea and one that should be followed up in >>>>>>>> separate enhancement. We could lean on the new >>>>>>>> `jdk.includeInExceptions` Security property which other >>>>>>>> component areas have started to use lately. >>>>>>>> >>>>>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>>> Gruss >>>>>>>>> Bernd >>>>>>>>> -- >>>>>>>>> http://bernd.eckenfels.net >>>>>>>>> Von: Se?n Coffey >>>>>>>>> Gesendet: Freitag, November 16, 2018 5:15 PM >>>>>>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net >>>>>>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per >>>>>>>>> RFC 1123 >>>>>>>>> Thanks for the comments Bernd. comments inline.. >>>>>>>>> >>>>>>>>> On 16/11/18 12:40, Bernd Eckenfels wrote: >>>>>>>>>> You could also add (a..b, false) and (.a, false), (a., false) >>>>>>>>>> to the testcases. >>>>>>>>> good point. test updated. >>>>>>>>>> I noticed that there are different types of Exception >>>>>>>>>> messages (DNS name, DNSName, DNS Name or name constrained, >>>>>>>>>> DNS name and SAN), would be good if all of them have the same >>>>>>>>>> keyword? >>>>>>>>> I cleaned up some other references to DNSName in the >>>>>>>>> sun.security.x509 package. I'm not sure what classes you were >>>>>>>>> referencing the above examples from. >>>>>>>>> >>>>>>>>> new webrev : >>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Sean. >>>>>>>>>> Gruss >>>>>>>>>> Bernd >>>>>>>>>> -- >>>>>>>>>> http://bernd.eckenfels.net >>>>>>>>>> Von: security-dev im >>>>>>>>>> Auftrag von Se?n Coffey >>>>>>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM >>>>>>>>>> An: OpenJDK Dev list >>>>>>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>>>>>>>> Looking to make an adjustment to DNSName constructor to help >>>>>>>>>> comply with >>>>>>>>>> RFC 1123 >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Sean. >>>>>>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Mon Dec 3 17:14:12 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 3 Dec 2018 17:14:12 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <8C2233AC-1FA1-46B5-95A3-A005DAECF4C3@oracle.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181129164456.GC13826@twosigma.com> <20181130163756.GD13826@twosigma.com> <8C2233AC-1FA1-46B5-95A3-A005DAECF4C3@oracle.com> Message-ID: <20181203171412.GA12201@twosigma.com> On Sun, Dec 02, 2018 at 07:58:38PM +0800, Weijun Wang wrote: > > On Dec 1, 2018, at 12:37 AM, Nico Williams wrote: > > > > I don't see where that allows something like this property to be set via > > some configuration file in /etc or via the registry on Windows. > > conf/security/java.security is our supported place for these per-installation > settings. It's not perfect because reinstalll JDK will wipe it. Maybe you can > create your own launcher wrapper to read settings from /etc or registry first > and then translate them into system properties before starting the JVM. Well... I'm not going to have time to do anything here, but if I did I'd look into moving parts of Preferences into security. That would work well enough for the Registry (since that has no dependencies on security), but it wouldn't work for XML without some serious refactoring to allow an XML that supports only local (file:) URIs in security -- that seems way too ambitious for a project I'm not funded to work on. These are suggestions for Oracle or any other contributor who needs this. Nico -- From anthony.scarpino at oracle.com Mon Dec 3 18:45:20 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 3 Dec 2018 10:45:20 -0800 Subject: AES ctr benchmark performance In-Reply-To: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> Message-ID: <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> Hi, That is how I read it, but when I've done the test it's closer to 55%. But openssl speed and jmh are not comparable. Openssl is only running through it's algorithm, while jmh is running through the VM and java byte code. jmh has to do more work outside of pure crypto ops than openssl. Tony On 12/3/18 12:09 AM, Kasper Janssens wrote: > Hello, > > I've been measuring the performance of the java 11 built in AES-NI > instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > > I run the benchmarks that are present in the open jdk itself through > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > algorithm=AES/CTR/NoPadding?. > > When I compare the results and calculate the throughput in GB/s, for 16k > encoding blocks, I get about 40% of the throughput when compared to the > openssl performance test through??openssl speed -evp aes-128-ctr?. > > I don't seem to find a decent comparison/benchmark that describes which > percentage of the maximum performance to expect with jdk 11, but 40 % > seems rather low. Does anybody know of a comparison (or might have an > idea where I go wrong, ?because, as these are off the shelf perf tools I > would think not a lot can be tweaked there). > > For reference, the openssl test reports this: > > The 'numbers' are in 1000s of bytes per second processed. > > type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? 8192 > bytes? 16384 bytes > > aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k? 5612174.68k > 6252751.53k? 6258371.24k > > So, for 16k blocks, 6258371k bytes per second > > The openjdk benchmark reports this > > Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) > (provider)?? Mode? Cnt?????? Score???? Error? Units > > AESBench.encrypt? AES/CTR/NoPadding?????? 16384 > 128????????????? thrpt? 100? 168066.873 ? 488.873? ops/s > > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > 16k or about 2689056k bytes per second or about 40 % of the openssl > number, taking some liberty with rounding the numbers. > > Is that expected or am I drawing the wrong conclusions? Or am I missing > something? > > When I print the options, the jvm reports that the AES intrinsics are > being used : > > java -XX:+PrintFlagsFinal | grep -i AES > > ???? intx MaxBCEAEstimateLevel???????????????????? = > 5??????????????????????????????????????? {product} {default} > > ???? intx MaxBCEAEstimateSize????????????????????? = > 150????????????????????????????????????? {product} {default} > > ???? bool UseAES??????????? ???????????????????????= > true???????????????????????????????????? {product} {default} > > System specs : Ubuntu 18.04 > > openjdk version "10.0.2" 2018-07-17 > > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > mode) > > Kasper > From ecki at zusammenkunft.net Mon Dec 3 20:27:40 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 3 Dec 2018 21:27:40 +0100 Subject: AES ctr benchmark performance In-Reply-To: <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> Message-ID: <5c0591bc.1c69fb81.53a9e.fe80@mx.google.com> Quick Question, why did you Need to switch it on and out of curiosity how do the times look like when you switch NI off? Greetings Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:13 An: Kasper Janssens; security-dev at openjdk.java.net Betreff: Re: AES ctr benchmark performance Hi, That is how I read it, but when I've done the test it's closer to 55%. But openssl speed and jmh are not comparable. Openssl is only running through it's algorithm, while jmh is running through the VM and java byte code. jmh has to do more work outside of pure crypto ops than openssl. Tony On 12/3/18 12:09 AM, Kasper Janssens wrote: > Hello, > > I've been measuring the performance of the java 11 built in AES-NI > instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > > I run the benchmarks that are present in the open jdk itself through > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > algorithm=AES/CTR/NoPadding?. > > When I compare the results and calculate the throughput in GB/s, for 16k > encoding blocks, I get about 40% of the throughput when compared to the > openssl performance test through??openssl speed -evp aes-128-ctr?. > > I don't seem to find a decent comparison/benchmark that describes which > percentage of the maximum performance to expect with jdk 11, but 40 % > seems rather low. Does anybody know of a comparison (or might have an > idea where I go wrong, ?because, as these are off the shelf perf tools I > would think not a lot can be tweaked there). > > For reference, the openssl test reports this: > > The 'numbers' are in 1000s of bytes per second processed. > > type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? 8192 > bytes? 16384 bytes > > aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k? 5612174.68k > 6252751.53k? 6258371.24k > > So, for 16k blocks, 6258371k bytes per second > > The openjdk benchmark reports this > > Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) > (provider)?? Mode? Cnt?????? Score???? Error? Units > > AESBench.encrypt? AES/CTR/NoPadding?????? 16384 > 128????????????? thrpt? 100? 168066.873 ? 488.873? ops/s > > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > 16k or about 2689056k bytes per second or about 40 % of the openssl > number, taking some liberty with rounding the numbers. > > Is that expected or am I drawing the wrong conclusions? Or am I missing > something? > > When I print the options, the jvm reports that the AES intrinsics are > being used : > > java -XX:+PrintFlagsFinal | grep -i AES > > ???? intx MaxBCEAEstimateLevel???????????????????? = > 5??????????????????????????????????????? {product} {default} > > ???? intx MaxBCEAEstimateSize????????????????????? = > 150????????????????????????????????????? {product} {default} > > ???? bool UseAES??????????? ???????????????????????= > true???????????????????????????????????? {product} {default} > > System specs : Ubuntu 18.04 > > openjdk version "10.0.2" 2018-07-17 > > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > mode) > > Kasper > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Dec 3 20:35:42 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 3 Dec 2018 12:35:42 -0800 Subject: AES ctr benchmark performance In-Reply-To: <5c0591bc.1c69fb81.53a9e.fe80@mx.google.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> <5c0591bc.1c69fb81.53a9e.fe80@mx.google.com> Message-ID: Very slow.. Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize. As far as why there is a switch, mostly debugging or possible bugs in hotspot that cause the intrinsic to break. Tony On 12/3/18 12:27 PM, Bernd Eckenfels wrote: > Quick Question, why did you Need to switch it on and out of curiosity > how do the times look like when you switch NI off? > > Greetings > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Anthony Scarpino > *Gesendet: *Montag, 3. Dezember 2018 21:13 > *An: *Kasper Janssens ; > security-dev at openjdk.java.net > *Betreff: *Re: AES ctr benchmark performance > > Hi, > > That is how I read it, but when I've done the test it's closer to 55%. > > But openssl speed and jmh are not comparable.? Openssl is only running > > through it's algorithm, while jmh is running through the VM and java > > byte code. jmh has to do more work outside of pure crypto ops than openssl. > > Tony > > On 12/3/18 12:09 AM, Kasper Janssens wrote: > > > Hello, > > > > > > I've been measuring the performance of the java 11 built in AES-NI > > > instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = > > > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > > > > > > I run the benchmarks that are present in the open jdk itself through > > > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > > > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > > > algorithm=AES/CTR/NoPadding?. > > > > > > When I compare the results and calculate the throughput in GB/s, for 16k > > > encoding blocks, I get about 40% of the throughput when compared to the > > > openssl performance test through??openssl speed -evp aes-128-ctr?. > > > > > > I don't seem to find a decent comparison/benchmark that describes which > > > percentage of the maximum performance to expect with jdk 11, but 40 % > > > seems rather low. Does anybody know of a comparison (or might have an > > > idea where I go wrong, ?because, as these are off the shelf perf tools I > > > would think not a lot can be tweaked there). > > > > > > For reference, the openssl test reports this: > > > > > > The 'numbers' are in 1000s of bytes per second processed. > > > > > > type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? 8192 > > > bytes? 16384 bytes > > > > > > aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k? 5612174.68k > > > 6252751.53k? 6258371.24k > > > > > > So, for 16k blocks, 6258371k bytes per second > > > > > > The openjdk benchmark reports this > > > > > > Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) > > > (provider)?? Mode? Cnt?????? Score???? Error? Units > > > > > > AESBench.encrypt? AES/CTR/NoPadding?????? 16384 > > > 128????????????? thrpt? 100? 168066.873 ? 488.873? ops/s > > > > > > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > > > 16k or about 2689056k bytes per second or about 40 % of the openssl > > > number, taking some liberty with rounding the numbers. > > > > > > Is that expected or am I drawing the wrong conclusions? Or am I missing > > > something? > > > > > > When I print the options, the jvm reports that the AES intrinsics are > > > being used : > > > > > > java -XX:+PrintFlagsFinal | grep -i AES > > > > > >? ???? intx MaxBCEAEstimateLevel???????????????????? = > > > 5??????????????????????????????????????? {product} {default} > > > > > >? ???? intx MaxBCEAEstimateSize????????????????????? = > > > 150????????????????????????????????????? {product} {default} > > > > > >? ???? bool UseAES??????????? ???????????????????????= > > > true???????????????????????????????????? {product} {default} > > > > > > System specs : Ubuntu 18.04 > > > > > > openjdk version "10.0.2" 2018-07-17 > > > > > > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > > > > > > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > > > mode) > > > > > > Kasper > > > > From ecki at zusammenkunft.net Mon Dec 3 20:46:26 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 3 Dec 2018 21:46:26 +0100 Subject: AES ctr benchmark performance In-Reply-To: References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> <5c0591bc.1c69fb81.53a9e.fe80@mx.google.com> Message-ID: <5c059622.1c69fb81.f0106.ffcf@mx.google.com> Well yes, was just wondering why the options had to be enabled explicitely and why -XX:+UnlockDiagnosticVMOptions was used. But I guess that was just unrelated info. BTW: does the C2 warmup Problem strike here again maybe? Gruss Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev at openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow.. Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize. As far as why there is a switch, mostly debugging or possible bugs in hotspot that cause the intrinsic to break. Tony On 12/3/18 12:27 PM, Bernd Eckenfels wrote: > Quick Question, why did you Need to switch it on and out of curiosity > how do the times look like when you switch NI off? > > Greetings > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Anthony Scarpino > *Gesendet: *Montag, 3. Dezember 2018 21:13 > *An: *Kasper Janssens ; > security-dev at openjdk.java.net > *Betreff: *Re: AES ctr benchmark performance > > Hi, > > That is how I read it, but when I've done the test it's closer to 55%. > > But openssl speed and jmh are not comparable.? Openssl is only running > > through it's algorithm, while jmh is running through the VM and java > > byte code. jmh has to do more work outside of pure crypto ops than openssl. > > Tony > > On 12/3/18 12:09 AM, Kasper Janssens wrote: > > > Hello, > > > > > > I've been measuring the performance of the java 11 built in AES-NI > > > instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = > > > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > > > > > > I run the benchmarks that are present in the open jdk itself through > > > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > > > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > > > algorithm=AES/CTR/NoPadding?. > > > > > > When I compare the results and calculate the throughput in GB/s, for 16k > > > encoding blocks, I get about 40% of the throughput when compared to the > > > openssl performance test through??openssl speed -evp aes-128-ctr?. > > > > > > I don't seem to find a decent comparison/benchmark that describes which > > > percentage of the maximum performance to expect with jdk 11, but 40 % > > > seems rather low. Does anybody know of a comparison (or might have an > > > idea where I go wrong, ?because, as these are off the shelf perf tools I > > > would think not a lot can be tweaked there). > > > > > > For reference, the openssl test reports this: > > > > > > The 'numbers' are in 1000s of bytes per second processed. > > > > > > type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? 8192 > > > bytes? 16384 bytes > > > > > > aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k? 5612174.68k > > > 6252751.53k? 6258371.24k > > > > > > So, for 16k blocks, 6258371k bytes per second > > > > > > The openjdk benchmark reports this > > > > > > Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) > > > (provider)?? Mode? Cnt?????? Score???? Error? Units > > > > > > AESBench.encrypt? AES/CTR/NoPadding?????? 16384 > > > 128????????????? thrpt? 100? 168066.873 ? 488.873? ops/s > > > > > > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > > > 16k or about 2689056k bytes per second or about 40 % of the openssl > > > number, taking some liberty with rounding the numbers. > > > > > > Is that expected or am I drawing the wrong conclusions? Or am I missing > > > something? > > > > > > When I print the options, the jvm reports that the AES intrinsics are > > > being used : > > > > > > java -XX:+PrintFlagsFinal | grep -i AES > > > > > >? ???? intx MaxBCEAEstimateLevel???????????????????? = > > > 5??????????????????????????????????????? {product} {default} > > > > > >? ???? intx MaxBCEAEstimateSize????????????????????? = > > > 150????????????????????????????????????? {product} {default} > > > > > >? ???? bool UseAES??????????? ???????????????????????= > > > true???????????????????????????????????? {product} {default} > > > > > > System specs : Ubuntu 18.04 > > > > > > openjdk version "10.0.2" 2018-07-17 > > > > > > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > > > > > > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > > > mode) > > > > > > Kasper > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Dec 3 20:50:00 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 3 Dec 2018 21:50:00 +0100 Subject: AES ctr benchmark performance In-Reply-To: <5c059622.1c69fb81.f0106.ffcf@mx.google.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> <5c0591bc.1c69fb81.53a9e.fe80@mx.google.com> <5c059622.1c69fb81.f0106.ffcf@mx.google.com> Message-ID: <5c0596f9.1c69fb81.f0106.0152@mx.google.com> Hello, and to partially answer myself: the UnlockDiagnostics is needed for Java 9+ Gruss Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev at openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow..? Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize. As far as why there is a switch, mostly debugging or possible bugs in hotspot that cause the intrinsic to break. Tony On 12/3/18 12:27 PM, Bernd Eckenfels wrote: > Quick Question, why did you Need to switch it on and out of curiosity > how do the times look like when you switch NI off? > > Greetings > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Anthony Scarpino > *Gesendet: *Montag, 3. Dezember 2018 21:13 > *An: *Kasper Janssens ; > security-dev at openjdk.java.net > *Betreff: *Re: AES ctr benchmark performance > > Hi, > > That is how I read it, but when I've done the test it's closer to 55%. > > But openssl speed and jmh are not comparable.? Openssl is only running > > through it's algorithm, while jmh is running through the VM and java > > byte code. jmh has to do more work outside of pure crypto ops than openssl. > > Tony > > On 12/3/18 12:09 AM, Kasper Janssens wrote: > >? > Hello, > >? > > >? > I've been measuring the performance of the java 11 built in AES-NI > >? > instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = > >? > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > >? > > >? > I run the benchmarks that are present in the open jdk itself through > >? > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > >? > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > >? > algorithm=AES/CTR/NoPadding?. > >? > > >? > When I compare the results and calculate the throughput in GB/s, for 16k > >? > encoding blocks, I get about 40% of the throughput when compared to the > >? > openssl performance test through??openssl speed -evp aes-128-ctr?. > >? > > >? > I don't seem to find a decent comparison/benchmark that describes which > >? > percentage of the maximum performance to expect with jdk 11, but 40 % > >? > seems rather low. Does anybody know of a comparison (or might have an > >? > idea where I go wrong, ?because, as these are off the shelf perf tools I > >? > would think not a lot can be tweaked there). > >? > > >? > For reference, the openssl test reports this: > >? > > >? > The 'numbers' are in 1000s of bytes per second processed. > >? > > >? > type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? 8192 > >? > bytes? 16384 bytes > >? > > >? > aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k? 5612174.68k > >? > 6252751.53k? 6258371.24k > >? > > >? > So, for 16k blocks, 6258371k bytes per second > >? > > >? > The openjdk benchmark reports this > >? > > >? > Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) > >? > (provider)?? Mode? Cnt?????? Score???? Error? Units > >? > > >? > AESBench.encrypt? AES/CTR/NoPadding?????? 16384 > >? > 128????????????? thrpt? 100? 168066.873 ? 488.873? ops/s > >? > > >? > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > >? > 16k or about 2689056k bytes per second or about 40 % of the openssl > >? > number, taking some liberty with rounding the numbers. > >? > > >? > Is that expected or am I drawing the wrong conclusions? Or am I missing > >? > something? > >? > > > ?> When I print the options, the jvm reports that the AES intrinsics are > >? > being used : > >? > > >? > java -XX:+PrintFlagsFinal | grep -i AES > >? > > >? >? ???? intx MaxBCEAEstimateLevel???????????????????? = > >? > 5??????????????????????????????????????? {product} {default} > >? > > >? >? ???? intx MaxBCEAEstimateSize????????????????????? = > >? > 150????????????????????????????????????? {product} {default} > >? > > >? >? ???? bool UseAES??????????? ???????????????????????= > >? > true???????????????????????????????????? {product} {default} > >? > > >? > System specs : Ubuntu 18.04 > >? > > >? > openjdk version "10.0.2" 2018-07-17 > >? > > >? > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > >? > > >? > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > >? > mode) > >? > > >? > Kasper > >? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Mon Dec 3 22:30:58 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 3 Dec 2018 17:30:58 -0500 Subject: AES ctr benchmark performance In-Reply-To: <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> Message-ID: <49900491-7263-6719-57da-4445b23605c7@oracle.com> I'm seeing JDK 11 performance around 40% of OpenSSL performance, too. This is on a Core i7-4980HQ (Haswell, turbo at 4 GHz). In addition to the "Java stuff" (e.g. garbage collection, array bounds checking) that Tony suggested, there is also the issue that the JDK native implementation does not interleave instructions, but the OpenSSL implementation does. The OpenSSL source file[1] has some great information about the effect of interleaving and the performance on various platforms. The JDK implementation of AES-CTR encrypts 6 blocks at a time, but it does all the other operations (increment counter, xor, etc) in sequence with the aesenc operations. The OpenSSL implementation performs all of these other operations in parallel with the aesenc operations. This difference in the native implementation likely accounts for some of the difference in performance, but I don't know how much. The "other" operations only require a relatively small number of cycles, but doing them in sequence may hurt performance a lot due to pipeline stalls. [1] https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl On 12/3/2018 1:45 PM, Anthony Scarpino wrote: > Hi, > > That is how I read it, but when I've done the test it's closer to 55%. > But openssl speed and jmh are not comparable.? Openssl is only running > through it's algorithm, while jmh is running through the VM and java > byte code. jmh has to do more work outside of pure crypto ops than > openssl. > > Tony > > > On 12/3/18 12:09 AM, Kasper Janssens wrote: >> Hello, >> >> I've been measuring the performance of the java 11 built in AES-NI >> instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = >> ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. >> >> I run the benchmarks that are present in the open jdk itself through? >> ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar >> org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p >> algorithm=AES/CTR/NoPadding?. >> >> When I compare the results and calculate the throughput in GB/s, for >> 16k encoding blocks, I get about 40% of the throughput when compared >> to the openssl performance test through??openssl speed -evp >> aes-128-ctr?. >> >> I don't seem to find a decent comparison/benchmark that describes >> which percentage of the maximum performance to expect with jdk 11, >> but 40 % seems rather low. Does anybody know of a comparison (or >> might have an idea where I go wrong, ?because, as these are off the >> shelf perf tools I would think not a lot can be tweaked there). >> >> For reference, the openssl test reports this: >> >> The 'numbers' are in 1000s of bytes per second processed. >> >> type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? >> 8192 bytes? 16384 bytes >> >> aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k 5612174.68k? >> 6252751.53k? 6258371.24k >> >> So, for 16k blocks, 6258371k bytes per second >> >> The openjdk benchmark reports this >> >> Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) >> (provider)?? Mode? Cnt?????? Score???? Error? Units >> >> AESBench.encrypt? AES/CTR/NoPadding?????? 16384 128????????????? >> thrpt? 100? 168066.873 ? 488.873? ops/s >> >> Out of which I conclude that, for 16k blocks, the perf here is 168066 >> * 16k or about 2689056k bytes per second or about 40 % of the openssl >> number, taking some liberty with rounding the numbers. >> >> Is that expected or am I drawing the wrong conclusions? Or am I >> missing something? >> >> When I print the options, the jvm reports that the AES intrinsics are >> being used : >> >> java -XX:+PrintFlagsFinal | grep -i AES >> >> ????? intx MaxBCEAEstimateLevel???????????????????? = >> 5??????????????????????????????????????? {product} {default} >> >> ????? intx MaxBCEAEstimateSize????????????????????? = >> 150????????????????????????????????????? {product} {default} >> >> ????? bool UseAES??????????? ???????????????????????= >> true???????????????????????????????????? {product} {default} >> >> System specs : Ubuntu 18.04 >> >> openjdk version "10.0.2" 2018-07-17 >> >> OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) >> >> OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, >> mixed mode) >> >> Kasper >> > From sha.jiang at oracle.com Tue Dec 4 02:41:21 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 4 Dec 2018 10:41:21 +0800 Subject: RFR[12] JDK-8214459: NSS source should be removed In-Reply-To: <7f3ed67c-9284-5436-591a-c0a009c5a0ef@oracle.com> References: <93a9d031-a1ff-4092-b496-6231a09bbf6c@oracle.com> <7f3ed67c-9284-5436-591a-c0a009c5a0ef@oracle.com> Message-ID: Hi Valerie, Do you have more concern about this issue? I re-generate this patch with hg diff option -g. The new patch should delete all the files, including the directory. diff --git a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz b/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz deleted file mode 100644 index 63fa5feb5108f92b1cfcd2fbfc990294ed4d8fed..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 GIT binary patch literal 0 Hc$@ Hi Valerie, > > On 2018/11/30 10:28, Valerie Peng wrote: >> I assume not just the two files, their containing src directory will >> be removed, right? > > Yes. This directory also will be removed. > > Best regards, > John Jiang > >> >> Valerie >> >> On 11/28/2018 10:35 PM, sha.jiang at oracle.com wrote: >>> Hi, >>> The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not >>> needed anymore, so just remove it. >>> >>> diff -r 1d520c376105 >>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz >>> Binary file >>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz >>> has changed >>> diff -r 1d520c376105 >>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 >>> --- >>> a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 >>> Wed Nov 28 18:16:39 2018 -0800 >>> +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000 >>> @@ -1,1 +0,0 @@ >>> -9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d >>> nss-3.16-with-nspr-4.10.4.tar.gz >>> >>> Best regards, >>> John Jiang >>> >> > From weijun.wang at oracle.com Tue Dec 4 02:55:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Dec 2018 10:55:49 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> Message-ID: > On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote: > >> - gss_canonicalize_name() is not fully implemented. This will be noticeable >> to callers of GSSNameElement's getKrbName(). In particular, permissions >> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly >> in NativeGSSContext). >> >> At minimum you absolutely must parse generic GSS name type names into >> Kerberos-style names (e.g., service at hostname -> service/hostname@). > > OK. I'm playing with the Java native bridge to MIT krb5 and noticed that whatever GSSName I created (user, user at REALM, service at host) the toString() of the original GSSName and its canonicalize(KRB5_OID) are always the same (and the same as the original input). On the other hand, the export() forms of them are also the same and show Kerberos-style names. From the debug output, I can see the first export() call notices it's not MN and canonicalize automatically. In my library, since there is only one mechanism, the name is created as MN at the beginning. So in import_name() you can see service at host is already changed into service/host, canonicalize_name() does nothing, and export_name() adds the realm. Is this also OK? Summary: Input MIT name export MIT mn export my name export my mn export ----- -------- ------ ------ ------ ------- ------ ----- ------ a a a at R a a at R a a at R a a at R s at h s at h s/h@ s at h s/h@ s/h s/h at R s/h s/h at R Thanks Max From weijun.wang at oracle.com Tue Dec 4 03:43:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Dec 2018 11:43:26 +0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> Message-ID: Hi Valerie I'm looking at the put->putService changes. Before this, a single put() in SunRsaSignEntries call adds a service but now you need to add() into a LinkedHashSet first in SunRsaSignEntries and then putService() each back in SunRsaSign. I don't have a simple way to do this since Provider::putService is protected and SunRsaSignEntries is also used in VerificationProvider, just wonder if you have thought about this. Thanks Max > On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: > > Hi, > > Can someone help reviewing this fix? > > Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 > Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ > > Thanks, > Valerie > > > > > From weijun.wang at oracle.com Tue Dec 4 03:57:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Dec 2018 11:57:16 +0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> Message-ID: <75F093DA-FA57-4DBC-83A8-3D26E9FE31B5@oracle.com> In fact, if the only reason why those Entries classes exist is because of VerificationProvider, can we move the content back into their Provider class as a public static method which is still callable by VerificationProvider? ?Max > ? 2018?12?4??11:43?Weijun Wang ??? > > Hi Valerie > > I'm looking at the put->putService changes. Before this, a single put() in SunRsaSignEntries call adds a service but now you need to add() into a LinkedHashSet first in SunRsaSignEntries and then putService() each back in SunRsaSign. > > I don't have a simple way to do this since Provider::putService is protected and SunRsaSignEntries is also used in VerificationProvider, just wonder if you have thought about this. > > Thanks > Max > >> On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: >> >> Hi, >> >> Can someone help reviewing this fix? >> >> Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >> >> Thanks, >> Valerie > From Kasper.Janssens at wdc.com Tue Dec 4 08:20:38 2018 From: Kasper.Janssens at wdc.com (Kasper Janssens) Date: Tue, 4 Dec 2018 08:20:38 +0000 Subject: AES ctr benchmark performance In-Reply-To: <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> Message-ID: Thanks for the answer! It?s good to know that I am likely not missing something. Okay, so I reckon that a large part of the extra work is copying buffers from the VM to get used by the AES instructions on the chip? On 03/12/2018, 19:47, "Anthony Scarpino" wrote: Hi, That is how I read it, but when I've done the test it's closer to 55%. But openssl speed and jmh are not comparable. Openssl is only running through it's algorithm, while jmh is running through the VM and java byte code. jmh has to do more work outside of pure crypto ops than openssl. Tony On 12/3/18 12:09 AM, Kasper Janssens wrote: > Hello, > > I've been measuring the performance of the java 11 built in AES-NI > instructions and, with NI switched on through JAVA_TOOL_OPTIONS = > ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. > > I run the benchmarks that are present in the open jdk itself through > ?java -server -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar > org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p > algorithm=AES/CTR/NoPadding?. > > When I compare the results and calculate the throughput in GB/s, for 16k > encoding blocks, I get about 40% of the throughput when compared to the > openssl performance test through ?openssl speed -evp aes-128-ctr?. > > I don't seem to find a decent comparison/benchmark that describes which > percentage of the maximum performance to expect with jdk 11, but 40 % > seems rather low. Does anybody know of a comparison (or might have an > idea where I go wrong, because, as these are off the shelf perf tools I > would think not a lot can be tweaked there). > > For reference, the openssl test reports this: > > The 'numbers' are in 1000s of bytes per second processed. > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes 16384 bytes > > aes-128-ctr 583576.76k 1907072.21k 4144141.40k 5612174.68k > 6252751.53k 6258371.24k > > So, for 16k blocks, 6258371k bytes per second > > The openjdk benchmark reports this > > Benchmark (algorithm) (dataSize) (keyLength) > (provider) Mode Cnt Score Error Units > > AESBench.encrypt AES/CTR/NoPadding 16384 > 128 thrpt 100 168066.873 ? 488.873 ops/s > > Out of which I conclude that, for 16k blocks, the perf here is 168066 * > 16k or about 2689056k bytes per second or about 40 % of the openssl > number, taking some liberty with rounding the numbers. > > Is that expected or am I drawing the wrong conclusions? Or am I missing > something? > > When I print the options, the jvm reports that the AES intrinsics are > being used : > > java -XX:+PrintFlagsFinal | grep -i AES > > intx MaxBCEAEstimateLevel = > 5 {product} {default} > > intx MaxBCEAEstimateSize = > 150 {product} {default} > > bool UseAES = > true {product} {default} > > System specs : Ubuntu 18.04 > > openjdk version "10.0.2" 2018-07-17 > > OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) > > OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed > mode) > > Kasper > From adam.petcher at oracle.com Tue Dec 4 18:40:47 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 4 Dec 2018 13:40:47 -0500 Subject: AES ctr benchmark performance In-Reply-To: <49900491-7263-6719-57da-4445b23605c7@oracle.com> References: <72457A7C-A430-43BA-8F06-34A77DF8A9BB@wdc.com> <2d24718e-280c-7e2d-f9f8-fbe01b1a91ce@oracle.com> <49900491-7263-6719-57da-4445b23605c7@oracle.com> Message-ID: <2889f765-bbc6-9447-81cc-b17b4e28a262@oracle.com> Another thing I noticed: The AES microbenchmark tests the performance of Cipher.doFinal(byte[]), which allocates an array on each call. This is (arguably) a bug in the benchmark, so I created JDK-8214800 to track it. Based on my experiments, this bug accounts for around 30% of the difference between OpenSSL performance and the JDK performance, as reported by this benchmark. On 12/3/2018 5:30 PM, Adam Petcher wrote: > I'm seeing JDK 11 performance around 40% of OpenSSL performance, too. > This is on a Core i7-4980HQ (Haswell, turbo at 4 GHz). > > In addition to the "Java stuff" (e.g. garbage collection, array bounds > checking) that Tony suggested, there is also the issue that the JDK > native implementation does not interleave instructions, but the > OpenSSL implementation does. The OpenSSL source file[1] has some great > information about the effect of interleaving and the performance on > various platforms. The JDK implementation of AES-CTR encrypts 6 blocks > at a time, but it does all the other operations (increment counter, > xor, etc) in sequence with the aesenc operations. The OpenSSL > implementation performs all of these other operations in parallel with > the aesenc operations. This difference in the native implementation > likely accounts for some of the difference in performance, but I don't > know how much. The "other" operations only require a relatively small > number of cycles, but doing them in sequence may hurt performance a > lot due to pipeline stalls. > > [1] > https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl > > On 12/3/2018 1:45 PM, Anthony Scarpino wrote: >> Hi, >> >> That is how I read it, but when I've done the test it's closer to >> 55%. But openssl speed and jmh are not comparable.? Openssl is only >> running through it's algorithm, while jmh is running through the VM >> and java byte code. jmh has to do more work outside of pure crypto >> ops than openssl. >> >> Tony >> >> >> On 12/3/18 12:09 AM, Kasper Janssens wrote: >>> Hello, >>> >>> I've been measuring the performance of the java 11 built in AES-NI >>> instructions and, with NI switched on through?JAVA_TOOL_OPTIONS = >>> ?-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics?. >>> >>> I run the benchmarks that are present in the open jdk itself >>> through? ?java -server -jar >>> target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar >>> org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p >>> algorithm=AES/CTR/NoPadding?. >>> >>> When I compare the results and calculate the throughput in GB/s, for >>> 16k encoding blocks, I get about 40% of the throughput when compared >>> to the openssl performance test through??openssl speed -evp >>> aes-128-ctr?. >>> >>> I don't seem to find a decent comparison/benchmark that describes >>> which percentage of the maximum performance to expect with jdk 11, >>> but 40 % seems rather low. Does anybody know of a comparison (or >>> might have an idea where I go wrong, ?because, as these are off the >>> shelf perf tools I would think not a lot can be tweaked there). >>> >>> For reference, the openssl test reports this: >>> >>> The 'numbers' are in 1000s of bytes per second processed. >>> >>> type???????????? 16 bytes???? 64 bytes??? 256 bytes?? 1024 bytes?? >>> 8192 bytes? 16384 bytes >>> >>> aes-128-ctr???? 583576.76k? 1907072.21k? 4144141.40k 5612174.68k? >>> 6252751.53k? 6258371.24k >>> >>> So, for 16k blocks, 6258371k bytes per second >>> >>> The openjdk benchmark reports this >>> >>> Benchmark?????????????? (algorithm)? (dataSize)? (keyLength) >>> (provider)?? Mode? Cnt?????? Score???? Error? Units >>> >>> AESBench.encrypt? AES/CTR/NoPadding?????? 16384 128????????????? >>> thrpt? 100? 168066.873 ? 488.873? ops/s >>> >>> Out of which I conclude that, for 16k blocks, the perf here is >>> 168066 * 16k or about 2689056k bytes per second or about 40 % of the >>> openssl number, taking some liberty with rounding the numbers. >>> >>> Is that expected or am I drawing the wrong conclusions? Or am I >>> missing something? >>> >>> When I print the options, the jvm reports that the AES intrinsics >>> are being used : >>> >>> java -XX:+PrintFlagsFinal | grep -i AES >>> >>> ????? intx MaxBCEAEstimateLevel???????????????????? = >>> 5??????????????????????????????????????? {product} {default} >>> >>> ????? intx MaxBCEAEstimateSize????????????????????? = >>> 150????????????????????????????????????? {product} {default} >>> >>> ????? bool UseAES??????????? ???????????????????????= >>> true???????????????????????????????????? {product} {default} >>> >>> System specs : Ubuntu 18.04 >>> >>> openjdk version "10.0.2" 2018-07-17 >>> >>> OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) >>> >>> OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, >>> mixed mode) >>> >>> Kasper >>> >> From anthony.scarpino at oracle.com Tue Dec 4 20:06:22 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 4 Dec 2018 12:06:22 -0800 Subject: 8214098: sun.security.ssl.HandshakeHash.T12HandshakeHash constructor check backwards. Message-ID: <67e0efc5-3889-2b68-d2be-4a3c28dbf8cc@oracle.com> Hi, I need a code review for the TLS 1.2 check being backwards for HandshakeHash, which showed up with a clonable MessageDigest object. Since TLS 1.3 does not use the same scheme as 1.2, I removed the unnecessary code. http://cr.openjdk.java.net/~ascarpino/8214098/webrev/ Tony From Nico.Williams at twosigma.com Tue Dec 4 20:34:36 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 4 Dec 2018 20:34:36 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> Message-ID: <20181204203436.GA22527@twosigma.com> On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote: > > On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote: > >> - gss_canonicalize_name() is not fully implemented. This will be noticeable > >> to callers of GSSNameElement's getKrbName(). In particular, permissions > >> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly > >> in NativeGSSContext). > >> > >> At minimum you absolutely must parse generic GSS name type names into > >> Kerberos-style names (e.g., service at hostname -> service/hostname@). > > > > OK. > > I'm playing with the Java native bridge to MIT krb5 and noticed that whatever > GSSName I created (user, user at REALM, service at host) the toString() of the > original GSSName and its canonicalize(KRB5_OID) are always the same (and the That, in principle, is a bug. That should be evidence that little code out there cares. But gss_display_name() on a generic-syntax imported name should be the same as the original input, while gss_display_name() on an MN is mechanism-specific, and for Kerberos should be a Kerberos-style name string. Looking at the JGSS code, it looks like this buglet is in MIT. I'll confirm later. > same as the original input). On the other hand, the export() forms of them > are also the same and show Kerberos-style names. Yes, code would definitely break if export() didn't do that... > From the debug output, I can see the first export() call notices it's not MN > and canonicalize automatically. > > In my library, since there is only one mechanism, the name is created as MN > at the beginning. So in import_name() you can see service at host is already > changed into service/host, canonicalize_name() does nothing, and > export_name() adds the realm. Is this also OK? In principle no. See above. > Summary: > > Input MIT name export MIT mn export my name export my mn export > ----- -------- ------ ------ ------ ------- ------ ----- ------ > a a a at R a a at R a a at R a a at R > s at h s at h s/h@ s at h s/h@ s/h s/h at R s/h s/h at R Speaking of @, I should read up on how to implement referrals on the client side using SSPI... Nico -- From sean.mullan at oracle.com Tue Dec 4 21:43:50 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 4 Dec 2018 16:43:50 -0500 Subject: RFR 8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 In-Reply-To: References: Message-ID: This looks fine to me. --Sean On 12/2/18 6:23 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8214513/webrev.00/ > > It's now able to read the wrong PBES2-params encoding created by JDK before JDK 11. > > Thanks > Max > From sean.mullan at oracle.com Tue Dec 4 22:29:48 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 4 Dec 2018 17:29:48 -0500 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> Message-ID: <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> I haven't reviewed all of this, but had a couple of comments so far: - VerificationProvider.java 77 // the provider. Otherwise, create a temporary map and use a This comment is now stale so it needs to be removed/updated. - Provider.java You removed synchronized from several of the methods, but some of those methods modified fields such as servicesChanged and legacyChanged. Are there any concurrency issues or race conditions now that those methods are not synchronized? --Sean On 11/21/18 1:05 PM, Valerie Peng wrote: > Hi, > > Can someone help reviewing this fix? > > Besides changing the Provider class to use ConcurrentHashMap in order to > reduce the lock contention on Provider.getService() calls, I also > changed the security providers in java.base module to register through > putService(...) calls. Performance is manually verified and mach5 run is > clean. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 > Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ > > Thanks, > Valerie > > > > > From xuelei.fan at oracle.com Tue Dec 4 23:09:57 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 4 Dec 2018 15:09:57 -0800 Subject: 8214098: sun.security.ssl.HandshakeHash.T12HandshakeHash constructor check backwards. In-Reply-To: <67e0efc5-3889-2b68-d2be-4a3c28dbf8cc@oracle.com> References: <67e0efc5-3889-2b68-d2be-4a3c28dbf8cc@oracle.com> Message-ID: <538b2856-1517-6cfd-f1e3-65614001c82a@oracle.com> Looks fine to me. Thanks, Xuelei On 12/4/2018 12:06 PM, Anthony Scarpino wrote: > Hi, > > I need a code review for the TLS 1.2 check being backwards for > HandshakeHash, which showed up with a clonable MessageDigest object. > Since TLS 1.3 does not use the same scheme as 1.2, I removed the > unnecessary code. > > http://cr.openjdk.java.net/~ascarpino/8214098/webrev/ > > Tony > > > From weijun.wang at oracle.com Wed Dec 5 03:41:44 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Dec 2018 11:41:44 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181204203436.GA22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> Message-ID: Java's GSSName::isMN always returns true, therefore to my observation, the GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. It is only called in export(), where the first call to export_name() might return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically call canonicalize_name() and export_name() again. And then, the export format is only useful when importing a NT_EXPORT_NAME. So, seems like both export_name() and canonicalize_name() are quite useless (at least in the view of the native bridge). What's your ideal output? The toString of canonicalize() and import(export) always showing krb5 style and name type being KRB5_NAME? --Max > On Dec 5, 2018, at 4:34 AM, Nico Williams wrote: > > On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote: >>> On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote: >>>> - gss_canonicalize_name() is not fully implemented. This will be noticeable >>>> to callers of GSSNameElement's getKrbName(). In particular, permissions >>>> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly >>>> in NativeGSSContext). >>>> >>>> At minimum you absolutely must parse generic GSS name type names into >>>> Kerberos-style names (e.g., service at hostname -> service/hostname@). >>> >>> OK. >> >> I'm playing with the Java native bridge to MIT krb5 and noticed that whatever >> GSSName I created (user, user at REALM, service at host) the toString() of the >> original GSSName and its canonicalize(KRB5_OID) are always the same (and the > > That, in principle, is a bug. That should be evidence that little code out > there cares. > > But gss_display_name() on a generic-syntax imported name should be the same as > the original input, while gss_display_name() on an MN is mechanism-specific, > and for Kerberos should be a Kerberos-style name string. > > Looking at the JGSS code, it looks like this buglet is in MIT. I'll confirm > later. > >> same as the original input). On the other hand, the export() forms of them >> are also the same and show Kerberos-style names. > > Yes, code would definitely break if export() didn't do that... > >> From the debug output, I can see the first export() call notices it's not MN >> and canonicalize automatically. >> >> In my library, since there is only one mechanism, the name is created as MN >> at the beginning. So in import_name() you can see service at host is already >> changed into service/host, canonicalize_name() does nothing, and >> export_name() adds the realm. Is this also OK? > > In principle no. See above. > >> Summary: >> >> Input MIT name export MIT mn export my name export my mn export >> ----- -------- ------ ------ ------ ------- ------ ----- ------ >> a a a at R a a at R a a at R a a at R >> s at h s at h s/h@ s at h s/h@ s/h s/h at R s/h s/h at R > > Speaking of @, I should read up on how to implement > referrals on the client side using SSPI... > > Nico > -- From weijun.wang at oracle.com Wed Dec 5 10:03:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Dec 2018 18:03:22 +0800 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> Message-ID: The change looks fine to me. Thanks Max > On Dec 4, 2018, at 1:11 AM, Se?n Coffey wrote: > > whoops: > latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v4/webrev/ > Regards, > Sean. From chris.hegarty at oracle.com Wed Dec 5 11:37:53 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Dec 2018 11:37:53 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> Message-ID: >> On Dec 4, 2018, at 1:11 AM, Se?n Coffey wrote: >> >> whoops: >> latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v4/webrev/ >> Regards, >> Sean. > Looks good. -Chris. From weijun.wang at oracle.com Wed Dec 5 14:15:37 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Dec 2018 22:15:37 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> Message-ID: <7C1FB024-097A-44C1-B368-1A162A220FD2@oracle.com> I've thought about this over and have the following plan: Since GSSName::isMN is always true, every gss_name_t must be a MN and I decide the name to be always krb5 style and the type to be always NT_KRB5_NAME. However, somewhere in the JGSS native bridge implementation the name and type are cached on the Java side, therefore the result of gSSMananger.createName("service at host", NT_HOSTBASED_SERVICE) does have toString() being service at host and type being NT_HOSTBASED_SERVICE. When canonicalize() is called, even if the GSS-API canonicalize_name() is not called a new gss_name_t is created and the Java side cache will be recreated, and this time name becomes service/host and type becomes NT_KRB5_NAME. Is this what you like to see? As for export(), I can also output a/b at . When the result is imported as a NT_EXPORT_NAME, I'll remember to remove the @ at the end. The result is: GSSManager m = GSSManager.getInstance(); GSSName n = m.createName("service at host", GSSName.NT_HOSTBASED_SERVICE); // n is now (service at host, NT_HOSTBASED_SERVICE) n = n.canonicalize(new Oid("1.2.840.113554.1.2.2")); // n is now (service/host, NT_KRB5_NAME) byte[] x = n.export(); // 0000: 04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 00 ......*.H....... // 0010: 00 00 0D 73 65 72 76 69 63 65 2F 68 6F 73 74 40 ...service/host@ n = m.createName(x, GSSName.NT_EXPORT_NAME); // n is now (service/host, NT_KRB5_NAME) Thanks Max > On Dec 5, 2018, at 11:41 AM, Weijun Wang wrote: > > Java's GSSName::isMN always returns true, therefore to my observation, the GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. It is only called in export(), where the first call to export_name() might return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically call canonicalize_name() and export_name() again. > > And then, the export format is only useful when importing a NT_EXPORT_NAME. > > So, seems like both export_name() and canonicalize_name() are quite useless (at least in the view of the native bridge). > > What's your ideal output? The toString of canonicalize() and import(export) always showing krb5 style and name type being KRB5_NAME? > > --Max > >> On Dec 5, 2018, at 4:34 AM, Nico Williams wrote: >> >> On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote: >>>> On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote: >>>>> - gss_canonicalize_name() is not fully implemented. This will be noticeable >>>>> to callers of GSSNameElement's getKrbName(). In particular, permissions >>>>> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly >>>>> in NativeGSSContext). >>>>> >>>>> At minimum you absolutely must parse generic GSS name type names into >>>>> Kerberos-style names (e.g., service at hostname -> service/hostname@). >>>> >>>> OK. >>> >>> I'm playing with the Java native bridge to MIT krb5 and noticed that whatever >>> GSSName I created (user, user at REALM, service at host) the toString() of the >>> original GSSName and its canonicalize(KRB5_OID) are always the same (and the >> >> That, in principle, is a bug. That should be evidence that little code out >> there cares. >> >> But gss_display_name() on a generic-syntax imported name should be the same as >> the original input, while gss_display_name() on an MN is mechanism-specific, >> and for Kerberos should be a Kerberos-style name string. >> >> Looking at the JGSS code, it looks like this buglet is in MIT. I'll confirm >> later. >> >>> same as the original input). On the other hand, the export() forms of them >>> are also the same and show Kerberos-style names. >> >> Yes, code would definitely break if export() didn't do that... >> >>> From the debug output, I can see the first export() call notices it's not MN >>> and canonicalize automatically. >>> >>> In my library, since there is only one mechanism, the name is created as MN >>> at the beginning. So in import_name() you can see service at host is already >>> changed into service/host, canonicalize_name() does nothing, and >>> export_name() adds the realm. Is this also OK? >> >> In principle no. See above. >> >>> Summary: >>> >>> Input MIT name export MIT mn export my name export my mn export >>> ----- -------- ------ ------ ------ ------- ------ ----- ------ >>> a a a at R a a at R a a at R a a at R >>> s at h s at h s/h@ s at h s/h@ s/h s/h at R s/h s/h at R >> >> Speaking of @, I should read up on how to implement >> referrals on the client side using SSPI... >> >> Nico >> -- > From anthony.scarpino at oracle.com Wed Dec 5 18:56:26 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 5 Dec 2018 10:56:26 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com> Message-ID: <9dcb8b6f-49d9-be5f-9787-882707ace176@oracle.com> Smita, I did some performance testing on the changes and noticed that while the larger data sizes perform better, there is a drop in the smaller data sizes. 16byte data sizes saw a drop from 2.4m ops/sec to 1.7m ops/sec and 64bytes dropped from 2.1m ops/sec to 1.5m ops/sec. At 256 bytes it is roughly equal. At 16k is the best performance increase from 60k ops/sec to 130 ops/sec Are the AVX instructions slower to setup and therefore affect smaller data sizes? Or maybe the larger array allocation in GHASH.java? Tony On 11/29/18 12:08 PM, Anthony Scarpino wrote: > [removed core-libs, added security-dev] > > I'm fine with the jdk changes and solaris-sparc appears to work fine > with the existing security and intrinsic tests.? I do not feel > comfortable reviewing the hotspot changes, so either Vladimir or someone > else from the hotspot team would need to look at it. > > Tony > > On 11/20/18 6:45 PM, Kamath, Smita wrote: >> Hi Tony, >> >> Thanks for your comments. >> >> 1)? This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? It may work as the code is now since the sparc intrinsic >> will only use the first two longs in the subkeyHtbl. >> Would it be possible to help with this sanity check?? I don't have the >> required set-up to test this scenario. >> >> 2) I have changed the code so that subkeyH corresponds to the first >> two entries of subkeyHtbl.? Please find the updated webrev link. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >> >> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >> >> Thanks and Regards, >> Smita >> >> >> >> -----Original Message----- >> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >> Sent: Tuesday, November 20, 2018 2:05 PM >> To: Kamath, Smita ; 'Vladimir Kozlov' >> >> Cc: Viswanathan, Sandhya ; >> core-libs-dev at openjdk.java.net; hotspot compiler >> >> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions >> >> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>> Instructions. I have tested this optimization on SKX x86_64 platform >>> and it shows ~20-30% performance improvement for larger message sizes >>> (for example 8k). >>> >>> I, smita.kamath at intel.com , Shay >>> Gueuron, (shay.gueron at intel.com )and >>> Regev Shemy (regev.shemy at intel.com ) are >>> contributors to this code. >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>> >>> For testing the implementation, I have executed TestAESMain.java. I >>> have executed Jtreg tests and tested this code on 64 bit Windows and >>> Linux platforms. >>> >>> Please review and let me know if you have any comments. >>> >>> Thanks and Regards, >>> >>> Smita >>> >> >> Hi, >> >> This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? >> It may work as the code is now since the sparc intrinsic will only use >> the first two longs in the subkeyHtbl. >> >> In that same idea, have you consider combining the subkeyH to be the >> first two of subkeyHtbl for the non-avx operations?? It would >> eliminate an extra two longs per instance. >> >> Tony >> > From valerie.peng at oracle.com Wed Dec 5 19:43:52 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 5 Dec 2018 11:43:52 -0800 Subject: RFR[12] JDK-8214459: NSS source should be removed In-Reply-To: References: <93a9d031-a1ff-4092-b496-6231a09bbf6c@oracle.com> <7f3ed67c-9284-5436-591a-c0a009c5a0ef@oracle.com> Message-ID: <98933f1d-25ef-fa05-8375-e6195bd5103d@oracle.com> Looks good. Thanks, Valerie On 12/3/2018 6:41 PM, sha.jiang at oracle.com wrote: > Hi Valerie, > Do you have more concern about this issue? > > I re-generate this patch with hg diff option -g. The new patch should > delete all the files, including the directory. > > diff --git > a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz > b/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz > deleted file mode 100644 > index > 63fa5feb5108f92b1cfcd2fbfc990294ed4d8fed..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 > GIT binary patch > literal 0 > Hc$@ > diff --git > a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 > b/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 > > deleted file mode 100644 > --- > a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 > +++ /dev/null > @@ -1,1 +0,0 @@ > -9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d > nss-3.16-with-nspr-4.10.4.tar.gz > > Best regards, > John Jiang > > On 2018/11/30 10:49, sha.jiang at oracle.com wrote: >> Hi Valerie, >> >> On 2018/11/30 10:28, Valerie Peng wrote: >>> I assume not just the two files, their containing src directory will >>> be removed, right? >> >> Yes. This directory also will be removed. >> >> Best regards, >> John Jiang >> >>> >>> Valerie >>> >>> On 11/28/2018 10:35 PM, sha.jiang at oracle.com wrote: >>>> Hi, >>>> The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not >>>> needed anymore, so just remove it. >>>> >>>> diff -r 1d520c376105 >>>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz >>>> Binary file >>>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz >>>> has changed >>>> diff -r 1d520c376105 >>>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 >>>> --- >>>> a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 >>>> Wed Nov 28 18:16:39 2018 -0800 >>>> +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000 >>>> @@ -1,1 +0,0 @@ >>>> -9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d >>>> nss-3.16-with-nspr-4.10.4.tar.gz >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >> From jamil.j.nimeh at oracle.com Wed Dec 5 23:59:54 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 5 Dec 2018 15:59:54 -0800 Subject: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError Message-ID: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> Hello all, This fix covers an issue where large numbers of TLS 1.2 session resumptions were causing a StackOverflowError to occur.? This was happening because the SSLSessionImpl constructor creates a new unmodifiableList from the SNI list attached to the HandshakeContext.? Since that is also an unmodifiableList, you get a new level of nesting of lists with each successive instantiation of SSLSessionImpl.? Eventually it grows to the point that an iteration of the list causes a stack overflow. Bug: https://bugs.openjdk.java.net/browse/JDK-8214129 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.01/ Thanks, --Jamil From weijun.wang at oracle.com Thu Dec 6 03:28:00 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 6 Dec 2018 11:28:00 +0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> Message-ID: <8C26FDD8-5C81-466D-9A8B-EACCE2E1052F@oracle.com> Hi Valerie - map.put("CertPathBuilder.PKIX ValidationAlgorithm", - "RFC5280"); - map.put("CertPathValidator.PKIX ValidationAlgorithm", - "RFC5280"); + attrs.put("PKIX ValidationAlgorithm", "RFC5280"); <<<<<<<<<< !!!! + add(p, "CertPathBuilder", "PKIX", + "sun.security.provider.certpath.SunCertPathBuilder", + null, attrs); + add(p, "CertPathValidator", "PKIX", + "sun.security.provider.certpath.PKIXCertPathValidator", + null, attrs); Here, "PKIX" is the algorithm name and not a part of the attribute name. Other new aliases and attributes look good. Thanks Max > On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: > > Hi, > > Can someone help reviewing this fix? > > Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 > Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ > > Thanks, > Valerie > > > > > From xuelei.fan at oracle.com Thu Dec 6 04:20:45 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 5 Dec 2018 20:20:45 -0800 Subject: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError In-Reply-To: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> References: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> Message-ID: <65f11950-3cc2-740c-3341-e6a31ac07d15@oracle.com> Hi Jamil, For a defense in depth fix, as you are already there, I may suggest update two more places. ServerNameExtension.java: ------------------------ private CHServerNamesSpec(List serverNames) { this.serverNames = Collections.unmodifiableList(serverNames); } SSLSessionImpl.java: -------------------- this.localSupportedSignAlgs = ... // two places in the constructors The coding style of the use of unmodifiableList() looks a little bit weird for a code reader who does not familar with the limitation of unmodifiableList() method. What do you think if adding a comment about why we code this way? Just in case, someone may rollback it later. Otherwise, looks fine to me. Thanks, Xuelei On 12/5/2018 3:59 PM, Jamil Nimeh wrote: > Hello all, > > This fix covers an issue where large numbers of TLS 1.2 session > resumptions were causing a StackOverflowError to occur.? This was > happening because the SSLSessionImpl constructor creates a new > unmodifiableList from the SNI list attached to the HandshakeContext. > Since that is also an unmodifiableList, you get a new level of nesting > of lists with each successive instantiation of SSLSessionImpl. > Eventually it grows to the point that an iteration of the list causes a > stack overflow. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214129 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.01/ > > Thanks, > > --Jamil > From jamil.j.nimeh at oracle.com Thu Dec 6 08:29:21 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 6 Dec 2018 00:29:21 -0800 Subject: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError In-Reply-To: <65f11950-3cc2-740c-3341-e6a31ac07d15@oracle.com> References: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> <65f11950-3cc2-740c-3341-e6a31ac07d15@oracle.com> Message-ID: <5aa55983-0ac6-e819-4c6b-9901a05e971b@oracle.com> I will change those additional spots in the code.? Glad you caught those.? I think also your suggestion about a comment on those locations in the code makes sense. --Jamil On 12/5/2018 8:20 PM, Xue-Lei Fan wrote: > Hi Jamil, > > For a defense in depth fix, as you are already there, I may suggest > update two more places. > > ServerNameExtension.java: > ------------------------ > ? private CHServerNamesSpec(List serverNames) { > ????? this.serverNames = > Collections.unmodifiableList(serverNames); > ? } > > SSLSessionImpl.java: > -------------------- > this.localSupportedSignAlgs = ... // two places in the constructors > > > The coding style of the use of unmodifiableList() looks a little bit > weird for a code reader who does not familar with the limitation of > unmodifiableList() method.? What do you think if adding a comment > about why we code this way?? Just in case, someone may rollback it later. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > > On 12/5/2018 3:59 PM, Jamil Nimeh wrote: >> Hello all, >> >> This fix covers an issue where large numbers of TLS 1.2 session >> resumptions were causing a StackOverflowError to occur.? This was >> happening because the SSLSessionImpl constructor creates a new >> unmodifiableList from the SNI list attached to the HandshakeContext. >> Since that is also an unmodifiableList, you get a new level of >> nesting of lists with each successive instantiation of >> SSLSessionImpl. Eventually it grows to the point that an iteration of >> the list causes a stack overflow. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214129 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.01/ >> >> Thanks, >> >> --Jamil >> From weijun.wang at oracle.com Thu Dec 6 13:27:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 6 Dec 2018 21:27:48 +0800 Subject: Fwd: My current jdk12 changes References: Message-ID: <241E9CD7-937F-4A77-8621-DDE5E399A3DE@oracle.com> Hi All Currently, I have 4 code changes out for review and I wish they can make JDK 12 (RDP1 is 12/13) 8076190: Customizing the generation of a PKCS12 keystore https://cr.openjdk.java.net/~weijun/8076190/webrev.05/ 6722928: Support SSPI as a native GSS-API provider https://cr.openjdk.java.net/~weijun/6722928/webrev.02/ 8213009: Refactoring existing SunMSCAPI classes (CNG step 1) https://cr.openjdk.java.net/~weijun/8213009/webrev.02/ 8213010: Supporting keys created with certmgr.exe (CNG step 1) https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ I've just finalized CSRs for the first 2. They were already in provisional status before. Sean is reviewing the pkcs12 one. Nicolas Williams provided feedback on the SSPI one and I still need an official code reviewer. Valerie had reviewed CNG step 1. Are you OK with the updated webrev? No comment for CNG step 2 yet. Thanks Max From weijun.wang at oracle.com Thu Dec 6 14:33:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 6 Dec 2018 22:33:40 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com> <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com> Message-ID: Webrev updated at https://cr.openjdk.java.net/~weijun/8213009/webrev.03 I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key instanceof RSAPublicKey" in RSA::engineInitVerify. Thanks Max > On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote: > > > >> On Nov 27, 2018, at 9:55 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Please find comments in line. >> On 11/22/2018 6:04 AM, Weijun Wang wrote: >>>> On Nov 22, 2018, at 9:14 AM, Valerie Peng >>>> wrote: >>>> >>>> Hi Max, >>>> >>>> Here are some comments: >>>> >>>> >>>> - line 39, add PSS here as well. >>>> - line 97, CSignature ctr, better to initialize all fields >>>> >>> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. >>> >> I was referring messageDigest/messageDigestAlgorithm/needsReset. My general preference is to set them to null/false even when not used, may help catch future coding problems. > > OK. > >>>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 >>>> >>> Can I do this later? This sub-task is meant to be a cleanup. >> My point for checking the key algorithm is to ensure that the specified key object is RSA type. After this cleanup and refactoring, the specified key should be checked to be of RSA type, i.e. line 111, 130. Otherwise, the casting to various RSA public/private key interfaces, e.g. java.security.interfaces.RSAPublicKey, may fail. > > OK, I can check for RSAPublicKey. > > On the other hand, if I create a subclass for CRSAPrivateKey, its getModulus() and getPrivateExponent() can only throw out a ProviderException if the key is unextractable, and this breaks some existing code inside JDK. > > Thanks > Max > >> >> Updates look fine. >> >> Regards, >> >> Valerie >> >>> But I think I need to move more RSA related methods into the RSA subclass. >>> >>> >>>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" >>>> >>> OK. >>> >>> >>>> - line 681: can be static, right? pkg-private? >>>> >>> Yes. Looks like it can be private. >>> >>> >>>> >>>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. >>>> >>> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. >>> >>> >>>> - line 127, add @Override >>>> >>> OK. >>> >>> >>>> - line 140, must getPublicKeyBob be public? Maybe pkg private? >>>> >>> Correct. >>> >>> >>>> >>>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. >>>> >>> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. >>> >>> >>>> >>>> - would be nice to have a String constant for "RSA". >>>> >>> Sure. >>> >>> Thanks >>> Max >>> >>> >>>> Rest looks fine. >>>> Thanks, >>>> Valerie >>>> >>>> >>>> On 11/15/2018 7:40 AM, Weijun Wang wrote: >>>> >>>>> Oops, my copy/paste sequence goes wrong. >>>>> >>>>> >>>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> Webrev updated at >>>>>> >>>>>> >>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >>>>> >>>>> >>>>> >>>>>> More refactorings: >>>>>> >>>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>>>>> >>>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>>>>> >>>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>>>>> >>>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang >>>>>>> wrote: >>>>>>> >>>>>>> Webrev updated at >>>>>>> >>>>>>> >>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>>>>> >>>>>>> >>>>>>> The subtask id is now used. >>>>>>> >>>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> Please review the change at >>>>>>>> >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>>>>> >>>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>>>>> >>>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>>>>> >>>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>>>>> >>>>>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>>>>> >>>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>>>>> >>>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>>>>> >>>>>>>> Noreg-cleanup. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> [1] >>>>>>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier > From Nico.Williams at twosigma.com Thu Dec 6 18:48:24 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 6 Dec 2018 18:48:24 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> Message-ID: <20181206184824.GB22527@twosigma.com> On Wed, Dec 05, 2018 at 11:41:44AM +0800, Weijun Wang wrote: > Java's GSSName::isMN always returns true, therefore to my observation, the > GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. That *would* be a valid design choice (per RFCs 2743 and 2744), but it requires always calling gss_canonicalize_name() immediately when you gss_import_name() a string (as opposed to an exported name token). However, to do this you have to canonicalize the name for every mechanism indicated by gss_indicate_mechs()! And then it wouldn't be clear what to output from toString() when the native provider supports multiple mechanisms, so I don't recommend this design choice. But the JGSS JNI bindings isn't actually doing any of that. Instead the JGSS JNI bindings outright lies about the name claiming it's an MN when it may not be. I'm not sure how much appetite we should have to fix this sort of buglet, but it should be fixed, really. If I'd noticed this buglet a couple of years ago then our contribution would include a fix for it :( > It is only called in export(), where the first call to export_name() might (And in getKrbName(), which is used only for JAAS permissions checks.) > return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically > call canonicalize_name() and export_name() again. Right. > And then, the export format is only useful when importing a NT_EXPORT_NAME. The export name is meant for two things: - to be able to get a stable token you can store in things like ACLs - to be able to memcmp() for name equality, which has different semantics than gss_compare_name() > So, seems like both export_name() and canonicalize_name() are quite useless > (at least in the view of the native bridge). Exported name tokens have uses (see above), and it does work in JGSS. So exportName is not at all useless. canonicalizeName(), however, is pretty useless. Because gss_canonicalize_name() is pretty useless. gss_canonicalize_name() was originally intended so that one could write an application that takes a user-input principal name, canonicalizes it, exports it, and stores the exported name token in an ACL. The problems with gss_canonicalize_name() are: a) It can require credentials in order to talk to a directory, but there's no input credentials handle argument. E.g., given referrals, to properly canonicalize a name with Kerberos requires doing TGS exchanges, which requires Kerberos client credentials. b) A directory may be required for the canonicalization step, but none may be available. E.g., imagine a GSS mechanism that uses PKIX certificates... How would you resolve a name "nico" of username name-type to something like CN=nico,...? For some realms you could have local mapping rules configuration to do that with, but in the general case you'd need a directory (LDAP, say), and you'd have to know how to search it for this. There isn't always a directory that allows these searches, and it's not always the case that certificates issued by some CA adhere to a rigid naming convention. Even if you use various subjectAlternativeName name types, you'd still have canonicalization issues that might require a directory. Oh, and searching any such directory would presumably require credentials; see (a). We've had a few lengthy discussions of this on the KRB-WG and KITTEN mailing lists. And I suspect if you look you might find discussions of this in the old CAT WG mailing list from the early- and mid-90s. Because of its shortcomings, I'm inclined to not worry too much about gss_canonicalize_name(), but isMN() *must not* lie, that's for sure, so in the end I'm inclined to just fix GSSNameElement to know whether a name is an MN, and to have a proper, public canonicalize() method that calls the native canonicalizeName() method (and so gss_canonicalize_name()). If you do all this then exportName() need not have that fallback code path to call gss_canonicalize_name(). In principle it's a bug to do that because, again, if the native GSS provider supports multiple mechanisms, which mechanism should exportName() pick?! This sort of bug has been papered over by supporting only Kerberos and SPNEGO, since ultimately that means supporting only Kerberos. But there are other mechanisms that might be supported. E.g., MSFT has one called PKU2U that uses PKIX credentials instead of Kerberos, and Globus has one that uses TLS for the same purpose. > What's your ideal output? The toString of canonicalize() and import(export) > always showing krb5 style and name type being KRB5_NAME? In the JNI bindings toString() should always output whatever gss_display_name() outputs. Full stop. The effect of that, if the bindings only call gss_canonicalize_name() when the Java canonicalize() method is called, would be this: - if a name is not an MN, meaning it wasn't output by gss_canonicalize_name(), gss_accept_sec_context(), gss_inquire_context(), or gss_import_name() of a GSS_C_NT_EXPORTED_NAME token, then toString() should return the original name from the gss_import_name() call (the GSSNameElement constructor); - otherwise (if a name is an MN), then toString() should return the output of gss_display_name() as applied to the MN If the JNI bindings were to aggressively call gss_canonicalize_name() early, then you'd have to choose a mechanism whose name display form to output in toString() (see above). Nico -- From Nico.Williams at twosigma.com Thu Dec 6 18:56:14 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 6 Dec 2018 18:56:14 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> References: <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com> <296eee95-58c7-d658-90e5-379d3091df8c@oracle.com> Message-ID: <20181206185614.GC22527@twosigma.com> On Mon, Dec 03, 2018 at 05:10:26PM +0000, Se?n Coffey wrote: > I made further edits to update the DNSName comment code to reference RFC > 5280 rather than the obsoleted RFC 2459. I also updated the test case with a > few extra tests per suggestion from Chris and others. Moved the dataprovider > into a good and bad data set also. > > A follow on bug has been logged to update all references of RFC 2459 to RFC > 5280 (JDK-8214532) Note that RFC 5280 has been updated by RFC 8399 as to dNSName, though that update wouldn't be relevant to the code you're changing, but it might be relevant to other references to RFCs 2459 and 5280 for all I know. For the record, I reviewed your changes and they LGTM. I did check whether non-hostname domainnames are allowed (e.g., SRV RR names), but RFC 5280 specifically refers to hostname syntax by referring to section 2.1 of RFC 1123. Nico -- From adam.petcher at oracle.com Thu Dec 6 20:14:08 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Dec 2018 15:14:08 -0500 Subject: RFR 8214688: TLS 1.3 session resumption with hello retry request failed with "illegal_parameter" Message-ID: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> Webrev: http://cr.openjdk.java.net/~apetcher/8214688/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8214688 The last session resumption bug fix[1] I made introduced a new issue when the server sends a HelloRetryRequest message. The proposed fix is pretty simple: when the client selects a ticket ID to use, it stores the ID in its context so it can find it again when it sends the second ClientHello message. We don't have regression tests for HelloRetryRequest, but I did more interop testing this time to try to prevent additional issues like this. [1] https://bugs.openjdk.java.net/browse/JDK-8213202 From jamil.j.nimeh at oracle.com Thu Dec 6 21:09:00 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 6 Dec 2018 13:09:00 -0800 Subject: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError In-Reply-To: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> References: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> Message-ID: Hello everyone, Updates from Xuelei's comments have been folded into an updated webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/ Thank you, --Jamil On 12/5/18 3:59 PM, Jamil Nimeh wrote: > Hello all, > > This fix covers an issue where large numbers of TLS 1.2 session > resumptions were causing a StackOverflowError to occur.? This was > happening because the SSLSessionImpl constructor creates a new > unmodifiableList from the SNI list attached to the HandshakeContext.? > Since that is also an unmodifiableList, you get a new level of nesting > of lists with each successive instantiation of SSLSessionImpl.? > Eventually it grows to the point that an iteration of the list causes > a stack overflow. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214129 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.01/ > > Thanks, > > --Jamil > From Nico.Williams at twosigma.com Thu Dec 6 21:33:25 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 6 Dec 2018 21:33:25 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181206184824.GB22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> Message-ID: <20181206213325.GE22527@twosigma.com> Looking at how to fix the incorrect isMN() implementation... The lowest cost route to fixing that would start with this sort of change: diff --git a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java index e1e89059c5..7939005652 100644 --- a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java +++ b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java @@ -125,6 +125,7 @@ public class GSSNameImpl implements GSSName { private String printableName = null; private Oid printableNameType = null; + private boolean isMechName; private HashMap elements = null; private GSSNameSpi mechElement = null; @@ -142,6 +143,7 @@ public class GSSNameImpl implements GSSName { this.mechElement = mechElement; elements = new HashMap(1); elements.put(mechElement.getMechanism(), this.mechElement); + this.isMechName = mechElement.getMechanism() != null; } GSSNameImpl(GSSManagerImpl gssManager, @@ -179,6 +181,7 @@ public class GSSNameImpl implements GSSName { this.gssManager = gssManager; this.elements = new HashMap(gssManager.getMechs().length); + this.isMechName = appNameType.equals(NT_EXPORT_NAME) && mech != null; if (appName instanceof String) { this.appNameStr = (String) appName; @@ -198,15 +201,17 @@ public class GSSNameImpl implements GSSName { this.appNameType = appNameType; - mechElement = getElement(mech); + if (mech != NULL) { + mechElement = getElement(mech); - /* - * printableName will be null if appName was in a byte[] or if - * appName was in a String but appNameType was null. - */ - if (printableName == null) { - printableName = mechElement.toString(); - printableNameType = mechElement.getStringNameType(); + /* + * printableName will be null if appName was in a byte[] or if + * appName was in a String but appNameType was null. + */ + if (printableName == null) { + printableName = mechElement.toString(); + printableNameType = mechElement.getStringNameType(); + } } /* @@ -215,7 +220,8 @@ public class GSSNameImpl implements GSSName { * appNameType (could be null) * printableName * printableNameType - * mechElement (which also exists in the hashmap of elements) + * mechElement (could be null, if not then it is also in the hashmap + * of elements) */ } @@ -464,7 +470,7 @@ public class GSSNameImpl implements GSSName { } public boolean isMN() { - return true; // Since always canonicalized for some mech + return isMechName; } public synchronized GSSNameSpi getElement(Oid mechOid) I've not attempted to build this, much less test it. There may be other changes needed elsewhere (bet on it). Nico -- From xuelei.fan at oracle.com Thu Dec 6 22:00:31 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Thu, 6 Dec 2018 14:00:31 -0800 Subject: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError In-Reply-To: References: <357eacc8-e57e-022c-7b1d-9621477bd512@oracle.com> Message-ID: <80f417ed-3e20-3dd7-321b-d13a70099397@oracle.com> Looks fine to me. Thanks, Xuelei On 12/6/2018 1:09 PM, Jamil Nimeh wrote: > Hello everyone, > > Updates from Xuelei's comments have been folded into an updated webrev: > > http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/ > > Thank you, > > --Jamil > > On 12/5/18 3:59 PM, Jamil Nimeh wrote: >> Hello all, >> >> This fix covers an issue where large numbers of TLS 1.2 session >> resumptions were causing a StackOverflowError to occur.? This was >> happening because the SSLSessionImpl constructor creates a new >> unmodifiableList from the SNI list attached to the HandshakeContext. >> Since that is also an unmodifiableList, you get a new level of nesting >> of lists with each successive instantiation of SSLSessionImpl. >> Eventually it grows to the point that an iteration of the list causes >> a stack overflow. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214129 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.01/ >> >> Thanks, >> >> --Jamil >> From anthony.scarpino at oracle.com Thu Dec 6 22:24:54 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 6 Dec 2018 14:24:54 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <6563F381B547594081EF9DE181D0791288A23A16@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com> <9dcb8b6f-49d9-be5f-9787-882707ace176@oracle.com> <6563F381B547594081EF9DE181D0791288A23A16@FMSMSX119.amr.corp.intel.com> Message-ID: Hi Smita, Great, the numbers look better. I'll run the regression tests and push it if all goes well. Tony On 12/6/18 11:19 AM, Kamath, Smita wrote: > Hi Tony, > > I have updated my code to address the performance regression in smaller data sizes. > Please find the updated webrev and JBS link attached. > > JBS link: https://bugs.openjdk.java.net/browse/JDK-8214074 > Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev02/ > > Thank you very much for your time and assistance. Please let me know if you have any questions. > > Regards, > Smita > > -----Original Message----- > From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] > Sent: Wednesday, December 5, 2018 10:56 AM > To: Kamath, Smita ; 'Vladimir Kozlov' > Cc: Viswanathan, Sandhya ; OpenJDK Security ; hotspot compiler > Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions > > Smita, > > I did some performance testing on the changes and noticed that while the larger data sizes perform better, there is a drop in the smaller data sizes. 16byte data sizes saw a drop from 2.4m ops/sec to 1.7m ops/sec and 64bytes dropped from 2.1m ops/sec to 1.5m ops/sec. At 256 bytes it is roughly equal. At 16k is the best performance increase from 60k ops/sec to 130 ops/sec > > Are the AVX instructions slower to setup and therefore affect smaller data sizes? Or maybe the larger array allocation in GHASH.java? > > Tony > > On 11/29/18 12:08 PM, Anthony Scarpino wrote: >> [removed core-libs, added security-dev] >> >> I'm fine with the jdk changes and solaris-sparc appears to work fine >> with the existing security and intrinsic tests.? I do not feel >> comfortable reviewing the hotspot changes, so either Vladimir or >> someone else from the hotspot team would need to look at it. >> >> Tony >> >> On 11/20/18 6:45 PM, Kamath, Smita wrote: >>> Hi Tony, >>> >>> Thanks for your comments. >>> >>> 1)? This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? It may work as the code is now since the sparc intrinsic >>> will only use the first two longs in the subkeyHtbl. >>> Would it be possible to help with this sanity check?? I don't have >>> the required set-up to test this scenario. >>> >>> 2) I have changed the code so that subkeyH corresponds to the first >>> two entries of subkeyHtbl.? Please find the updated webrev link. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >>> >>> Thanks and Regards, >>> Smita >>> >>> >>> >>> -----Original Message----- >>> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >>> Sent: Tuesday, November 20, 2018 2:05 PM >>> To: Kamath, Smita ; 'Vladimir Kozlov' >>> >>> Cc: Viswanathan, Sandhya ; >>> core-libs-dev at openjdk.java.net; hotspot compiler >>> >>> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX >>> instructions >>> >>> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>>> Instructions. I have tested this optimization on SKX x86_64 platform >>>> and it shows ~20-30% performance improvement for larger message >>>> sizes (for example 8k). >>>> >>>> I, smita.kamath at intel.com , Shay >>>> Gueuron, (shay.gueron at intel.com )and >>>> Regev Shemy (regev.shemy at intel.com ) >>>> are contributors to this code. >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>>> >>>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>>> >>>> For testing the implementation, I have executed TestAESMain.java. I >>>> have executed Jtreg tests and tested this code on 64 bit Windows and >>>> Linux platforms. >>>> >>>> Please review and let me know if you have any comments. >>>> >>>> Thanks and Regards, >>>> >>>> Smita >>>> >>> >>> Hi, >>> >>> This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? >>> It may work as the code is now since the sparc intrinsic will only >>> use the first two longs in the subkeyHtbl. >>> >>> In that same idea, have you consider combining the subkeyH to be the >>> first two of subkeyHtbl for the non-avx operations?? It would >>> eliminate an extra two longs per instance. >>> >>> Tony >>> >> > From valerie.peng at oracle.com Thu Dec 6 22:58:45 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Dec 2018 14:58:45 -0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com> <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com> Message-ID: <741f46e0-df55-e5da-6a89-f8e40d5a0c4c@oracle.com> Hi, Max, CSignature.java: one last nit, line 98 and 102 can be replaced by just one line outside the if-block. Thanks, Valerie On 12/6/2018 6:33 AM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8213009/webrev.03 > > I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key instanceof RSAPublicKey" in RSA::engineInitVerify. > > Thanks > Max > > >> On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote: >> >> >> >>> On Nov 27, 2018, at 9:55 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> Please find comments in line. >>> On 11/22/2018 6:04 AM, Weijun Wang wrote: >>>>> On Nov 22, 2018, at 9:14 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> Here are some comments: >>>>> >>>>> >>>>> - line 39, add PSS here as well. >>>>> - line 97, CSignature ctr, better to initialize all fields >>>>> >>>> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. >>>> >>> I was referring messageDigest/messageDigestAlgorithm/needsReset. My general preference is to set them to null/false even when not used, may help catch future coding problems. >> OK. >> >>>>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 >>>>> >>>> Can I do this later? This sub-task is meant to be a cleanup. >>> My point for checking the key algorithm is to ensure that the specified key object is RSA type. After this cleanup and refactoring, the specified key should be checked to be of RSA type, i.e. line 111, 130. Otherwise, the casting to various RSA public/private key interfaces, e.g. java.security.interfaces.RSAPublicKey, may fail. >> OK, I can check for RSAPublicKey. >> >> On the other hand, if I create a subclass for CRSAPrivateKey, its getModulus() and getPrivateExponent() can only throw out a ProviderException if the key is unextractable, and this breaks some existing code inside JDK. >> >> Thanks >> Max >> >>> Updates look fine. >>> >>> Regards, >>> >>> Valerie >>> >>>> But I think I need to move more RSA related methods into the RSA subclass. >>>> >>>> >>>>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" >>>>> >>>> OK. >>>> >>>> >>>>> - line 681: can be static, right? pkg-private? >>>>> >>>> Yes. Looks like it can be private. >>>> >>>> >>>>> >>>>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. >>>>> >>>> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. >>>> >>>> >>>>> - line 127, add @Override >>>>> >>>> OK. >>>> >>>> >>>>> - line 140, must getPublicKeyBob be public? Maybe pkg private? >>>>> >>>> Correct. >>>> >>>> >>>>> >>>>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. >>>>> >>>> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. >>>> >>>> >>>>> >>>>> - would be nice to have a String constant for "RSA". >>>>> >>>> Sure. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> Rest looks fine. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> >>>>> On 11/15/2018 7:40 AM, Weijun Wang wrote: >>>>> >>>>>> Oops, my copy/paste sequence goes wrong. >>>>>> >>>>>> >>>>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang >>>>>>> wrote: >>>>>>> >>>>>>> Webrev updated at >>>>>>> >>>>>>> >>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>>> More refactorings: >>>>>>> >>>>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>>>>>> >>>>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>>>>>> >>>>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>>>>>> >>>>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> Webrev updated at >>>>>>>> >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> The subtask id is now used. >>>>>>>> >>>>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Please review the change at >>>>>>>>> >>>>>>>>> >>>>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>>>>>> >>>>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>>>>>> >>>>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>>>>>> >>>>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>>>>>> >>>>>>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>>>>>> >>>>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>>>>>> >>>>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>>>>>> >>>>>>>>> Noreg-cleanup. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From weijun.wang at oracle.com Fri Dec 7 00:24:44 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Dec 2018 08:24:44 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: <741f46e0-df55-e5da-6a89-f8e40d5a0c4c@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com> <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com> <741f46e0-df55-e5da-6a89-f8e40d5a0c4c@oracle.com> Message-ID: Hi Valerie, I'll fix it in my local repo, run some test, and push the changeset. Thanks, Max > On Dec 7, 2018, at 6:58 AM, Valerie Peng wrote: > > Hi, Max, > > CSignature.java: one last nit, line 98 and 102 can be replaced by just one line outside the if-block. > > Thanks, > > Valerie > > On 12/6/2018 6:33 AM, Weijun Wang wrote: >> Webrev updated at >> >> https://cr.openjdk.java.net/~weijun/8213009/webrev.03 >> >> I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key instanceof RSAPublicKey" in RSA::engineInitVerify. >> >> Thanks >> Max >> >>> On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Nov 27, 2018, at 9:55 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> Please find comments in line. >>>> On 11/22/2018 6:04 AM, Weijun Wang wrote: >>>>>> On Nov 22, 2018, at 9:14 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> Here are some comments: >>>>>> >>>>>> >>>>>> - line 39, add PSS here as well. >>>>>> - line 97, CSignature ctr, better to initialize all fields >>>>>> >>>>> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. >>>>> >>>> I was referring messageDigest/messageDigestAlgorithm/needsReset. My general preference is to set them to null/false even when not used, may help catch future coding problems. >>> OK. >>> >>>>>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 >>>>>> >>>>> Can I do this later? This sub-task is meant to be a cleanup. >>>> My point for checking the key algorithm is to ensure that the specified key object is RSA type. After this cleanup and refactoring, the specified key should be checked to be of RSA type, i.e. line 111, 130. Otherwise, the casting to various RSA public/private key interfaces, e.g. java.security.interfaces.RSAPublicKey, may fail. >>> OK, I can check for RSAPublicKey. >>> >>> On the other hand, if I create a subclass for CRSAPrivateKey, its getModulus() and getPrivateExponent() can only throw out a ProviderException if the key is unextractable, and this breaks some existing code inside JDK. >>> >>> Thanks >>> Max >>> >>>> Updates look fine. >>>> >>>> Regards, >>>> >>>> Valerie >>>> >>>>> But I think I need to move more RSA related methods into the RSA subclass. >>>>> >>>>> >>>>>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" >>>>>> >>>>> OK. >>>>> >>>>> >>>>>> - line 681: can be static, right? pkg-private? >>>>>> >>>>> Yes. Looks like it can be private. >>>>> >>>>> >>>>>> >>>>>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. >>>>>> >>>>> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. >>>>> >>>>> >>>>>> - line 127, add @Override >>>>>> >>>>> OK. >>>>> >>>>> >>>>>> - line 140, must getPublicKeyBob be public? Maybe pkg private? >>>>>> >>>>> Correct. >>>>> >>>>> >>>>>> >>>>>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. >>>>>> >>>>> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. >>>>> >>>>> >>>>>> >>>>>> - would be nice to have a String constant for "RSA". >>>>>> >>>>> Sure. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> Rest looks fine. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> >>>>>> On 11/15/2018 7:40 AM, Weijun Wang wrote: >>>>>> >>>>>>> Oops, my copy/paste sequence goes wrong. >>>>>>> >>>>>>> >>>>>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> Webrev updated at >>>>>>>> >>>>>>>> >>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>>> More refactorings: >>>>>>>> >>>>>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>>>>>>> >>>>>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>>>>>>> >>>>>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>>>>>>> >>>>>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Webrev updated at >>>>>>>>> >>>>>>>>> >>>>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> The subtask id is now used. >>>>>>>>> >>>>>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Please review the change at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>>>>>>> >>>>>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>>>>>>> >>>>>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>>>>>>> >>>>>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>>>>>>> >>>>>>>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>>>>>>> >>>>>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>>>>>>> >>>>>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>>>>>>> >>>>>>>>>> Noreg-cleanup. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From weijun.wang at oracle.com Fri Dec 7 00:41:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Dec 2018 08:41:13 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181206213325.GE22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <20181206213325.GE22527@twosigma.com> Message-ID: <7455A11F-412A-488C-A706-3C2B24319B8E@oracle.com> I filed https://bugs.openjdk.java.net/browse/JDK-8214988. Thanks, Max > On Dec 7, 2018, at 5:33 AM, Nico Williams wrote: > > Looking at how to fix the incorrect isMN() implementation... The lowest cost > route to fixing that would start with this sort of change: > > diff --git a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java > index e1e89059c5..7939005652 100644 > --- a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java > +++ b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java .... From jamil.j.nimeh at oracle.com Fri Dec 7 01:03:09 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 6 Dec 2018 17:03:09 -0800 Subject: RFR 8208648: ECC Field Arithmetic Enhancements In-Reply-To: References: Message-ID: <102ad6c6-30b6-bdb8-9ef4-725315319f79@oracle.com> Hi Adam, comments/questions below (mostly simple stuff, nothing major): * IntegerPolynomial.java o The comment block for multByInt should reflect your changes you made, namely the removal of "r" from the signature. o 88: In the case of multiplying two very large long values would we ever see those cause an overflow.? If so, is it OK to have them overflow before the reduce operation? o 420-425: Looks like this was a copy of the comment block from conditionalSwap().? Maybe needs to be tailored to what the conditionalAssign method does? o IntegerPolynomialP256.java, IntegerPolynomialP384.java, IntegerPolynomialP521.java + In the carryReduce0 and carryReduce methods, you have many uses of an integer literal (33554432 for P256, 134217728 for P384/521).? Should these be made as private static final long values? o P256OrderField.java, P384OrderField.java, P521OrderField.java + Similar question about using a static final long vs. repeated int literal values in the carryReduce* methods. o With respect to the last two main bullet items: Would conversion to a static final value be difficult due to the fact that they are generated from Fieldgen.jsh? --Jamil On 11/30/2018 11:59 AM, Adam Petcher wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8208648 > webrev: http://cr.openjdk.java.net/~apetcher/8208648/webrev.00/ > > This changeset includes the enhancements to the finite field > arithmetic library that are necessary for the new implementation of > ECDSA and ECDH[1]. The actual ECDH and ECDSA changes will be reviewed > separately. Please see the JBS tickets for more information about the > changes, and here are some additional notes: > > 1) This change includes a code generator that produces finite field > implementations. The generated code is included in the review, and it > will be checked in to the repository with a comment indicating that it > is generated and should not be modified directly. Another option is to > put the code generator into the build process so the generated code > does not need to be checked in, but it's not clear whether this is a > better option. > 2) Reviewing every line of the generated code is probably not > necessary, and it is probably better to focus on the code generator > itself (Fieldgen.jsh). Of course, it is probably a good idea to review > the generated code for its structure and for opportunities for > improvement. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8208698 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Dec 7 02:25:19 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Dec 2018 18:25:19 -0800 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Martin, I suppose the changes in this update is just the system property renaming? I looked at the relevant files and they look fine. If you made more changes than this, please let me know and I will take a closer look at them. Don't forget to add a release note subtask for JDK-6913047 as it has a "release-note=yes" label. I will re-run mach5 with this webrev.15 just to be safe. Regards, Valerie On 11/29/2018 8:45 AM, Martin Balao wrote: > Hi Valerie, > > Webrev.15 > > * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.15/ > * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.15.zip > > Property to disable this fix has been renamed to > "sun.security.pkcs11.disableKeyExtraction", as requested in the CSR [1]. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8213430 From weijun.wang at oracle.com Fri Dec 7 02:45:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Dec 2018 10:45:02 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181206184824.GB22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> Message-ID: <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> Hi Nico, Your detailed analysis is very valuable and I've included the whole text into https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was complicated at the beginning and I remember I've especially asked you to look at it in my initial code review request. I think I have a better understanding now but unfortunately we are not likely to fix the native library very soon since RDP 1 for JDK 12 is near [1]. Let's come back to this bug. Yesterday I sent out a plan (pasted below): > Since GSSName::isMN is always true, every gss_name_t must be a MN and I decide the name to be always krb5 style and the type to be always NT_KRB5_NAME. However, somewhere in the JGSS native bridge implementation the name and type are cached on the Java side, therefore the result of gSSMananger.createName("service at host", NT_HOSTBASED_SERVICE) does have toString() being service at host and type being NT_HOSTBASED_SERVICE. When canonicalize() is called, even if the GSS-API canonicalize_name() is not called a new gss_name_t is created and the Java side cache will be recreated, and this time name becomes service/host and type becomes NT_KRB5_NAME. > > Is this what you like to see? > > As for export(), I can also output a/b at . When the result is imported as a NT_EXPORT_NAME, I'll remember to remove the @ at the end. > > The result is: > > GSSManager m = GSSManager.getInstance(); > GSSName n = m.createName("service at host", GSSName.NT_HOSTBASED_SERVICE); > // n is now (service at host, NT_HOSTBASED_SERVICE) > n = n.canonicalize(new Oid("1.2.840.113554.1.2.2")); > // n is now (service/host, NT_KRB5_NAME) > byte[] x = n.export(); > // 0000: 04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 00 ......*.H....... > // 0010: 00 00 0D 73 65 72 76 69 63 65 2F 68 6F 73 74 40 ...service/host@ > n = m.createName(x, GSSName.NT_EXPORT_NAME); > // n is now (service/host, NT_KRB5_NAME) I think the result is quite good. It's like the native bridge itself has stored a non-MN (except that its isMN() is true) although inside the new library there is only MN. And you mentioned about ServicePermission check, this means I cannot export a/b@ only and the realm is needed. The latest webrev is at https://cr.openjdk.java.net/~weijun/6722928/webrev.02/ Any other comment? You said you wanted to check the krb5 <-> SPNEGO token translation codes. Thanks, Max [1] https://openjdk.java.net/projects/jdk/12/ > On Dec 7, 2018, at 2:48 AM, Nico Williams wrote: > > On Wed, Dec 05, 2018 at 11:41:44AM +0800, Weijun Wang wrote: >> Java's GSSName::isMN always returns true, therefore to my observation, the >> GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. > > That *would* be a valid design choice (per RFCs 2743 and 2744), but it requires > always calling gss_canonicalize_name() immediately when you gss_import_name() a > string (as opposed to an exported name token). > > However, to do this you have to canonicalize the name for every mechanism > indicated by gss_indicate_mechs()! And then it wouldn't be clear what to > output from toString() when the native provider supports multiple mechanisms, > so I don't recommend this design choice. > > But the JGSS JNI bindings isn't actually doing any of that. > > Instead the JGSS JNI bindings outright lies about the name claiming it's an MN > when it may not be. I'm not sure how much appetite we should have to fix this > sort of buglet, but it should be fixed, really. > > If I'd noticed this buglet a couple of years ago then our contribution would > include a fix for it :( > >> It is only called in export(), where the first call to export_name() might > > (And in getKrbName(), which is used only for JAAS permissions checks.) > >> return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically >> call canonicalize_name() and export_name() again. > > Right. > >> And then, the export format is only useful when importing a NT_EXPORT_NAME. > > The export name is meant for two things: > > - to be able to get a stable token you can store in things like ACLs > > - to be able to memcmp() for name equality, which has different semantics than > gss_compare_name() > >> So, seems like both export_name() and canonicalize_name() are quite useless >> (at least in the view of the native bridge). > > Exported name tokens have uses (see above), and it does work in JGSS. So > exportName is not at all useless. > > canonicalizeName(), however, is pretty useless. Because > gss_canonicalize_name() is pretty useless. > > gss_canonicalize_name() was originally intended so that one could write an > application that takes a user-input principal name, canonicalizes it, exports > it, and stores the exported name token in an ACL. > > The problems with gss_canonicalize_name() are: > > a) It can require credentials in order to talk to a directory, but there's no > input credentials handle argument. > > E.g., given referrals, to properly canonicalize a name with Kerberos > requires doing TGS exchanges, which requires Kerberos client credentials. > > b) A directory may be required for the canonicalization step, but none may be > available. > > E.g., imagine a GSS mechanism that uses PKIX certificates... How would you > resolve a name "nico" of username name-type to something like CN=nico,...? > > For some realms you could have local mapping rules configuration to do that > with, but in the general case you'd need a directory (LDAP, say), and you'd > have to know how to search it for this. There isn't always a directory that > allows these searches, and it's not always the case that certificates issued > by some CA adhere to a rigid naming convention. > > Even if you use various subjectAlternativeName name types, you'd still have > canonicalization issues that might require a directory. > > Oh, and searching any such directory would presumably require credentials; > see (a). > > We've had a few lengthy discussions of this on the KRB-WG and KITTEN mailing > lists. And I suspect if you look you might find discussions of this in the old > CAT WG mailing list from the early- and mid-90s. > > Because of its shortcomings, I'm inclined to not worry too much about > gss_canonicalize_name(), but isMN() *must not* lie, that's for sure, so in the > end I'm inclined to just fix GSSNameElement to know whether a name is an MN, > and to have a proper, public canonicalize() method that calls the native > canonicalizeName() method (and so gss_canonicalize_name()). > > If you do all this then exportName() need not have that fallback code path to > call gss_canonicalize_name(). In principle it's a bug to do that because, > again, if the native GSS provider supports multiple mechanisms, which mechanism > should exportName() pick?! This sort of bug has been papered over by > supporting only Kerberos and SPNEGO, since ultimately that means supporting > only Kerberos. But there are other mechanisms that might be supported. E.g., > MSFT has one called PKU2U that uses PKIX credentials instead of Kerberos, and > Globus has one that uses TLS for the same purpose. > >> What's your ideal output? The toString of canonicalize() and import(export) >> always showing krb5 style and name type being KRB5_NAME? > > In the JNI bindings toString() should always output whatever gss_display_name() > outputs. Full stop. > > The effect of that, if the bindings only call gss_canonicalize_name() when the > Java canonicalize() method is called, would be this: > > - if a name is not an MN, meaning it wasn't output by gss_canonicalize_name(), > gss_accept_sec_context(), gss_inquire_context(), or gss_import_name() of a > GSS_C_NT_EXPORTED_NAME token, then toString() should return the original > name from the gss_import_name() call (the GSSNameElement constructor); > > - otherwise (if a name is an MN), then toString() should return the output of > gss_display_name() as applied to the MN > > If the JNI bindings were to aggressively call gss_canonicalize_name() early, > then you'd have to choose a mechanism whose name display form to output in > toString() (see above). > > Nico > -- From valerie.peng at oracle.com Fri Dec 7 02:52:08 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Dec 2018 18:52:08 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <75F093DA-FA57-4DBC-83A8-3D26E9FE31B5@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <75F093DA-FA57-4DBC-83A8-3D26E9FE31B5@oracle.com> Message-ID: <07a96a28-e9da-9349-46ef-7d53b0ea23b1@oracle.com> Hi, Max, In? my first prototype, I got rid of the Entries classes (for both SUN and SunRsaSign provider) and adds the Services inside the Provider. Later, when I saw VerificationProvider class and its dependency on the Entries class, I have to revert back to the original approach of having the Entries classes. I thought about putting the Entries classes into their provider classes, however, I am not sure if any of our licensee may remove SUN, SunRsaSign provider class which is why we have VerificationProvider. So, I think having separate Entries classes are probably the safest choice. As for creating a HashSet to store the services and then putting them into provider object in individual provider class is to work with the current API of Provider.putService()... If you have better suggestion, I am all ears... Thanks! Valerie On 12/3/2018 7:57 PM, Weijun Wang wrote: > In fact, if the only reason why those Entries classes exist is because of VerificationProvider, can we move the content back into their Provider class as a public static method which is still callable by VerificationProvider? > > ?Max > >> ? 2018?12?4??11:43?Weijun Wang ??? >> >> Hi Valerie >> >> I'm looking at the put->putService changes. Before this, a single put() in SunRsaSignEntries call adds a service but now you need to add() into a LinkedHashSet first in SunRsaSignEntries and then putService() each back in SunRsaSign. >> >> I don't have a simple way to do this since Provider::putService is protected and SunRsaSignEntries is also used in VerificationProvider, just wonder if you have thought about this. >> >> Thanks >> Max >> >>> On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: >>> >>> Hi, >>> >>> Can someone help reviewing this fix? >>> >>> Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >>> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >>> >>> Thanks, >>> Valerie From weijun.wang at oracle.com Fri Dec 7 02:55:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Dec 2018 10:55:48 +0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <07a96a28-e9da-9349-46ef-7d53b0ea23b1@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <75F093DA-FA57-4DBC-83A8-3D26E9FE31B5@oracle.com> <07a96a28-e9da-9349-46ef-7d53b0ea23b1@oracle.com> Message-ID: <5352A26F-D312-4BD4-BC59-C60F1DDDA4C8@oracle.com> > On Dec 7, 2018, at 10:52 AM, Valerie Peng wrote: > > Hi, Max, > > In my first prototype, I got rid of the Entries classes (for both SUN and SunRsaSign provider) and adds the Services inside the Provider. Later, when I saw VerificationProvider class and its dependency on the Entries class, I have to revert back to the original approach of having the Entries classes. I thought about putting the Entries classes into their provider classes, however, I am not sure if any of our licensee may remove SUN, SunRsaSign provider class which is why we have VerificationProvider. So, I think having separate Entries classes are probably the safest choice. As for creating a HashSet to store the services and then putting them into provider object in individual provider class is to work with the current API of Provider.putService()... > > If you have better suggestion, I am all ears... No. See below. > > Thanks! > Valerie > > > On 12/3/2018 7:57 PM, Weijun Wang wrote: >> In fact, if the only reason why those Entries classes exist is because of VerificationProvider, can we move the content back into their Provider class as a public static method which is still callable by VerificationProvider? I wrote this on my cellphone when I'm out, but when I come back and want to try it out, I cannot use Provider as the argument for the proposed static method. So, just keep the current change. Thanks, Max >> >> ?Max >> >>> ? 2018?12?4??11:43?Weijun Wang ??? >>> >>> Hi Valerie >>> >>> I'm looking at the put->putService changes. Before this, a single put() in SunRsaSignEntries call adds a service but now you need to add() into a LinkedHashSet first in SunRsaSignEntries and then putService() each back in SunRsaSign. >>> >>> I don't have a simple way to do this since Provider::putService is protected and SunRsaSignEntries is also used in VerificationProvider, just wonder if you have thought about this. >>> >>> Thanks >>> Max >>> >>>> On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: >>>> >>>> Hi, >>>> >>>> Can someone help reviewing this fix? >>>> >>>> Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From valerie.peng at oracle.com Fri Dec 7 02:58:15 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Dec 2018 18:58:15 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <8C26FDD8-5C81-466D-9A8B-EACCE2E1052F@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <8C26FDD8-5C81-466D-9A8B-EACCE2E1052F@oracle.com> Message-ID: Right, thanks for catching this. Will fix it in next webrev. Valerie On 12/5/2018 7:28 PM, Weijun Wang wrote: > Hi Valerie > > - map.put("CertPathBuilder.PKIX ValidationAlgorithm", > - "RFC5280"); > - map.put("CertPathValidator.PKIX ValidationAlgorithm", > - "RFC5280"); > + attrs.put("PKIX ValidationAlgorithm", "RFC5280"); <<<<<<<<<< !!!! > + add(p, "CertPathBuilder", "PKIX", > + "sun.security.provider.certpath.SunCertPathBuilder", > + null, attrs); > + add(p, "CertPathValidator", "PKIX", > + "sun.security.provider.certpath.PKIXCertPathValidator", > + null, attrs); > > Here, "PKIX" is the algorithm name and not a part of the attribute name. > > Other new aliases and attributes look good. > > Thanks > Max > > >> On Nov 22, 2018, at 2:05 AM, Valerie Peng wrote: >> >> Hi, >> >> Can someone help reviewing this fix? >> >> Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >> >> Thanks, >> Valerie >> >> >> >> >> From valerie.peng at oracle.com Fri Dec 7 03:27:23 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Dec 2018 19:27:23 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> Message-ID: <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> Hi Sean, Thanks for your review, I have removed the stale comment from the VerificationProvider. As for your concern on race condition, legacyChanged and the String/String legacy mapping are still synchronized on the provider object. Only the service mapping is managed by the ConcurrentHashMap. I have also changed serviceChanged to be volatile. For those methods which no longer have synchronized keywords, they still have synchronized blocks around the legacy mapping related code. In general, the provider mappings are populated during construction time and rarely updated afterwards. In addition, most if not all, they either use all legacy or all service. The mixing of them makes the code un-necessarily complicated, oh-well. Latest webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.01 Valerie On 12/4/2018 2:29 PM, Sean Mullan wrote: > I haven't reviewed all of this, but had a couple of comments so far: > > - VerificationProvider.java > > 77???????? // the provider. Otherwise, create a temporary map and use a > > This comment is now stale so it needs to be removed/updated. > > - Provider.java > > You removed synchronized from several of the methods, but some of > those methods modified fields such as servicesChanged and > legacyChanged. Are there any concurrency issues or race conditions now > that those methods are not synchronized? > > --Sean > > > On 11/21/18 1:05 PM, Valerie Peng wrote: >> Hi, >> >> Can someone help reviewing this fix? >> >> Besides changing the Provider class to use ConcurrentHashMap in order >> to reduce the lock contention on Provider.getService() calls, I also >> changed the security providers in java.base module to register >> through putService(...) calls. Performance is manually verified and >> mach5 run is clean. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >> >> Thanks, >> Valerie >> >> >> >> >> From anthony.scarpino at oracle.com Fri Dec 7 06:12:35 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 6 Dec 2018 22:12:35 -0800 Subject: RFR 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: On 11/30/18 12:01 PM, Adam Petcher wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8208698 > webrev: http://cr.openjdk.java.net/~apetcher/8208698/webrev.00/ > > This is a re-implementation of ECDH and ECDSA that is designed to be > resilient against side-channel attacks. The implementation only supports > the 256-bit, 384-bit, and 521-bit NIST curves, and only key pair > generation, key agreement, and signature is implemented. For other > curves/algorithms, the existing native ECC implementation will be used. > This change depends on a separate change (reviewed concurrently) that > enhances the finite field arithmetic library. The implementation is > intended to follow the recommendations in FIPS 186-4 and SP 800-56A. > More information on the techniques used can be found in the JBS ticket. > > There is no new signature verification implementation, because signature > verification typically does not involve secret inputs. If anyone has any > desire for branchless signature verification, please let me know. > > I tested this change by running all the existing regression tests, and > by checking it against some additional test vectors. I've done some > initial benchmarking on two platforms: a Linux VM with a Skylake CPU, > and a Macbook with a Haswell CPU. In general, the performance of the new > implementation is 20-30% faster than the existing native implementation. > Though the performance of the 521-bit curve is actually around 10% > slower on Mac/Haswell. I think this regression is acceptable, because > the 521-bit curve is not used as much as the others, and it is only used > if lower performance is acceptable. I plan to do some additional > benchmarking while the review is in progress. > > This change includes a new (internal) class hierarchy for EC points in > various coordinate systems. It may seem a little over-complicated, since > the only type of point used in the implementation (other than affine) is > ProjectivePoint. But it is common for different curves to use different > coordinate systems, even within the same ECC algorithm/implementation. > The EdDSA prototype also uses these point classes, and it uses extended > homogeneous coordinates, in addition to projective coordinates. > I don't have any code comments to add to your code. It's pretty clean and mostly algorithm code which the known answer tests will do a better job of judging correctness. One comment I did have was if there were any implications from using little endian on sparcv9? This code will never interact with the native ECC code on big endian processors? Did you/can you run sparcv9 regressions tests? Tony From Nico.Williams at twosigma.com Fri Dec 7 07:11:46 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 7 Dec 2018 07:11:46 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> Message-ID: <20181207071146.GF22527@twosigma.com> On Fri, Dec 07, 2018 at 10:45:02AM +0800, Weijun Wang wrote: > Your detailed analysis is very valuable and I've included the whole text into > https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was > complicated at the beginning and I remember I've especially asked you to look > at it in my initial code review request. I think I have a better > understanding now but unfortunately we are not likely to fix the native > library very soon since RDP 1 for JDK 12 is near [1]. If we could apply OOP to a GSSv3 abstract API we'd say that a NAME has a subclass called CANONICAL_NAME. This would allow us to declare that canonicalizing a name and inquiring a securoty context output only CANONICAL_NAMEs. (For those following along, the GSS-API has an "abstract" API defined in RFC 2743, and then bindings for various programming languages. The Java GSSName class is called NAME in the abstract API.) > Let's come back to this bug. Yesterday I sent out a plan (pasted below): OK. > > Since GSSName::isMN is always true, every gss_name_t must be a MN and I > > decide the name to be always krb5 style and the type to be always > > NT_KRB5_NAME. However, somewhere in the JGSS native bridge implementation > > the name and type are cached on the Java side, therefore the result of > > gSSMananger.createName("service at host", NT_HOSTBASED_SERVICE) does have > > toString() being service at host and type being NT_HOSTBASED_SERVICE. When > > canonicalize() is called, even if the GSS-API canonicalize_name() is not > > called a new gss_name_t is created and the Java side cache will be > > recreated, and this time name becomes service/host and type becomes > > NT_KRB5_NAME. > > > > Is this what you like to see? Yes it is! > > As for export(), I can also output a/b at . When the result is imported as a > > NT_EXPORT_NAME, I'll remember to remove the @ at the end. Exported name tokens and the "empty realm" thing don't play well: they won't memcmp() equal to any exported name tokens exported from a name output by gss_accept_sec_context() or gss_inquire_context(). The only way to compare such a name would be to import() it and then use equals(). This is a symptom of gss_canonicalize_name() being a bad interface. In Kerberos the only reliable way to canonicalize a non-MN is to call gss_init_sec_context(), inquire the security context to get the target's canonical name, then throw away the context and initial security token. This trick would not work for PKU2U or the Globus mechanism. Of course, you still need a credential handle to init with, so you'll use the default credential because gss_canonicalize_name() doesn't have an input credential handle :( > > The result is: > > > > GSSManager m = GSSManager.getInstance(); > > GSSName n = m.createName("service at host", GSSName.NT_HOSTBASED_SERVICE); > > // n is now (service at host, NT_HOSTBASED_SERVICE) > > n = n.canonicalize(new Oid("1.2.840.113554.1.2.2")); > > // n is now (service/host, NT_KRB5_NAME) > > byte[] x = n.export(); > > // 0000: 04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 00 ......*.H....... > > // 0010: 00 00 0D 73 65 72 76 69 63 65 2F 68 6F 73 74 40 ...service/host@ > > n = m.createName(x, GSSName.NT_EXPORT_NAME); > > // n is now (service/host, NT_KRB5_NAME) > > I think the result is quite good. It's like the native bridge itself has > stored a non-MN (except that its isMN() is true) although inside the new > library there is only MN. Yes, it's looking good. > And you mentioned about ServicePermission check, this means I cannot export > a/b@ only and the realm is needed. The latest webrev is at At some point we need to talk about revamping ServicePermission. What I'd suggest is that we say that ServicePermission is intended to work with any mechanism that supports GSS_C_NT_USERNAME and GSS_C_NT_HOSTBASED_SERVICE, and any other name type that can be mapped onto Kerberos naming style, and that in ServicePermission names are Kerberos style. We could add a ServicePermission() constructor that takes a GSS name-type Oid and a generic syntax name and then maps to Kerberos style names. And we could add a GSSName and GSSNameSpi methods to get Kerberos-style name forms for any non-Kerberos mechanism. Then we could say that an empty realm in a ServicePermission matches any realm. (Kerberos actually has a notion of X.500-style realm names too, so we could even have that in ServicePermission for any GSS mechanisms that use PKIX.) > https://cr.openjdk.java.net/~weijun/6722928/webrev.02/ > > Any other comment? You said you wanted to check the krb5 <-> SPNEGO > token translation codes. I'll need a bit more time to do a thorough review. Nico -- From mbalao at redhat.com Fri Dec 7 14:17:27 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 7 Dec 2018 11:17:27 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Valerie, On Thu, Dec 6, 2018 at 11:27 PM Valerie Peng wrote: > > I suppose the changes in this update is just the system property > renaming? I looked at the relevant files and they look fine. If you made > more changes than this, please let me know and I will take a closer look > at them. Yes, that's right. No changes other that those related to renaming and documenting the property as requested in the CSR. > > Don't forget to add a release note subtask for JDK-6913047 as it has a > "release-note=yes" label. Will do. > > I will re-run mach5 with this webrev.15 just to be safe. Thanks, Martin.- From weijun.wang at oracle.com Fri Dec 7 15:21:29 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 7 Dec 2018 23:21:29 +0800 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties Message-ID: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8214568/webrev.00 Thanks Max From sean.mullan at oracle.com Fri Dec 7 16:02:38 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Dec 2018 11:02:38 -0500 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs Message-ID: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> Please review this change to Distrust TLS server certificates anchored by Symantec Root CAs. Although the restrictions won't kick in until after 12 GA, the fix touches code that validates certificate chains, so getting this into 12 now will provide more assurance that the chain validation code continues to work properly. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8207258 Please see the recently posted blog for more information about the restrictions that are being imposed: https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates Thanks, Sean From adam.petcher at oracle.com Fri Dec 7 16:53:58 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Dec 2018 11:53:58 -0500 Subject: RFR 8208648: ECC Field Arithmetic Enhancements In-Reply-To: <102ad6c6-30b6-bdb8-9ef4-725315319f79@oracle.com> References: <102ad6c6-30b6-bdb8-9ef4-725315319f79@oracle.com> Message-ID: <95a66d20-b651-bcc5-fa4a-8d8258571d70@oracle.com> Updated webrev: http://cr.openjdk.java.net/~apetcher/8208648/webrev.01/ Thanks for looking at this. See below. On 12/6/2018 8:03 PM, Jamil Nimeh wrote: > Hi Adam, comments/questions below (mostly simple stuff, nothing major): > > * IntegerPolynomial.java > o The comment block for multByInt should reflect your changes > you made, namely the removal of "r" from the signature. > Fixed. > o 88: In the case of multiplying two very large long values > would we ever see those cause an overflow.? If so, is it OK to > have them overflow before the reduce operation? > The potential for overflow is the hardest part of all this, and any overflow will cause serious problems. You can do some calculations to ensure that overflow doesn't happen. For the multiplication, these calculations are pretty simple and can be done manually. For an n-bit representation, each limb has a maximum magnitude of 2^(n + 1) going into the multiplication. If there are k limbs, then the maximum magnitude of any limb after the multiplication is 2^(2n + 2 + log k). There is no overflow during multiplication as long as this maximum is strictly less than 2^63. For example, the P-521 field uses 19 limbs with 28 bits each. So the maximum limb magnitude after multiplication is 2^(2*28 + 2 + log 19) =~ 2^(62.25). Doing these sorts of calculations to ensure that there is no overflow during the carry/reduce sequence is much more tedious. I have a model of this arithmetic that does all this calculation for me, and that is what I used to ensure there is no overflow. Also, the unit test (TestIntegerModuloP.java) does a large number of random operations, and I suspect that it would be very unlikely for an accidental overflow to get past that test. > o > > > o 420-425: Looks like this was a copy of the comment block from > conditionalSwap().? Maybe needs to be tailored to what the > conditionalAssign method does? > Fixed. > > o IntegerPolynomialP256.java, IntegerPolynomialP384.java, > IntegerPolynomialP521.java > + In the carryReduce0 and carryReduce methods, you have many > uses of an integer literal (33554432 for P256, 134217728 > for P384/521).? Should these be made as private static > final long values? > o P256OrderField.java, P384OrderField.java, P521OrderField.java > + Similar question about using a static final long vs. > repeated int literal values in the carryReduce* methods. > o With respect to the last two main bullet items: Would > conversion to a static final value be difficult due to the > fact that they are generated from Fieldgen.jsh? > I changed the literal that was used during the carry operations to a class constant called CARRY_ADD, and made it more clear what it is (it is 1 << n for some n). The only literals remaining are the coefficients that are used in reduction. Making these constants is a bit more complicated, because there are several cases to consider, and there are optimizations for each of these cases to make the code more clear. For example, if the coefficient is 1, then don't bother multiplying by it. I can make these class constants, too, but I'm not sure it is worth the trouble. Let me know what you think. Changing the generator to produce better generated code is no problem, so please let me know if you find more opportunities to make this code more clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Fri Dec 7 16:59:02 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Dec 2018 11:59:02 -0500 Subject: RFR 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: <82d3d5b8-5287-4eec-d9b2-17eeeeb5e11a@oracle.com> On 12/7/2018 1:12 AM, Anthony Scarpino wrote: > I don't have any code comments to add to your code. It's pretty clean > and mostly algorithm code which the known answer tests will do a > better job of judging correctness. > > One comment I did have was if there were any implications from using > little endian on sparcv9?? This code will never interact with the > native ECC code on big endian processors?? Did you/can you run sparcv9 > regressions tests? I wouldn't expect any byte order issues, since there is no interaction with native code, direct byte buffers, etc. I ran regression tests (including ECC KATs) on sparcv9, and I didn't get any failures. This new implementation is not used by default on Solaris due to the provider order---I changed the provider order during this test to make sure I was actually testing the SunEC implementation. > > Tony From ecki at zusammenkunft.net Fri Dec 7 18:19:32 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 7 Dec 2018 18:19:32 +0000 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> Message-ID: Woha, having a specific property named after an brand looks awfully specific and even hostile. (Yes it can be removed in a future version when all existing certs are expected to expire, but having code patches distributed for such policy enforcement does look like a heavy gun) Won?t it be a bettter idea to have a generic blacklist framework (with thumbrint and forced end date), maybe even by using WebStart blacklist technology? (Or just put the list with new syntax in the algorithm restriction properties - the list is long but if it?s limited to the thumbprints it should be doable) Also, since this (without OCSP stapling or CT) somewhat trust symantec to not backdate issuances, why not trust them to not issue new ones? Just wait for a few more month and remove them completely from the cacerts file. (After all, this is not a Web Browser) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Sean Mullan Gesendet: Freitag, Dezember 7, 2018 7:03 PM An: security Dev OpenJDK Betreff: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs Please review this change to Distrust TLS server certificates anchored by Symantec Root CAs. Although the restrictions won't kick in until after 12 GA, the fix touches code that validates certificate chains, so getting this into 12 now will provide more assurance that the chain validation code continues to work properly. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8207258 Please see the recently posted blog for more information about the restrictions that are being imposed: https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Fri Dec 7 18:31:53 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 7 Dec 2018 10:31:53 -0800 Subject: RFR 8208648: ECC Field Arithmetic Enhancements In-Reply-To: <95a66d20-b651-bcc5-fa4a-8d8258571d70@oracle.com> References: <102ad6c6-30b6-bdb8-9ef4-725315319f79@oracle.com> <95a66d20-b651-bcc5-fa4a-8d8258571d70@oracle.com> Message-ID: <42484fa9-347c-b7c5-0ccc-76cc8721c8d2@oracle.com> Hi Adam, The changes look good.? With respect to the other coefficients, I agree with you that it's probably not worth the trouble to make them into constants.? It was just that one specific literal value in each file that jumped out at me.? Thanks also for the overflow explanation.? I would agree that given the extent to which you are exercising that code there would be some evidence if an overflow was causing issues. --Jamil On 12/7/2018 8:53 AM, Adam Petcher wrote: > > Updated webrev: http://cr.openjdk.java.net/~apetcher/8208648/webrev.01/ > > Thanks for looking at this. See below. > > On 12/6/2018 8:03 PM, Jamil Nimeh wrote: >> Hi Adam, comments/questions below (mostly simple stuff, nothing major): >> >> * IntegerPolynomial.java >> o The comment block for multByInt should reflect your changes >> you made, namely the removal of "r" from the signature. >> > Fixed. > >> o 88: In the case of multiplying two very large long values >> would we ever see those cause an overflow.? If so, is it OK >> to have them overflow before the reduce operation? >> > The potential for overflow is the hardest part of all this, and any > overflow will cause serious problems. You can do some calculations to > ensure that overflow doesn't happen. For the multiplication, these > calculations are pretty simple and can be done manually. For an n-bit > representation, each limb has a maximum magnitude of 2^(n + 1) going > into the multiplication. If there are k limbs, then the maximum > magnitude of any limb after the multiplication is 2^(2n + 2 + log k). > There is no overflow during multiplication as long as this maximum is > strictly less than 2^63. For example, the P-521 field uses 19 limbs > with 28 bits each. So the maximum limb magnitude after multiplication > is 2^(2*28 + 2 + log 19) =~ 2^(62.25). > > Doing these sorts of calculations to ensure that there is no overflow > during the carry/reduce sequence is much more tedious. I have a model > of this arithmetic that does all this calculation for me, and that is > what I used to ensure there is no overflow. Also, the unit test > (TestIntegerModuloP.java) does a large number of random operations, > and I suspect that it would be very unlikely for an accidental > overflow to get past that test. > >> o >> >> >> o 420-425: Looks like this was a copy of the comment block from >> conditionalSwap().? Maybe needs to be tailored to what the >> conditionalAssign method does? >> > Fixed. >> >> o IntegerPolynomialP256.java, IntegerPolynomialP384.java, >> IntegerPolynomialP521.java >> + In the carryReduce0 and carryReduce methods, you have >> many uses of an integer literal (33554432 for P256, >> 134217728 for P384/521).? Should these be made as private >> static final long values? >> o P256OrderField.java, P384OrderField.java, P521OrderField.java >> + Similar question about using a static final long vs. >> repeated int literal values in the carryReduce* methods. >> o With respect to the last two main bullet items: Would >> conversion to a static final value be difficult due to the >> fact that they are generated from Fieldgen.jsh? >> > I changed the literal that was used during the carry operations to a > class constant called CARRY_ADD, and made it more clear what it is (it > is 1 << n for some n). The only literals remaining are the > coefficients that are used in reduction. Making these constants is a > bit more complicated, because there are several cases to consider, and > there are optimizations for each of these cases to make the code more > clear. For example, if the coefficient is 1, then don't bother > multiplying by it. I can make these class constants, too, but I'm not > sure it is worth the trouble. Let me know what you think. > > Changing the generator to produce better generated code is no problem, > so please let me know if you find more opportunities to make this code > more clear. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Dec 7 19:02:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Dec 2018 14:02:13 -0500 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> Message-ID: <03c2cb7f-6c14-2fc6-407f-a5a74e2fbe5b@oracle.com> On 12/7/18 1:19 PM, Bernd Eckenfels wrote: > Woha, having a specific property named after an brand looks awfully > specific and even hostile. (Yes it can be removed in a future version > when all existing certs are expected to expire, but having code patches > distributed for such policy enforcement does look like a heavy gun) The property itself is named "jdk.security.caDistrustPolicies", so there is no brand information in the name. I guess you are referring to the name of the policy id that it can be set to: "SYMANTEC_TLS"? This is a JDK-specific property, so other SE implementations do not have to support it. Also, the root certificates are now part of OpenJDK. We should be able to implement controls which ensure they conform to acceptable industry standards, and if that means revealing the name of the CA, I don't see that as a problem. > Won?t it be a bettter idea to have a generic blacklist framework (with > thumbrint and forced end date), maybe even by using WebStart blacklist > technology? (Or just put the list with new syntax in the algorithm > restriction properties - the list is long but if it?s limited to the > thumbprints it should be doable) We did consider the existing blacklist framework. However, that is currently too coarse. It is all-or-nothing. If a certificate chain contains a blacklisted certificate, it is rejected regardless of the usage (TLS, code signing, etc) or other constraints (notBefore, notAfter dates). It would have been a much bigger effort to enhance the blacklist mechanism to support those features. Another solution I considered was to tag the roots in the cacerts keystore with various attributes, but the cacerts keystore is currently in JKS format, which does not support attributes. > Also, since this (without OCSP stapling or CT) ?somewhat trust symantec > to not backdate issuances, why not trust them to not issue new ones? > Just wait for a few more month and remove them completely from the > cacerts file. (After all, this is not a Web Browser) We may do that eventually, but if we unilaterally removed the roots, there is a significant risk that we would break existing code that has been signed with Symantec issued code signing certificates, especially with code that has also been timestamped. That code is expected to work beyond the lifetime of the certificate. Thanks, Sean > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Sean Mullan > *Gesendet:* Freitag, Dezember 7, 2018 7:03 PM > *An:* security Dev OpenJDK > *Betreff:* RFR (12): 8207258: Distrust TLS server certificates anchored > by Symantec Root CAs > Please review this change to Distrust TLS server certificates anchored > by Symantec Root CAs. Although the restrictions won't kick in until > after 12 GA, the fix touches code that validates certificate chains, so > getting this into 12 now will provide more assurance that the chain > validation code continues to work properly. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ > issue: https://bugs.openjdk.java.net/browse/JDK-8207258 > > Please see the recently posted blog for more information about the > restrictions that are being imposed: > https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates > > > Thanks, > Sean From ecki at zusammenkunft.net Fri Dec 7 19:16:21 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 7 Dec 2018 19:16:21 +0000 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: <03c2cb7f-6c14-2fc6-407f-a5a74e2fbe5b@oracle.com> References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> , <03c2cb7f-6c14-2fc6-407f-a5a74e2fbe5b@oracle.com> Message-ID: Actually I was referring to the property name in the issue, did not notice that the description differs from the patch, sorry. Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Dec 7 19:20:27 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Dec 2018 14:20:27 -0500 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> <03c2cb7f-6c14-2fc6-407f-a5a74e2fbe5b@oracle.com> Message-ID: On 12/7/18 2:16 PM, Bernd Eckenfels wrote: > Actually I was referring to the property name in the issue, did not > notice that the description differs from the patch, sorry. Ah, sorry about that, that was old information, I need to update the JBS issue ... will do that. --Sean > > Gruss > Bernd > -- > http://bernd.eckenfels.net From valerie.peng at oracle.com Fri Dec 7 21:10:33 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 7 Dec 2018 13:10:33 -0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com> <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com> <741f46e0-df55-e5da-6a89-f8e40d5a0c4c@oracle.com> Message-ID: <22d382bf-93ec-48e5-9721-c02fc1d49166@oracle.com> Sure, sounds good~ Valerie On 12/6/2018 4:24 PM, Weijun Wang wrote: > Hi Valerie, > > I'll fix it in my local repo, run some test, and push the changeset. > > Thanks, > Max > >> On Dec 7, 2018, at 6:58 AM, Valerie Peng wrote: >> >> Hi, Max, >> >> CSignature.java: one last nit, line 98 and 102 can be replaced by just one line outside the if-block. >> >> Thanks, >> >> Valerie >> >> On 12/6/2018 6:33 AM, Weijun Wang wrote: >>> Webrev updated at >>> >>> https://cr.openjdk.java.net/~weijun/8213009/webrev.03 >>> >>> I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key instanceof RSAPublicKey" in RSA::engineInitVerify. >>> >>> Thanks >>> Max >>> >>>> On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Nov 27, 2018, at 9:55 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> Please find comments in line. >>>>> On 11/22/2018 6:04 AM, Weijun Wang wrote: >>>>>>> On Nov 22, 2018, at 9:14 AM, Valerie Peng >>>>>>> wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Here are some comments: >>>>>>> >>>>>>> >>>>>>> - line 39, add PSS here as well. >>>>>>> - line 97, CSignature ctr, better to initialize all fields >>>>>>> >>>>>> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. >>>>>> >>>>> I was referring messageDigest/messageDigestAlgorithm/needsReset. My general preference is to set them to null/false even when not used, may help catch future coding problems. >>>> OK. >>>> >>>>>>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 >>>>>>> >>>>>> Can I do this later? This sub-task is meant to be a cleanup. >>>>> My point for checking the key algorithm is to ensure that the specified key object is RSA type. After this cleanup and refactoring, the specified key should be checked to be of RSA type, i.e. line 111, 130. Otherwise, the casting to various RSA public/private key interfaces, e.g. java.security.interfaces.RSAPublicKey, may fail. >>>> OK, I can check for RSAPublicKey. >>>> >>>> On the other hand, if I create a subclass for CRSAPrivateKey, its getModulus() and getPrivateExponent() can only throw out a ProviderException if the key is unextractable, and this breaks some existing code inside JDK. >>>> >>>> Thanks >>>> Max >>>> >>>>> Updates look fine. >>>>> >>>>> Regards, >>>>> >>>>> Valerie >>>>> >>>>>> But I think I need to move more RSA related methods into the RSA subclass. >>>>>> >>>>>> >>>>>>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" >>>>>>> >>>>>> OK. >>>>>> >>>>>> >>>>>>> - line 681: can be static, right? pkg-private? >>>>>>> >>>>>> Yes. Looks like it can be private. >>>>>> >>>>>> >>>>>>> >>>>>>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. >>>>>>> >>>>>> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. >>>>>> >>>>>> >>>>>>> - line 127, add @Override >>>>>>> >>>>>> OK. >>>>>> >>>>>> >>>>>>> - line 140, must getPublicKeyBob be public? Maybe pkg private? >>>>>>> >>>>>> Correct. >>>>>> >>>>>> >>>>>>> >>>>>>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. >>>>>>> >>>>>> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. >>>>>> >>>>>> >>>>>>> >>>>>>> - would be nice to have a String constant for "RSA". >>>>>>> >>>>>> Sure. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> Rest looks fine. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> >>>>>>> On 11/15/2018 7:40 AM, Weijun Wang wrote: >>>>>>> >>>>>>>> Oops, my copy/paste sequence goes wrong. >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Webrev updated at >>>>>>>>> >>>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> More refactorings: >>>>>>>>> >>>>>>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>>>>>>>> >>>>>>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>>>>>>>> >>>>>>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>>>>>>>> >>>>>>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Webrev updated at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The subtask id is now used. >>>>>>>>>> >>>>>>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Please review the change at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>>>>>>>> >>>>>>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>>>>>>>> >>>>>>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>>>>>>>> >>>>>>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>>>>>>>> >>>>>>>>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>>>>>>>> >>>>>>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>>>>>>>> >>>>>>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>>>>>>>> >>>>>>>>>>> Noreg-cleanup. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From sean.mullan at oracle.com Fri Dec 7 22:06:22 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Dec 2018 17:06:22 -0500 Subject: Fwd: My current jdk12 changes In-Reply-To: <241E9CD7-937F-4A77-8621-DDE5E399A3DE@oracle.com> References: <241E9CD7-937F-4A77-8621-DDE5E399A3DE@oracle.com> Message-ID: <6fd4c1d4-cef2-6fe5-c383-68eb834390f8@oracle.com> On 12/6/18 8:27 AM, Weijun Wang wrote: > Hi All > > Currently, I have 4 code changes out for review and I wish they can make JDK 12 (RDP1 is 12/13) > > 8076190: Customizing the generation of a PKCS12 keystore > https://cr.openjdk.java.net/~weijun/8076190/webrev.05/ * java.security 1124 # file. This can be any HmacPBE algorithm defined in the Mac section of the 1125 # Java Security Standard Algorithm Names Specification. When set to "NONE", 1126 # no Mac is generated. The default value is "HmacPBESHA1". These "HmacPBE" algorithms are not defined in the Standard Algorithm Names Specification. Make sure you file a follow-on bug to add them, if you don't fix it as part of this. 1073 # parameter used to generate the existing Mac will be reused. If the existing Should that be "parameters"? 1085 # "keystore.pkcs12.keyPbeIterationCount" values define here. Typo: defined 1123 # The algorithm used to calculated the optional MacData at the end of a PKCS12 Typo: calculate * PKCS12KeyStore.java 84 * Currently these PBE algorithms are used by default: 85 * - pbeWithSHAAnd3KeyTripleDESCBC to encrypt private keys 86 * - pbeWithSHAAnd40BitRC2CBC to encrypt certificates I'd use the standard names here: PBEWithSHA1AndDESede, PBEWithSHA1AndRC2_40. Also, can you add the default Mac algorithm? 221 int number = Integer.parseInt(result); I suggest catching NumberFormatException and throwing a more informative exception such as on lines 223-224. Also, you may want to parse the String into an int later, when (or if) the properties are used. That would be more consistent with what the definitions in java.security says about the properties. 936 * EncryptedPrivateKeyInfo extra space before "*". 2020 certProtectionAlgorithm = CERT_PROTECTION_ALGORITHM; 2021 certPbeIterationCount = CERT_PBE_ITERATION_COUNT; 2022 macAlgorithm = MAC_ALGORITHM; These algorithms could be set to "". Is that ok, are they rejected cleanly at some later point? --Sean From anthony.scarpino at oracle.com Fri Dec 7 23:07:47 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 7 Dec 2018 15:07:47 -0800 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <6563F381B547594081EF9DE181D0791288A23A16@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com> <9dcb8b6f-49d9-be5f-9787-882707ace176@oracle.com> <6563F381B547594081EF9DE181D0791288A23A16@FMSMSX119.amr.corp.intel.com> Message-ID: Hi Smita, I ran into a tag mismatch with the com/sun/crypto/provider/Cipher/AEAD/Encrypt.java test on windows-x64. It did not fail on linux, so I suppose its a windows register issue. I'm going to try to add what is done in the other ghash intrinsic for windows platforms. You might want to look at that too. Tony On 12/6/18 11:19 AM, Kamath, Smita wrote: > Hi Tony, > > I have updated my code to address the performance regression in smaller data sizes. > Please find the updated webrev and JBS link attached. > > JBS link: https://bugs.openjdk.java.net/browse/JDK-8214074 > Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev02/ > > Thank you very much for your time and assistance. Please let me know if you have any questions. > > Regards, > Smita > > -----Original Message----- > From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] > Sent: Wednesday, December 5, 2018 10:56 AM > To: Kamath, Smita ; 'Vladimir Kozlov' > Cc: Viswanathan, Sandhya ; OpenJDK Security ; hotspot compiler > Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions > > Smita, > > I did some performance testing on the changes and noticed that while the larger data sizes perform better, there is a drop in the smaller data sizes. 16byte data sizes saw a drop from 2.4m ops/sec to 1.7m ops/sec and 64bytes dropped from 2.1m ops/sec to 1.5m ops/sec. At 256 bytes it is roughly equal. At 16k is the best performance increase from 60k ops/sec to 130 ops/sec > > Are the AVX instructions slower to setup and therefore affect smaller data sizes? Or maybe the larger array allocation in GHASH.java? > > Tony > > On 11/29/18 12:08 PM, Anthony Scarpino wrote: >> [removed core-libs, added security-dev] >> >> I'm fine with the jdk changes and solaris-sparc appears to work fine >> with the existing security and intrinsic tests.? I do not feel >> comfortable reviewing the hotspot changes, so either Vladimir or >> someone else from the hotspot team would need to look at it. >> >> Tony >> >> On 11/20/18 6:45 PM, Kamath, Smita wrote: >>> Hi Tony, >>> >>> Thanks for your comments. >>> >>> 1)? This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? It may work as the code is now since the sparc intrinsic >>> will only use the first two longs in the subkeyHtbl. >>> Would it be possible to help with this sanity check?? I don't have >>> the required set-up to test this scenario. >>> >>> 2) I have changed the code so that subkeyH corresponds to the first >>> two entries of subkeyHtbl.? Please find the updated webrev link. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >>> >>> Thanks and Regards, >>> Smita >>> >>> >>> >>> -----Original Message----- >>> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >>> Sent: Tuesday, November 20, 2018 2:05 PM >>> To: Kamath, Smita ; 'Vladimir Kozlov' >>> >>> Cc: Viswanathan, Sandhya ; >>> core-libs-dev at openjdk.java.net; hotspot compiler >>> >>> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX >>> instructions >>> >>> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>>> Instructions. I have tested this optimization on SKX x86_64 platform >>>> and it shows ~20-30% performance improvement for larger message >>>> sizes (for example 8k). >>>> >>>> I, smita.kamath at intel.com , Shay >>>> Gueuron, (shay.gueron at intel.com )and >>>> Regev Shemy (regev.shemy at intel.com ) >>>> are contributors to this code. >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>>> >>>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>>> >>>> For testing the implementation, I have executed TestAESMain.java. I >>>> have executed Jtreg tests and tested this code on 64 bit Windows and >>>> Linux platforms. >>>> >>>> Please review and let me know if you have any comments. >>>> >>>> Thanks and Regards, >>>> >>>> Smita >>>> >>> >>> Hi, >>> >>> This intrinsic is also used with solaris-sparc, has there been a >>> sanity check by anyone to make sure this does not break the sparc >>> intrinsic? >>> It may work as the code is now since the sparc intrinsic will only >>> use the first two longs in the subkeyHtbl. >>> >>> In that same idea, have you consider combining the subkeyH to be the >>> first two of subkeyHtbl for the non-avx operations?? It would >>> eliminate an extra two longs per instance. >>> >>> Tony >>> >> > From smita.kamath at intel.com Thu Dec 6 19:19:00 2018 From: smita.kamath at intel.com (Kamath, Smita) Date: Thu, 6 Dec 2018 19:19:00 +0000 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <9dcb8b6f-49d9-be5f-9787-882707ace176@oracle.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com> <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com> <9dcb8b6f-49d9-be5f-9787-882707ace176@oracle.com> Message-ID: <6563F381B547594081EF9DE181D0791288A23A16@FMSMSX119.amr.corp.intel.com> Hi Tony, I have updated my code to address the performance regression in smaller data sizes. Please find the updated webrev and JBS link attached. JBS link: https://bugs.openjdk.java.net/browse/JDK-8214074 Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev02/ Thank you very much for your time and assistance. Please let me know if you have any questions. Regards, Smita -----Original Message----- From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] Sent: Wednesday, December 5, 2018 10:56 AM To: Kamath, Smita ; 'Vladimir Kozlov' Cc: Viswanathan, Sandhya ; OpenJDK Security ; hotspot compiler Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions Smita, I did some performance testing on the changes and noticed that while the larger data sizes perform better, there is a drop in the smaller data sizes. 16byte data sizes saw a drop from 2.4m ops/sec to 1.7m ops/sec and 64bytes dropped from 2.1m ops/sec to 1.5m ops/sec. At 256 bytes it is roughly equal. At 16k is the best performance increase from 60k ops/sec to 130 ops/sec Are the AVX instructions slower to setup and therefore affect smaller data sizes? Or maybe the larger array allocation in GHASH.java? Tony On 11/29/18 12:08 PM, Anthony Scarpino wrote: > [removed core-libs, added security-dev] > > I'm fine with the jdk changes and solaris-sparc appears to work fine > with the existing security and intrinsic tests.? I do not feel > comfortable reviewing the hotspot changes, so either Vladimir or > someone else from the hotspot team would need to look at it. > > Tony > > On 11/20/18 6:45 PM, Kamath, Smita wrote: >> Hi Tony, >> >> Thanks for your comments. >> >> 1)? This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? It may work as the code is now since the sparc intrinsic >> will only use the first two longs in the subkeyHtbl. >> Would it be possible to help with this sanity check?? I don't have >> the required set-up to test this scenario. >> >> 2) I have changed the code so that subkeyH corresponds to the first >> two entries of subkeyHtbl.? Please find the updated webrev link. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074 >> >> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/ >> >> Thanks and Regards, >> Smita >> >> >> >> -----Original Message----- >> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com] >> Sent: Tuesday, November 20, 2018 2:05 PM >> To: Kamath, Smita ; 'Vladimir Kozlov' >> >> Cc: Viswanathan, Sandhya ; >> core-libs-dev at openjdk.java.net; hotspot compiler >> >> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX >> instructions >> >> On 11/19/18 12:50 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I'd like to contribute an optimization for GHASH Algorithm using AVX >>> Instructions. I have tested this optimization on SKX x86_64 platform >>> and it shows ~20-30% performance improvement for larger message >>> sizes (for example 8k). >>> >>> I, smita.kamath at intel.com , Shay >>> Gueuron, (shay.gueron at intel.com )and >>> Regev Shemy (regev.shemy at intel.com ) >>> are contributors to this code. >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 >>> >>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ >>> >>> For testing the implementation, I have executed TestAESMain.java. I >>> have executed Jtreg tests and tested this code on 64 bit Windows and >>> Linux platforms. >>> >>> Please review and let me know if you have any comments. >>> >>> Thanks and Regards, >>> >>> Smita >>> >> >> Hi, >> >> This intrinsic is also used with solaris-sparc, has there been a >> sanity check by anyone to make sure this does not break the sparc >> intrinsic? >> It may work as the code is now since the sparc intrinsic will only >> use the first two longs in the subkeyHtbl. >> >> In that same idea, have you consider combining the subkeyH to be the >> first two of subkeyHtbl for the non-avx operations?? It would >> eliminate an extra two longs per instance. >> >> Tony >> > From weijun.wang at oracle.com Sun Dec 9 14:22:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 9 Dec 2018 22:22:09 +0800 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> Message-ID: <2C1570CF-1A9C-49C5-9C9F-5671C39ADC7A@oracle.com> Hi Sean, CADistrustPolicy.java: 80 String[] policies = (property != null) ? property.split(",") : null; 81 EnumSet set = EnumSet.noneOf(CADistrustPolicy.class); 82 for (String policy : policies) { If the property is not defined, the last line above would throw an NPE. test/Distrust.java: 118 private static final Date APRIL_17_2019 = 119 Date.from(LocalDate.of(2019, 4, 17) 120 .atStartOfDay(ZoneId.systemDefault()) 121 .toInstant()); Should UTC be used? 144 testTM(getTMF("PKIX", getParams(VERISIGN_UNIVERSAL_ROOTCA)), 145 loadCertificateChain("verisignuniversalrootca"), !distrust); What's the purpose of the above test? To make sure that even if one day we removed these root CAs from cacerts then the mechanism still works as expected? 191 X509Certificate tlsServerCert = chain[0]; 192 chain[0] = new DistrustedTLSServerCert(tlsServerCert, APRIL_17_2019); Is it necessary to introduce a local variable? No other comment. Thanks, Max > On Dec 8, 2018, at 12:02 AM, Sean Mullan wrote: > > Please review this change to Distrust TLS server certificates anchored by Symantec Root CAs. Although the restrictions won't kick in until after 12 GA, the fix touches code that validates certificate chains, so getting this into 12 now will provide more assurance that the chain validation code continues to work properly. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ > issue: https://bugs.openjdk.java.net/browse/JDK-8207258 > > Please see the recently posted blog for more information about the restrictions that are being imposed: https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates > > Thanks, > Sean From gg5070 at gmail.com Mon Dec 10 13:47:53 2018 From: gg5070 at gmail.com (Gidon Gershinsky) Date: Mon, 10 Dec 2018 15:47:53 +0200 Subject: Problems with AES-GCM native acceleration In-Reply-To: References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> Message-ID: I've run my decryption benchmarks on Java with this patch, with excellent results. The benchmarks reach the top speed right away, no long warm-up anymore. Also, there is no need to split the operation into multiple updates, the doFinal works just fine. Moreover, the maximal decryption throughput is actually higher than in Java11 after warm-up. On one thread, I get 930MB/sec instead of 850MB/s. On 8 threads, 350x8 instead of 230x8. This capability will be important in the Spark/Parquet workloads. Cheers, Gidon On Fri, Nov 30, 2018 at 6:10 PM Andrew Haley wrote: > On 11/21/18 5:37 PM, Andrew Haley wrote: > > On 11/15/18 10:42 AM, Gidon Gershinsky wrote: > >> Having the decryption optimized in the HotSpot engine would be ideal. > > > > I agree with you. I did a few experiments, and it can take a very > > long time for C2 compilation to kick in, especially because GCM is > > glacially slow until the intrinsics are used. > > > > I think this would be a generally useful enhancement to HotSpot, > > and I'm kicking around an experimental patch which adds the > > intrinsics to c1 and the interpreter. > > There's a proof-of-concept patch at http://cr.openjdk.java.net/~aph/gctr/ > It's all rather hacky but it works. > > The patch is rather more complicated than I would have liked. We > could simplify it somewhat by getting rid of the C1 intrinsic, and > instead making C1 call the interpreter implementation. > > There also a jmh benchmark in that directory. Test results for 1Mb > look like this: > > Interp: > > Benchmark Mode Cnt Score Error Units > AESGCMUpdateAAD2.test avgt 5 1426.275 ? 8.778 us/op > > C1: > > Benchmark Mode Cnt Score Error Units > AESGCMUpdateAAD2.test avgt 5 1359.367 ? 8.196 us/op > > C2: > > Benchmark Mode Cnt Score Error Units > AESGCMUpdateAAD2.test avgt 5 1333.863 ? 18.385 us/op > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Mon Dec 10 15:39:55 2018 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Dec 2018 12:39:55 -0300 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) Message-ID: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> Hi, I'd like to propose an implementation of Kerberos cross-realm referrals for OpenJDK's client, according to RFC 6806 [1]. Request for Enhancement: "JDK-8215032 - Support Kerberos cross-realm referrals (RFC 6806)" [2]. Related tickets: "JDK-6631053 - Support canonicalize in Kerberos configuration file" [3] and "JDK-8005819 - Support cross-realm MSSFU" [4]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00/ * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00.zip Implementation notes: * System properties introduced: * sun.security.krb5.disableReferrals: disable this feature * sun.security.krb5.maxReferrals: max referral hops for both client and server referrals (5 by default, as suggested by RFC 6806) * CSR will be needed * NT-ENTERPRISE principals * Supported * Krb5LoginModule has not been extended to use it. However, I'm open to discuss this API first and propose an implementation then -either in the context of this enhancement or in a new one-. * Client referrals * Supported * Client announces support setting CANONICALIZE flag * Fallback: if a failure occurs, client retries without CANONICALIZE flag * Server referrals * Supported * Client announces support setting CANONICALIZE flag * Fallback: if a failure occurs, client retries without CANONICALIZE flag * FAST * RFC 6806 - Section 11 FAST scheme supported * Complete FAST support (RFC 6113) is out of scope * RFC 6806 - Section 11 FAST is mandatory for AS-REQ, and optional for TGS-REQ. Client does not ask for it in TGS requests -sending PA-REQ-ENC-PA-REP PA data- for compatibility reasons. Some servers do not support PA-REQ-ENC-PA-REP in TGS requests and if no checksum is available in TGS responses (even though ENC_PA_REP flag is set), no enforcement is possible. * MIT's client does not send PA-REQ-ENC-PA-REP requests for TGS, only for TGTs [5] * MIT's client only verifies PA-REQ-ENC-PA-REP for TGTs [6] * MIT's KDC supports PA-REQ-ENC-PA-REP in TGT [7] and TGS [8] replies, but Microsoft's Active Directory 2016 does not apparently. * Cache * If a referral loop is introduced when adding a new entry to the cache, we break the loop by invalidating the "next" entry * Adding an entry to the cache may override a previous one * The assumption is that newer information is more accurate * For a given Principal Name, there can only be one "Realm -> Next Realm" referral entry (whose lifetime is given by the referral krbtgt ticket) * Security * Client name changes are allowed in AS-REPs only if: * Client sent CANONICALIZE * Server supports RFC 6806 - Section 11 FAST * Authenticated checksum is correct * Server name changes are allowed in TGS-REPs only if: * Client sent CANONICALIZE * It's for a referral (sname = krbtgt/TO-REALM.COM at FROM-REALM.COM) * Testing * KDC used for testing purposes was extended to include basic support of RFC 6806 server-side * NT-ENTERPRISE principals * Client referrals * Server referrlas * FAST - Section 11 scheme * ReferralsTest functional test added * Client referral with NT-ENTERPRISE principal * Server referral Regressing testing: * No regressions found in jdk/sun/security/krb5 category. * Test results: passed: 128 I'd be grateful if someone can have a look. Kind regards, Martin.- -- [1] - https://tools.ietf.org/html/rfc6806.html [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 [3] - https://bugs.openjdk.java.net/browse/JDK-6631053 [4] - https://bugs.openjdk.java.net/browse/JDK-8005819 [5] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1421 [6] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1665 [7] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_as_req.c#L326 [8] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_tgs_req.c#L724 From aph at redhat.com Mon Dec 10 16:15:21 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Dec 2018 16:15:21 +0000 Subject: Problems with AES-GCM native acceleration In-Reply-To: References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> Message-ID: <737aad13-273a-4295-e835-da766e004a93@redhat.com> On 12/10/18 1:47 PM, Gidon Gershinsky wrote: > I've run my decryption benchmarks on Java with this patch, with excellent > results. > The benchmarks reach the top speed right away, no long warm-up anymore. > Also, there is no need to split the operation into multiple updates, the > doFinal works just fine. > > Moreover, the maximal decryption throughput is actually higher than in > Java11 after warm-up. > On one thread, I get 930MB/sec instead of 850MB/s. > On 8 threads, 350x8 instead of 230x8. > > This capability will be important in the Spark/Parquet workloads. The downloadable binary build is at https://aph.fedorapeople.org/jdk-12-internal+0-adhoc.aph.jdk-jdk.tar.gz -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jamil.j.nimeh at oracle.com Mon Dec 10 18:10:29 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 10 Dec 2018 10:10:29 -0800 Subject: RFR 8214688: TLS 1.3 session resumption with hello retry request failed with "illegal_parameter" In-Reply-To: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> References: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> Message-ID: <3813d98b-dba4-93ea-13af-f129be9832b1@oracle.com> Looks good to me. --Jamil On 12/6/2018 12:14 PM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8214688/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8214688 > > The last session resumption bug fix[1] I made introduced a new issue > when the server sends a HelloRetryRequest message. The proposed fix is > pretty simple: when the client selects a ticket ID to use, it stores > the ID in its context so it can find it again when it sends the second > ClientHello message. We don't have regression tests for > HelloRetryRequest, but I did more interop testing this time to try to > prevent additional issues like this. > > [1] https://bugs.openjdk.java.net/browse/JDK-8213202 > > From sean.mullan at oracle.com Mon Dec 10 19:20:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Dec 2018 14:20:54 -0500 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: <2C1570CF-1A9C-49C5-9C9F-5671C39ADC7A@oracle.com> References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> <2C1570CF-1A9C-49C5-9C9F-5671C39ADC7A@oracle.com> Message-ID: <18bb6005-8c01-b36c-63c9-1cd0f9cd5fe4@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.02/ Specific comments below ... On 12/9/18 9:22 AM, Weijun Wang wrote: > Hi Sean, > > CADistrustPolicy.java: > > 80 String[] policies = (property != null) ? property.split(",") : null; > 81 EnumSet set = EnumSet.noneOf(CADistrustPolicy.class); > 82 for (String policy : policies) { > > If the property is not defined, the last line above would throw an NPE. Good catch. > test/Distrust.java: > > 118 private static final Date APRIL_17_2019 = > 119 Date.from(LocalDate.of(2019, 4, 17) > 120 .atStartOfDay(ZoneId.systemDefault()) > 121 .toInstant()); > > Should UTC be used? Yes, fixed. > 144 testTM(getTMF("PKIX", getParams(VERISIGN_UNIVERSAL_ROOTCA)), > 145 loadCertificateChain("verisignuniversalrootca"), !distrust); > > What's the purpose of the above test? To make sure that even if one day we removed these root CAs from cacerts then the mechanism still works as expected? No, it is simply to test the use case where an application passes its own PKIXBuilderParameters into a TrustManager. However, it is better to just pass in the cacerts KeyStore in that case to the PKIXBuilderParameters constructor. So, I have modified the test accordingly. I also created a new SecurityUtils class in the test library area and added a utility method for returning the cacerts KeyStore. We can change other tests over time to use this new utility method. > > 191 X509Certificate tlsServerCert = chain[0]; > 192 chain[0] = new DistrustedTLSServerCert(tlsServerCert, APRIL_17_2019); > > Is it necessary to introduce a local variable? No, fixed. Thanks, Sean > > No other comment. > > Thanks, > Max > >> On Dec 8, 2018, at 12:02 AM, Sean Mullan wrote: >> >> Please review this change to Distrust TLS server certificates anchored by Symantec Root CAs. Although the restrictions won't kick in until after 12 GA, the fix touches code that validates certificate chains, so getting this into 12 now will provide more assurance that the chain validation code continues to work properly. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8207258 >> >> Please see the recently posted blog for more information about the restrictions that are being imposed: https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates >> >> Thanks, >> Sean > From openjdk at suche.org Mon Dec 10 19:58:45 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 10 Dec 2018 20:58:45 +0100 Subject: JDK11 Bug with SSLv3 In-Reply-To: <3813d98b-dba4-93ea-13af-f129be9832b1@oracle.com> References: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> <3813d98b-dba4-93ea-13af-f129be9832b1@oracle.com> Message-ID: Hi, i am not sure if there is already an bug opened. But i found an error in the SSL-Socket handling. If the ssl client socket enabled SSLv3-TLSv1.2 and the server select SSLv3 the client later on send an "RSA ClientKeyExchange" with version TLSv1.2. I added the relevant parts of the debug log. If there is no bug opened yet i can provide an sample with client/server that demonstrate the bug and can maybe used for regression tests. Gru? Thomas Lu?nig 2018-12-10T12:16:41.666 javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.666 CET|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { ? "client version"????? : "TLSv1.2", ? "random"????????????? : "90 B4 FF B0 8E C8 FA 3F D8 15 A3 73 13 78 38 D5 3A FB 49 68 28 ED B1 95 3C 3E 24 0C DD 64 A2 95", ? "session id"????????? : "", ? "cipher suites"?????? : "[SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", ? "compression methods" : "00", ? ... 2018-12-10T12:16:41.688 javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.688 CET|ServerHello.java:866|Consuming ServerHello handshake message ( "ServerHello": { ? "server version"????? : "SSLv3", ? "random"????????????? : "5C 37 37 A9 EA DD D7 67 28 15 D3 DF 5F 3F 13 E2 34 88 93 67 16 FD 4F 76 A6 08 11 BE 36 E3 B4 26", ? "session id"????????? : "1D 5F B9 F7 EC DE 8E D9 38 52 AB FF 04 A1 24 1D", ? "cipher suite"??????? : "SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A)", ? "compression methods" : "00", ? "extensions"????????? : [ ??? ? ] } ) 2018-12-10T12:16:41.699 javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.699 CET|CertificateMessage.java:358|Consuming server Certificate handshake message ( "Certificates": [ ? "certificate" : { ??? "version"??????????? : "v3", ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", ??? "signature algorithm": "SHA256withRSA", ??? "issuer"???????????? : "CN=VR IDENT CLASS 3 CA 2010, OU=VR IDENT, O=GAD EG, C=DE", ??? "not before"???????? : "2017-07-20 01:33:58.000 CEST", ??? ... 2018-12-10T12:16:41.854 javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.853 CET|X509TrustManagerImpl.java:242|Found trusted certificate ( ? "certificate" : { ??? "version"??????????? : "v3", ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", ??? ... 2018-12-10T12:16:41.856 javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.856 CET|RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake message ( "RSA ClientKeyExchange": { ? "client_version":? TLSv1.2 ? "encncrypted": { ??? 0000: 52 2E C4 EB 8C 65 06 77?? 47 5D 9E 10 56 95 8A 6E R....e.wG]..V..n ??? 0010: 03 D0 70 8D 73 51 93 F7?? 8B F7 73 55 25 AC E4 0C ..p.sQ....sU%... ??? 0020: 34 68 26 01 E0 40 64 B5?? 82 C6 1C 7C 04 81 E3 15 4h&.. at d......... ??? ... From xuelei.fan at oracle.com Mon Dec 10 21:14:58 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 10 Dec 2018 13:14:58 -0800 Subject: Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close Message-ID: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> Hi, Please review the TLS 1.3 half-close issue in JDK. http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/ While trying to duplex close a TLS connection upon the half-close policy, there might be pending receiving data in the closing side, and result in a TCP RST during closing. The TCP RST may then cause the peer reading failure. For example: 1. client and server establish a TLS 1.3 connection. 2. server sending the post-handshake NewSessionTicket message. 3. client send the application data, and then close the connection. 4. as the client does not call to read the post-handshake message, the connection close will cause a TCP RST. 5. server trying to read the client application data, but the socket may be impacted by the TCP RST, and the reading can fail. It would not be an issue any more if the client could read the post-handshake message, explicit or implicit. I would like applications consider to use half-close policy, and moving away from the duplex-close policy. The basic idea of the fix is trying to use up buffered network input before close the socket. As is an implicit behavior to consume the post-handshake message, and mitigate the impact of it. This fix is not a perfect one. It is just a workaround for duplex-close. I'm open to hear more ideas. Thanks, Xuelei From openjdk at suche.org Mon Dec 10 23:44:03 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 11 Dec 2018 00:44:03 +0100 Subject: JDK11 Bug with SSLv3 In-Reply-To: References: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> <3813d98b-dba4-93ea-13af-f129be9832b1@oracle.com> Message-ID: <9b84358a-88a6-26a5-1b2c-83e6c0164d8c@suche.org> Hi, here is an demo to show the problem. a) The problem is an problem between the key exchange message and the enabled protocols and the server selected protocol. b) In this demo it only check if the protocol of the key exchange is TLSv1.2 while SSLv3 is expected. c) It also show another issue that the jdk as server does not check if the received messages matches the selected protocol version. ??? -> I think this does not open an security issue but should be verified too, it maybe wanted for compatibility but than it should be configurable per connection. Gru? Thomas Lu?nig package demo; import java.io.ByteArrayInputStream; import java.io.InputStream; import java.io.OutputStream; import java.io.PrintStream; import java.net.ServerSocket; import java.security.KeyFactory; import java.security.KeyStore; import java.security.PrivateKey; import java.security.Security; import java.security.cert.Certificate; import java.security.cert.CertificateFactory; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Arrays; import java.util.Base64; import javax.net.ssl.KeyManagerFactory; import javax.net.ssl.SSLContext; import javax.net.ssl.SSLServerSocket; import javax.net.ssl.SSLServerSocketFactory; import javax.net.ssl.SSLSocket; import javax.net.ssl.SSLSocketFactory; import javax.net.ssl.TrustManagerFactory; class CheckPrintStream extends PrintStream { ??? public CheckPrintStream() { super(System.out); } ??? @Override public void write(final byte[] buf, final int off, final int len) { ??? ??? final String t = new String(buf, off, len); ??? ??? if(t.contains("RSA ClientKeyExchange")) { ??? ??? ??? if(t.contains("\"client_version\":? TLSv1.2")) { ??? ??? ??? ??? System.out.println("CHECK Failed"); ??? ??? ??? ??? final int p = t.indexOf("TLSv1.2"); ??? ??? ??? ??? super.write(buf, off, p+7); ??? ??? ??? ??? super.write('\n'); ??? ??? ??? } ??? ??? ??? else super.write(buf, off, len); ??? ??? } ??? } } public class SSLv3_TLSv12 { ??? static Base64.Decoder b64 = Base64.getDecoder(); ??? static byte[] rsaKey = b64.decode("MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAI64R+LgQkK7kAMRrJh8IbhwXjl0X579vTPJZGUwltqu5tKMpvQE7LDiPP3TAWD1m5ntXHFZKrhiI2QU5kSVGH8yggzK3eFcz8K8p56MpCcqykgM5R/Nt6LSKx/n3snNKuWIOdgOZzl75JXTLp3Mc4IXNFzut6fKopT7N9NRZaktAgMBAAECgYEAiXuD5E3cBqTgCdTQyuNpKF82pWoxYttTk7uBdujjqS2rNVBA0/iaeZq23lyRi3GNvy4kSxx2RsBjD1oCqDZoLUXRyxYqYr2STYZXdz3hKC7p3E7mT+0DgYFWe3nUSlXLGaSpwgXtiH1xLQZ7/jqCMWwDDTibsVcbJDz/Lb2x1xECQQDwku/XTLphWYaTEzw2MkYMxswYDGxIPEM+3hvpzF4Elr5hAOjSfSa66Og89hyokKn5/uRWZ08YbDIuY+BtihSjAkEAl98NN90Gky3p7Kto+39uT9ltzzzpv1+UCyqkY//Q6BrDzoixiNTQtdEnzkXZwYrqe35kIHHIv6gn0t03LDNX7wJBANkdIwuBmauF6mgNsgePc5zQRR1nCMpgaKfyN+rWn/swOHy/H1/nxu5kiEOMMe0HMgAGw/geoEmATAGF7eOt/FUCQHgTOvg4IMKtQo6E1/RAxI8NceywVH+iqgJKLL+Du0BIKRhaq0NsP7gBLl/AinKjytDpFXExhW9DHHlzvfOMhLECQQDmeLkRneJ/Hh5kK5vtpNgE9V+kLfnN2+QhCIWHztFR9VNNgf3JzfZFCruwldZJnCPIdxAi7CpECsk/Bf2zL6XD"); ??? static byte[] rsaCer = b64.decode("MIICHjCCAYegAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMQ0wCwYDVQQLEwRDZXJ0MRIwEAYDVQQKEwlzdWNoZS5vcmcxCzAJBgNVBAYTAkRFMRIwEAYDVQQDEwlsb2NhbGhvc3QwHhcNMTgxMjA5MjIzMDIwWhcNMTgxMjIxMTIxNzAwWjBEMQ0wCwYDVQQLEwRDZXJ0MRIwEAYDVQQKEwlzdWNoZS5vcmcxCzAJBgNVBAYTAkRFMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI64R+LgQkK7kAMRrJh8IbhwXjl0X579vTPJZGUwltqu5tKMpvQE7LDiPP3TAWD1m5ntXHFZKrhiI2QU5kSVGH8yggzK3eFcz8K8p56MpCcqykgM5R/Nt6LSKx/n3snNKuWIOdgOZzl75JXTLp3Mc4IXNFzut6fKopT7N9NRZaktAgMBAAGjIDAeMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgP4MA0GCSqGSIb3DQEBCwUAA4GBAGFzQL9URFabGys3clkqn6l/tdTzqn6ncG1dL/rhoO1jPAxqGdf7hJ9iPQjPRpdqJl5aawLx9BtWCkdCNXN+Vk4opaGmVNsmQ1eRbZREYEKVKPNquzDIcimDYveYNPRf9shUcU2Z7eAI/GX/uMSlm4XzL7sL4P0v8M/qfja8EQ46"); ??? static { ??? ??? Security.setProperty("jdk.tls.disabledAlgorithms", ""); ??? ??? System.setProperty("javax.net.debug","all"); ??? } ??? static void server(final ServerSocket srv, final String[] suites) { ??? ??? while(!srv.isClosed()) { ??? ??? ??? try(??? SSLSocket s = (SSLSocket)srv.accept(); ??? ??? ??? ??? ??? InputStream? i = s.getInputStream(); ??? ??? ??? ??? ??? OutputStream o = s.getOutputStream()) { ??? ??? ??? ??? s.setUseClientMode(false); ??? ??? ??? ??? if(suites != null) s.setEnabledCipherSuites(suites); ??? ??? ??? ??? s.setEnabledProtocols(new String[]{"SSLv3"}); ??? ??? ??? ??? o.write('s'); ??? ??? ??? ??? i.read(); ??? ??? ??? ??? suite = s.getSession().getCipherSuite(); ??? ??? ??? } catch(final Throwable t) { t.printStackTrace(); } ??? ??? } ??? } ??? static SSLContext context(final String keyType) throws Exception { ??? ??? final PrivateKey key = KeyFactory.getInstance(keyType).generatePrivate(new PKCS8EncodedKeySpec(rsaKey)); ??? ??? final CertificateFactory fact = CertificateFactory.getInstance("X.509"); ??? ??? final Certificate??? cer = fact.generateCertificate(new ByteArrayInputStream(rsaCer)); ??? ??? final KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); ??? ??? ks.load(null, null); ??? ??? final char[] pass = "test".toCharArray(); ??? ??? ks.setKeyEntry("a", key, pass, new Certificate[]{cer}); ??? ??? final TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); ??? ??? tmf.init(ks); ??? ??? final KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); ??? ??? kmf.init(ks, pass); ??? ??? final SSLContext c = SSLContext.getInstance("TLS"); ??? ??? c.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); ??? ??? return c; ??? } ??? static volatile String suite = null; ??? static void doCheck(final String[] suites) { ??? ??? suite = null; ??? ??? System.out.println("START Suites: "+Arrays.toString(suites)); ??? ??? try { ??? ??? ??? final SSLContext c = context("RSA"); ??? ??? ??? final SSLSocketFactory?????? csf = c.getSocketFactory(); ??? ??? ??? final SSLServerSocketFactory ssf = c.getServerSocketFactory(); ??? ??? ??? try(final SSLServerSocket srv = (SSLServerSocket)ssf.createServerSocket(0, 16)) { ??? ??? ??? ??? if(suites != null) srv.setEnabledCipherSuites(suites); ??? ??? ??? ??? srv.setEnabledProtocols(new String[]{"SSLv3"}); ??? ??? ??? ??? new Thread(()->server(srv, suites)).start(); ??? ??? ??? ??? try(??? SSLSocket s = (SSLSocket)csf.createSocket("localhost", srv.getLocalPort()); ??? ??? ??? ??? ??? ??? InputStream? i = s.getInputStream(); ??? ??? ??? ??? ??? ??? OutputStream o = s.getOutputStream()) { ??? ??? ??? ??? ??? if(suites != null) s.setEnabledCipherSuites(suites); ??? ??? ??? ??? ??? s.setEnabledProtocols(new String[]{"SSLv3","TLSv1","TLSv1.1","TLSv1.2"}); ??? ??? ??? ??? ??? o.write('c'); ??? ??? ??? ??? ??? i.read(); ??? ??? ??? ??? } catch(final Throwable t) { t.printStackTrace(System.out); } ??? ??? ??? } ??? ??? } catch(final Throwable t) { t.printStackTrace(System.out); ??? ??? } finally { System.out.println("DONE Suites: "+Arrays.toString(suites)+" used "+suite); } ??? } ??? public static void main(final String[] argc) throws Exception { ??? ??? try(final PrintStream check = new CheckPrintStream()) { ??? ??? ??? System.setErr(check); ??? ??? ??? doCheck(new String[]{"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"}); // WORKS ??? ??? ??? doCheck(new String[]{"SSL_RSA_WITH_3DES_EDE_CBC_SHA"???? }); // -> Wrong TLSv1.2 in "RSA ClientKeyExchange" ??? ??? } ??? } } On 10.12.2018 20:58:45, Thomas Lu?nig wrote: > Hi, > > i am not sure if there is already an bug opened. But i found an error > in the SSL-Socket handling. > If the ssl client socket enabled SSLv3-TLSv1.2 and the server select > SSLv3 the client later on send an > "RSA ClientKeyExchange" with version TLSv1.2. I added the relevant > parts of the debug log. > If there is no bug opened yet i can provide an sample with > client/server that demonstrate the bug > and can maybe used for regression tests. > > Gru? Thomas Lu?nig > > > 2018-12-10T12:16:41.666 > javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.666 > CET|ClientHello.java:651|Produced ClientHello handshake message ( > "ClientHello": { > ? "client version"????? : "TLSv1.2", > ? "random"????????????? : "90 B4 FF B0 8E C8 FA 3F D8 15 A3 73 13 78 > 38 D5 3A FB 49 68 28 ED B1 95 3C 3E 24 0C DD 64 A2 95", > ? "session id"????????? : "", > ? "cipher suites"?????? : "[SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A), > TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", > ? "compression methods" : "00", > ? ... > > 2018-12-10T12:16:41.688 > javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.688 > CET|ServerHello.java:866|Consuming ServerHello handshake message ( > "ServerHello": { > ? "server version"????? : "SSLv3", > ? "random"????????????? : "5C 37 37 A9 EA DD D7 67 28 15 D3 DF 5F 3F > 13 E2 34 88 93 67 16 FD 4F 76 A6 08 11 BE 36 E3 B4 26", > ? "session id"????????? : "1D 5F B9 F7 EC DE 8E D9 38 52 AB FF 04 A1 > 24 1D", > ? "cipher suite"??????? : "SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A)", > ? "compression methods" : "00", > ? "extensions"????????? : [ > ??? > ? ] > } > ) > > 2018-12-10T12:16:41.699 > javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.699 > CET|CertificateMessage.java:358|Consuming server Certificate handshake > message ( > "Certificates": [ > ? "certificate" : { > ??? "version"??????????? : "v3", > ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", > ??? "signature algorithm": "SHA256withRSA", > ??? "issuer"???????????? : "CN=VR IDENT CLASS 3 CA 2010, OU=VR IDENT, > O=GAD EG, C=DE", > ??? "not before"???????? : "2017-07-20 01:33:58.000 CEST", > ??? ... > > 2018-12-10T12:16:41.854 > javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.853 > CET|X509TrustManagerImpl.java:242|Found trusted certificate ( > ? "certificate" : { > ??? "version"??????????? : "v3", > ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", > ??? ... > > 2018-12-10T12:16:41.856 > javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.856 > CET|RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange > handshake message ( > "RSA ClientKeyExchange": { > ? "client_version":? TLSv1.2 > ? "encncrypted": { > ??? 0000: 52 2E C4 EB 8C 65 06 77?? 47 5D 9E 10 56 95 8A 6E > R....e.wG]..V..n > ??? 0010: 03 D0 70 8D 73 51 93 F7?? 8B F7 73 55 25 AC E4 0C > ..p.sQ....sU%... > ??? 0020: 34 68 26 01 E0 40 64 B5?? 82 C6 1C 7C 04 81 E3 15 > 4h&.. at d......... > ??? ... > > From weijun.wang at oracle.com Tue Dec 11 00:56:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Dec 2018 08:56:35 +0800 Subject: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs In-Reply-To: <18bb6005-8c01-b36c-63c9-1cd0f9cd5fe4@oracle.com> References: <0d337ca6-8ebf-6487-4f4f-1d972a4dd140@oracle.com> <2C1570CF-1A9C-49C5-9C9F-5671C39ADC7A@oracle.com> <18bb6005-8c01-b36c-63c9-1cd0f9cd5fe4@oracle.com> Message-ID: CADistrustPolicy.java: 81 if (property == null || property.length() == 0) { 82 return set; 83 } There is an ongoing effort to use property.isEmpty(). Let's go with it. Everything else looks fine to me. Thanks, Max > On Dec 11, 2018, at 3:20 AM, Sean Mullan wrote: > > Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.02/ > > Specific comments below ... > > On 12/9/18 9:22 AM, Weijun Wang wrote: >> Hi Sean, >> CADistrustPolicy.java: >> 80 String[] policies = (property != null) ? property.split(",") : null; >> 81 EnumSet set = EnumSet.noneOf(CADistrustPolicy.class); >> 82 for (String policy : policies) { >> If the property is not defined, the last line above would throw an NPE. > > Good catch. > >> test/Distrust.java: >> 118 private static final Date APRIL_17_2019 = >> 119 Date.from(LocalDate.of(2019, 4, 17) >> 120 .atStartOfDay(ZoneId.systemDefault()) >> 121 .toInstant()); >> Should UTC be used? > > Yes, fixed. > >> 144 testTM(getTMF("PKIX", getParams(VERISIGN_UNIVERSAL_ROOTCA)), >> 145 loadCertificateChain("verisignuniversalrootca"), !distrust); >> What's the purpose of the above test? To make sure that even if one day we removed these root CAs from cacerts then the mechanism still works as expected? > > No, it is simply to test the use case where an application passes its own PKIXBuilderParameters into a TrustManager. However, it is better to just pass in the cacerts KeyStore in that case to the PKIXBuilderParameters constructor. So, I have modified the test accordingly. I also created a new SecurityUtils class in the test library area and added a utility method for returning the cacerts KeyStore. We can change other tests over time to use this new utility method. > >> 191 X509Certificate tlsServerCert = chain[0]; >> 192 chain[0] = new DistrustedTLSServerCert(tlsServerCert, APRIL_17_2019); >> Is it necessary to introduce a local variable? > > No, fixed. > > Thanks, > Sean > >> No other comment. >> Thanks, >> Max >>> On Dec 8, 2018, at 12:02 AM, Sean Mullan wrote: >>> >>> Please review this change to Distrust TLS server certificates anchored by Symantec Root CAs. Although the restrictions won't kick in until after 12 GA, the fix touches code that validates certificate chains, so getting this into 12 now will provide more assurance that the chain validation code continues to work properly. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/ >>> issue: https://bugs.openjdk.java.net/browse/JDK-8207258 >>> >>> Please see the recently posted blog for more information about the restrictions that are being imposed: https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates >>> >>> Thanks, >>> Sean From weijun.wang at oracle.com Tue Dec 11 05:34:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Dec 2018 13:34:13 +0800 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> Message-ID: <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> Hi Martin, This is really a big contribution. I'll look at it once I have free time. Currently busy with last minute changes before JDK 12 RDP. Thanks, Max > On Dec 10, 2018, at 11:39 PM, Martin Balao wrote: > > Hi, > > I'd like to propose an implementation of Kerberos cross-realm referrals > for OpenJDK's client, according to RFC 6806 [1]. > > Request for Enhancement: "JDK-8215032 - Support Kerberos cross-realm > referrals (RFC 6806)" [2]. > > Related tickets: "JDK-6631053 - Support canonicalize in Kerberos > configuration file" [3] and "JDK-8005819 - Support cross-realm MSSFU" [4]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00.zip > > Implementation notes: > > * System properties introduced: > * sun.security.krb5.disableReferrals: disable this feature > * sun.security.krb5.maxReferrals: max referral hops for both client > and server referrals (5 by default, as suggested by RFC 6806) > * CSR will be needed > > * NT-ENTERPRISE principals > * Supported > * Krb5LoginModule has not been extended to use it. However, I'm open > to discuss this API first and propose an implementation then -either in > the context of this enhancement or in a new one-. > > * Client referrals > * Supported > * Client announces support setting CANONICALIZE flag > * Fallback: if a failure occurs, client retries without CANONICALIZE flag > > * Server referrals > * Supported > * Client announces support setting CANONICALIZE flag > * Fallback: if a failure occurs, client retries without CANONICALIZE flag > > * FAST > * RFC 6806 - Section 11 FAST scheme supported > * Complete FAST support (RFC 6113) is out of scope > * RFC 6806 - Section 11 FAST is mandatory for AS-REQ, and optional for > TGS-REQ. Client does not ask for it in TGS requests -sending > PA-REQ-ENC-PA-REP PA data- for compatibility reasons. Some servers do > not support PA-REQ-ENC-PA-REP in TGS requests and if no checksum is > available in TGS responses (even though ENC_PA_REP flag is set), no > enforcement is possible. > * MIT's client does not send PA-REQ-ENC-PA-REP requests for TGS, only > for TGTs [5] > * MIT's client only verifies PA-REQ-ENC-PA-REP for TGTs [6] > * MIT's KDC supports PA-REQ-ENC-PA-REP in TGT [7] and TGS [8] > replies, but Microsoft's Active Directory 2016 does not apparently. > > * Cache > * If a referral loop is introduced when adding a new entry to the > cache, we break the loop by invalidating the "next" entry > * Adding an entry to the cache may override a previous one > * The assumption is that newer information is more accurate > * For a given Principal Name, there can only be one "Realm -> Next > Realm" referral entry (whose lifetime is given by the referral krbtgt > ticket) > > * Security > * Client name changes are allowed in AS-REPs only if: > * Client sent CANONICALIZE > * Server supports RFC 6806 - Section 11 FAST > * Authenticated checksum is correct > * Server name changes are allowed in TGS-REPs only if: > * Client sent CANONICALIZE > * It's for a referral (sname = krbtgt/TO-REALM.COM at FROM-REALM.COM) > > * Testing > * KDC used for testing purposes was extended to include basic support > of RFC 6806 server-side > * NT-ENTERPRISE principals > * Client referrals > * Server referrlas > * FAST - Section 11 scheme > * ReferralsTest functional test added > * Client referral with NT-ENTERPRISE principal > * Server referral > > Regressing testing: > > * No regressions found in jdk/sun/security/krb5 category. > * Test results: passed: 128 > > I'd be grateful if someone can have a look. > > Kind regards, > Martin.- > > -- > [1] - https://tools.ietf.org/html/rfc6806.html > [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 > [3] - https://bugs.openjdk.java.net/browse/JDK-6631053 > [4] - https://bugs.openjdk.java.net/browse/JDK-8005819 > [5] - > https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1421 > [6] - > https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1665 > [7] - > https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_as_req.c#L326 > [8] - > https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_tgs_req.c#L724 From wenxiang.qiu at foxmail.com Tue Dec 11 08:57:13 2018 From: wenxiang.qiu at foxmail.com (=?ISO-8859-1?B?V2VueGlhbmc=?=) Date: Tue, 11 Dec 2018 16:57:13 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke Message-ID: Hi everyone, I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. Wenxiang Qiu -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Dec 11 09:55:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Dec 2018 17:55:01 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: References: Message-ID: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. --Max > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > Hi everyone, > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > Wenxiang Qiu From matthias.baesken at sap.com Tue Dec 11 15:38:43 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Dec 2018 15:38:43 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> Message-ID: > File paths are, in general, always something that demands extra scrutiny > as it can be the source of security issues (privacy leaks, traversal > attacks, etc). It's not just me that thinks that way, you can do a > search on the Internet and find lots of references. ... > > It might be perfectly fine and your usage might be ok too. But I'll need > some time to evaluate it further. I am not familiar with the code in > this part of the JDK. > > I would also see if you can think about the security issues as well. > Where do these paths come from? What are the application use cases that > invoke these lower methods? From application code or elsewhere? Are > relative paths used? Are paths containing ".." canonicalized? Are they > arbitrary paths or a fixed set of paths? Do they ever contain sensitive > information like home directory user names, etc? > > Once we understand if there are any security issues, then we can decide > if allowing that via a system property is acceptable or not, and if so > the security risks that we would have to document for that property. > Hello, the file paths potentially printed in the enhanced exceptions in *canonicalize0, *createFileExclusively, Java_java_io_WinNTFileSystem_canonicalizeWithPrefix0 could potentially come from more or less arbitrary paths. This means, in some cases, there is a chance that information (like user-ids/user-names often found in paths below HOME dirs ) might be in the printed paths that people do not want to have in log files or other output containing the exception messages. For such potentially sensitive info in exception messages, we have already the jdk.includeInExceptions security property, see the java.security file : 1064 # Enhanced exception message information 1065 # 1066 # By default, exception messages should not include potentially sensitive 1067 # information such as file names, host names, or port numbers. This property 1068 # accepts one or more comma separated values, each of which represents a 1069 # category of enhanced exception message information to enable. Values are 1070 # case-insensitive. Leading and trailing whitespaces, surrounding each value, 1071 # are ignored. Unknown values are ignored. I think this approach fits well for 8211752 (and is used already for some other categories). I created an updated webrev, it uses the jdk.includeInExceptions security property (had to do it via JNI because it did not work from the static class initializers of UnixFileSystem/WinNTFileSystem) : http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.2/ Best regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Donnerstag, 8. November 2018 20:36 > To: Baesken, Matthias ; Langer, Christoph > ; Alan Bateman ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > On 11/7/18 3:52 AM, Baesken, Matthias wrote: > >> Sorry, I haven't had time to look at this in more detail yet. But, let's > >> take a step back first. Can you or Matthias explain in more detail why > >> this fix is necessary? What are the use cases and motivation? > > > > Hello, > > adding paths (or maybe more details) to exception messages just > makes analyzing errors easier. > > You do not get just "Bad path", but also the real bad path which gives you a > hint where to look and analyze further . > > File paths are, in general, always something that demands extra scrutiny > as it can be the source of security issues (privacy leaks, traversal > attacks, etc). It's not just me that thinks that way, you can do a > search on the Internet and find lots of references. > > > That's why we introduced it in our JVM ages ago. > > I have to agree that additionally printing cwd / user.dir is a bit special, so I > omit that from this revision of the patch. > > This makes the patch more simple. > > New revision : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.1/ > > > > > > Unfortunately the usage of sun.security.util.SecurityProperties (which was > considered) in the static { ... } > > class initializers (e.g. UnixFileSystem.java) just does not work. > > It fails with already in the build (!) with : > > > > Error occurred during initialization of boot layer > > java.lang.ExceptionInInitializerError > > Caused by: java.lang.NullPointerException > > > > (seems it is too early in the game for SecurityProperties). > > (btw. this is another NOT very helpful exception error message) > > > > > > So I unfortunately had to go back to using system properties. > > > > > > Btw. another question regarding path output in exceptions : > > you seem to consider it a bad thing to (unconditionally) print paths in the > exception messages, > > but then on the other hand we have it already in OpenJDK > UnixFileSystem_md.c : > > > > 269 JNIEXPORT jboolean JNICALL > > 270 Java_java_io_UnixFileSystem_createFileExclusively(JNIEnv *env, > jclass cls, > > 271 jstring pathname) > > 272 { > > ....... > > 277 /* The root directory always exists */ > > 278 if (strcmp (path, "/")) { > > 279 fd = handleOpen(path, O_RDWR | O_CREAT | O_EXCL, 0666); > > 280 if (fd < 0) { > > 281 if (errno != EEXIST) > > 282 JNU_ThrowIOExceptionWithLastError(env, path); > > 283 } else { > > 284 if (close(fd) == -1) > > 285 JNU_ThrowIOExceptionWithLastError(env, path); > > > > > > Why is it fine here for a long time , but considered harmful at the other > places ? > > If we want to be consistent, we should then write "Bad path" here (or > allow the path output at the other places too ). > > It might be perfectly fine and your usage might be ok too. But I'll need > some time to evaluate it further. I am not familiar with the code in > this part of the JDK. > > I would also see if you can think about the security issues as well. > Where do these paths come from? What are the application use cases that > invoke these lower methods? From application code or elsewhere? Are > relative paths used? Are paths containing ".." canonicalized? Are they > arbitrary paths or a fixed set of paths? Do they ever contain sensitive > information like home directory user names, etc? > > Once we understand if there are any security issues, then we can decide > if allowing that via a system property is acceptable or not, and if so > the security risks that we would have to document for that property. > > Thanks, > Sean > From jamil.j.nimeh at oracle.com Tue Dec 11 17:16:41 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 11 Dec 2018 09:16:41 -0800 Subject: JDK11 Bug with SSLv3 In-Reply-To: <9b84358a-88a6-26a5-1b2c-83e6c0164d8c@suche.org> References: <859ce23e-2d0d-6897-a891-0f9b2cbb53f5@oracle.com> <3813d98b-dba4-93ea-13af-f129be9832b1@oracle.com> <9b84358a-88a6-26a5-1b2c-83e6c0164d8c@suche.org> Message-ID: Quick follow up.? Thomas and I exchanged a couple messages off-alias but I wanted to summarize it here in case others were following this thread.? The short story: Based on what is in RFC 5246 with respect to the RSA client key exchange message, the Java client is putting the correct version in the PreMasterSecret.client_version field. --Jamil On 12/10/2018 3:44 PM, Thomas Lu?nig wrote: > Hi, > > here is an demo to show the problem. > a) The problem is an problem between the key exchange message and the > enabled protocols and the server selected protocol. > b) In this demo it only check if the protocol of the key exchange is > TLSv1.2 while SSLv3 is expected. > c) It also show another issue that the jdk as server does not check if > the received messages matches the selected protocol version. > ??? -> I think this does not open an security issue but should be > verified too, it maybe wanted for compatibility but than it should be > configurable per connection. > > Gru? Thomas Lu?nig > > package demo; > > import java.io.ByteArrayInputStream; > import java.io.InputStream; > import java.io.OutputStream; > import java.io.PrintStream; > import java.net.ServerSocket; > import java.security.KeyFactory; > import java.security.KeyStore; > import java.security.PrivateKey; > import java.security.Security; > import java.security.cert.Certificate; > import java.security.cert.CertificateFactory; > import java.security.spec.PKCS8EncodedKeySpec; > import java.util.Arrays; > import java.util.Base64; > > import javax.net.ssl.KeyManagerFactory; > import javax.net.ssl.SSLContext; > import javax.net.ssl.SSLServerSocket; > import javax.net.ssl.SSLServerSocketFactory; > import javax.net.ssl.SSLSocket; > import javax.net.ssl.SSLSocketFactory; > import javax.net.ssl.TrustManagerFactory; > > class CheckPrintStream extends PrintStream { > ??? public CheckPrintStream() { super(System.out); } > > ??? @Override public void write(final byte[] buf, final int off, final > int len) { > ??? ??? final String t = new String(buf, off, len); > ??? ??? if(t.contains("RSA ClientKeyExchange")) { > ??? ??? ??? if(t.contains("\"client_version\":? TLSv1.2")) { > ??? ??? ??? ??? System.out.println("CHECK Failed"); > ??? ??? ??? ??? final int p = t.indexOf("TLSv1.2"); > ??? ??? ??? ??? super.write(buf, off, p+7); > ??? ??? ??? ??? super.write('\n'); > ??? ??? ??? } > ??? ??? ??? else super.write(buf, off, len); > ??? ??? } > ??? } > } > > public class SSLv3_TLSv12 { > ??? static Base64.Decoder b64 = Base64.getDecoder(); > ??? static byte[] rsaKey = > b64.decode("MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAI64R+LgQkK7kAMRrJh8IbhwXjl0X579vTPJZGUwltqu5tKMpvQE7LDiPP3TAWD1m5ntXHFZKrhiI2QU5kSVGH8yggzK3eFcz8K8p56MpCcqykgM5R/Nt6LSKx/n3snNKuWIOdgOZzl75JXTLp3Mc4IXNFzut6fKopT7N9NRZaktAgMBAAECgYEAiXuD5E3cBqTgCdTQyuNpKF82pWoxYttTk7uBdujjqS2rNVBA0/iaeZq23lyRi3GNvy4kSxx2RsBjD1oCqDZoLUXRyxYqYr2STYZXdz3hKC7p3E7mT+0DgYFWe3nUSlXLGaSpwgXtiH1xLQZ7/jqCMWwDDTibsVcbJDz/Lb2x1xECQQDwku/XTLphWYaTEzw2MkYMxswYDGxIPEM+3hvpzF4Elr5hAOjSfSa66Og89hyokKn5/uRWZ08YbDIuY+BtihSjAkEAl98NN90Gky3p7Kto+39uT9ltzzzpv1+UCyqkY//Q6BrDzoixiNTQtdEnzkXZwYrqe35kIHHIv6gn0t03LDNX7wJBANkdIwuBmauF6mgNsgePc5zQRR1nCMpgaKfyN+rWn/swOHy/H1/nxu5kiEOMMe0HMgAGw/geoEmATAGF7eOt/FUCQHgTOvg4IMKtQo6E1/RAxI8NceywVH+iqgJKLL+Du0BIKRhaq0NsP7gBLl/AinKjytDpFXExhW9DHHlzvfOMhLECQQDmeLkRneJ/Hh5kK5vtpNgE9V+kLfnN2+QhCIWHztFR9VNNgf3JzfZFCruwldZJnCPIdxAi7CpECsk/Bf2zL6XD"); > ??? static byte[] rsaCer = > b64.decode("MIICHjCCAYegAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMQ0wCwYDVQQLEwRDZXJ0MRIwEAYDVQQKEwlzdWNoZS5vcmcxCzAJBgNVBAYTAkRFMRIwEAYDVQQDEwlsb2NhbGhvc3QwHhcNMTgxMjA5MjIzMDIwWhcNMTgxMjIxMTIxNzAwWjBEMQ0wCwYDVQQLEwRDZXJ0MRIwEAYDVQQKEwlzdWNoZS5vcmcxCzAJBgNVBAYTAkRFMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI64R+LgQkK7kAMRrJh8IbhwXjl0X579vTPJZGUwltqu5tKMpvQE7LDiPP3TAWD1m5ntXHFZKrhiI2QU5kSVGH8yggzK3eFcz8K8p56MpCcqykgM5R/Nt6LSKx/n3snNKuWIOdgOZzl75JXTLp3Mc4IXNFzut6fKopT7N9NRZaktAgMBAAGjIDAeMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgP4MA0GCSqGSIb3DQEBCwUAA4GBAGFzQL9URFabGys3clkqn6l/tdTzqn6ncG1dL/rhoO1jPAxqGdf7hJ9iPQjPRpdqJl5aawLx9BtWCkdCNXN+Vk4opaGmVNsmQ1eRbZREYEKVKPNquzDIcimDYveYNPRf9shUcU2Z7eAI/GX/uMSlm4XzL7sL4P0v8M/qfja8EQ46"); > > ??? static { > ??? ??? Security.setProperty("jdk.tls.disabledAlgorithms", ""); > ??? ??? System.setProperty("javax.net.debug","all"); > ??? } > > ??? static void server(final ServerSocket srv, final String[] suites) { > ??? ??? while(!srv.isClosed()) { > ??? ??? ??? try(??? SSLSocket s = (SSLSocket)srv.accept(); > ??? ??? ??? ??? ??? InputStream? i = s.getInputStream(); > ??? ??? ??? ??? ??? OutputStream o = s.getOutputStream()) { > ??? ??? ??? ??? s.setUseClientMode(false); > ??? ??? ??? ??? if(suites != null) s.setEnabledCipherSuites(suites); > ??? ??? ??? ??? s.setEnabledProtocols(new String[]{"SSLv3"}); > ??? ??? ??? ??? o.write('s'); > ??? ??? ??? ??? i.read(); > ??? ??? ??? ??? suite = s.getSession().getCipherSuite(); > ??? ??? ??? } catch(final Throwable t) { t.printStackTrace(); } > ??? ??? } > ??? } > > ??? static SSLContext context(final String keyType) throws Exception { > ??? ??? final PrivateKey key = > KeyFactory.getInstance(keyType).generatePrivate(new > PKCS8EncodedKeySpec(rsaKey)); > ??? ??? final CertificateFactory fact = > CertificateFactory.getInstance("X.509"); > ??? ??? final Certificate??? cer = fact.generateCertificate(new > ByteArrayInputStream(rsaCer)); > ??? ??? final KeyStore ks = > KeyStore.getInstance(KeyStore.getDefaultType()); > ??? ??? ks.load(null, null); > ??? ??? final char[] pass = "test".toCharArray(); > ??? ??? ks.setKeyEntry("a", key, pass, new Certificate[]{cer}); > ??? ??? final TrustManagerFactory tmf = > TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); > ??? ??? tmf.init(ks); > ??? ??? final KeyManagerFactory kmf = > KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); > ??? ??? kmf.init(ks, pass); > ??? ??? final SSLContext c = SSLContext.getInstance("TLS"); > ??? ??? c.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); > ??? ??? return c; > ??? } > > ??? static volatile String suite = null; > > ??? static void doCheck(final String[] suites) { > ??? ??? suite = null; > ??? ??? System.out.println("START Suites: "+Arrays.toString(suites)); > ??? ??? try { > ??? ??? ??? final SSLContext c = context("RSA"); > ??? ??? ??? final SSLSocketFactory?????? csf = c.getSocketFactory(); > ??? ??? ??? final SSLServerSocketFactory ssf = > c.getServerSocketFactory(); > ??? ??? ??? try(final SSLServerSocket srv = > (SSLServerSocket)ssf.createServerSocket(0, 16)) { > ??? ??? ??? ??? if(suites != null) srv.setEnabledCipherSuites(suites); > ??? ??? ??? ??? srv.setEnabledProtocols(new String[]{"SSLv3"}); > ??? ??? ??? ??? new Thread(()->server(srv, suites)).start(); > ??? ??? ??? ??? try(??? SSLSocket s = > (SSLSocket)csf.createSocket("localhost", srv.getLocalPort()); > ??? ??? ??? ??? ??? ??? InputStream? i = s.getInputStream(); > ??? ??? ??? ??? ??? ??? OutputStream o = s.getOutputStream()) { > ??? ??? ??? ??? ??? if(suites != null) s.setEnabledCipherSuites(suites); > ??? ??? ??? ??? ??? s.setEnabledProtocols(new > String[]{"SSLv3","TLSv1","TLSv1.1","TLSv1.2"}); > ??? ??? ??? ??? ??? o.write('c'); > ??? ??? ??? ??? ??? i.read(); > ??? ??? ??? ??? } catch(final Throwable t) { > t.printStackTrace(System.out); } > ??? ??? ??? } > ??? ??? } catch(final Throwable t) { t.printStackTrace(System.out); > ??? ??? } finally { System.out.println("DONE Suites: > "+Arrays.toString(suites)+" used "+suite); } > ??? } > > ??? public static void main(final String[] argc) throws Exception { > ??? ??? try(final PrintStream check = new CheckPrintStream()) { > ??? ??? ??? System.setErr(check); > ??? ??? ??? doCheck(new > String[]{"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"}); // WORKS > ??? ??? ??? doCheck(new String[]{"SSL_RSA_WITH_3DES_EDE_CBC_SHA"???? > }); // -> Wrong TLSv1.2 in "RSA ClientKeyExchange" > ??? ??? } > ??? } > } > > > On 10.12.2018 20:58:45, Thomas Lu?nig wrote: >> Hi, >> >> i am not sure if there is already an bug opened. But i found an error >> in the SSL-Socket handling. >> If the ssl client socket enabled SSLv3-TLSv1.2 and the server select >> SSLv3 the client later on send an >> "RSA ClientKeyExchange" with version TLSv1.2. I added the relevant >> parts of the debug log. >> If there is no bug opened yet i can provide an sample with >> client/server that demonstrate the bug >> and can maybe used for regression tests. >> >> Gru? Thomas Lu?nig >> >> >> 2018-12-10T12:16:41.666 >> javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.666 >> CET|ClientHello.java:651|Produced ClientHello handshake message ( >> "ClientHello": { >> ? "client version"????? : "TLSv1.2", >> ? "random"????????????? : "90 B4 FF B0 8E C8 FA 3F D8 15 A3 73 13 78 >> 38 D5 3A FB 49 68 28 ED B1 95 3C 3E 24 0C DD 64 A2 95", >> ? "session id"????????? : "", >> ? "cipher suites"?????? : "[SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A), >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >> ? "compression methods" : "00", >> ? ... >> >> 2018-12-10T12:16:41.688 >> javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.688 >> CET|ServerHello.java:866|Consuming ServerHello handshake message ( >> "ServerHello": { >> ? "server version"????? : "SSLv3", >> ? "random"????????????? : "5C 37 37 A9 EA DD D7 67 28 15 D3 DF 5F 3F >> 13 E2 34 88 93 67 16 FD 4F 76 A6 08 11 BE 36 E3 B4 26", >> ? "session id"????????? : "1D 5F B9 F7 EC DE 8E D9 38 52 AB FF 04 A1 >> 24 1D", >> ? "cipher suite"??????? : "SSL_RSA_WITH_3DES_EDE_CBC_SHA(0x000A)", >> ? "compression methods" : "00", >> ? "extensions"????????? : [ >> ??? >> ? ] >> } >> ) >> >> 2018-12-10T12:16:41.699 >> javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.699 >> CET|CertificateMessage.java:358|Consuming server Certificate >> handshake message ( >> "Certificates": [ >> ? "certificate" : { >> ??? "version"??????????? : "v3", >> ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", >> ??? "signature algorithm": "SHA256withRSA", >> ??? "issuer"???????????? : "CN=VR IDENT CLASS 3 CA 2010, OU=VR IDENT, >> O=GAD EG, C=DE", >> ??? "not before"???????? : "2017-07-20 01:33:58.000 CEST", >> ??? ... >> >> 2018-12-10T12:16:41.854 >> javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.853 >> CET|X509TrustManagerImpl.java:242|Found trusted certificate ( >> ? "certificate" : { >> ??? "version"??????????? : "v3", >> ??? "serial number"????? : "02 6F D4 BA 63 70 2F 13 00 91 5D E4", >> ??? ... >> >> 2018-12-10T12:16:41.856 >> javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.856 >> CET|RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange >> handshake message ( >> "RSA ClientKeyExchange": { >> ? "client_version":? TLSv1.2 >> ? "encncrypted": { >> ??? 0000: 52 2E C4 EB 8C 65 06 77?? 47 5D 9E 10 56 95 8A 6E >> R....e.wG]..V..n >> ??? 0010: 03 D0 70 8D 73 51 93 F7?? 8B F7 73 55 25 AC E4 0C >> ..p.sQ....sU%... >> ??? 0020: 34 68 26 01 E0 40 64 B5?? 82 C6 1C 7C 04 81 E3 15 >> 4h&.. at d......... >> ??? ... >> >> From sean.mullan at oracle.com Tue Dec 11 20:00:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Dec 2018 15:00:26 -0500 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> Message-ID: <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> On 12/11/18 10:38 AM, Baesken, Matthias wrote: >> File paths are, in general, always something that demands extra scrutiny >> as it can be the source of security issues (privacy leaks, traversal >> attacks, etc). It's not just me that thinks that way, you can do a >> search on the Internet and find lots of references. > ... >> >> It might be perfectly fine and your usage might be ok too. But I'll need >> some time to evaluate it further. I am not familiar with the code in >> this part of the JDK. >> >> I would also see if you can think about the security issues as well. >> Where do these paths come from? What are the application use cases that >> invoke these lower methods? From application code or elsewhere? Are >> relative paths used? Are paths containing ".." canonicalized? Are they >> arbitrary paths or a fixed set of paths? Do they ever contain sensitive >> information like home directory user names, etc? >> >> Once we understand if there are any security issues, then we can decide >> if allowing that via a system property is acceptable or not, and if so >> the security risks that we would have to document for that property. >> > > Hello, the file paths potentially printed in the enhanced exceptions in *canonicalize0, *createFileExclusively, > Java_java_io_WinNTFileSystem_canonicalizeWithPrefix0 could potentially come from more or less arbitrary paths. That to me, is an issue that warrants much more careful analysis before deciding whether to proceed with this fix. > This means, in some cases, there is a chance that information (like user-ids/user-names often found in paths below HOME dirs ) > might be in the printed paths that people do not want to have in log files or other output containing the exception messages. > > For such potentially sensitive info in exception messages, we have already the jdk.includeInExceptions > security property, see the java.security file : > > 1064 # Enhanced exception message information > 1065 # > 1066 # By default, exception messages should not include potentially sensitive > 1067 # information such as file names, host names, or port numbers. This property > 1068 # accepts one or more comma separated values, each of which represents a > 1069 # category of enhanced exception message information to enable. Values are > 1070 # case-insensitive. Leading and trailing whitespaces, surrounding each value, > 1071 # are ignored. Unknown values are ignored. > > I think this approach fits well for 8211752 (and is used already for some other categories). I am concerned that a single property controls whether or not potentially sensitive pathnames appear in Exceptions. > I created an updated webrev, it uses the jdk.includeInExceptions security property > (had to do it via JNI because it did not work from the static class initializers of UnixFileSystem/WinNTFileSystem) : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.2/ These exceptions are generated from a very low level part of the native JDK Windows or Unix FileSystem implementations. That is a concern. The previous usages of this property were more focused and confined to smaller parts of the code resulting in fewer code paths to analyze. I think we need to take a step back. I think we need to reconsider whether the jdk.includeInExceptions security property is appropriate for this type of enhancement. Therefore, I oppose this change as-is. I'm happy to participate in a more involved discussion where we start with use cases and motivation before jumping to solutions. Thanks, Sean From valerie.peng at oracle.com Tue Dec 11 22:21:08 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 11 Dec 2018 14:21:08 -0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe In-Reply-To: References: Message-ID: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> Hi Max, - Comments (line 60-63) missed SHA224withECDSA? - Line 430: should be "ECPublicKey" - Line 919, 922: is it really necessary to have two methods with algorithm name argument? It seems they are functionally the same but one calls CAPI vs CNG. Can they be merged? - generateECBlob() method (line 110-148), is the extra 1 due to the sign bit added by the BigInteger.toByteArray()? I recall BigInteger adds an extra 00 byte sometimes to indicate the positive value, but why is there an extra 1? Are the bytes for x, y, bs longer than the allocated "keyLen" length? - line 627, shouldn't 'C' be at buffer[1]? If not, what is at buffer[1]? len value is not checked, not sure how useful it is. Thanks, Valerie On 12/3/2018 7:14 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ > > A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. > > Not supported: > > 1. No EC KeyPairGenerator yet. > > 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. > > 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. > > 4. NONEwithECDSA not supported. > > Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. > > Thanks > Max > From Nico.Williams at twosigma.com Wed Dec 12 00:40:54 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 12 Dec 2018 00:40:54 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> Message-ID: <20181212004054.GG22527@twosigma.com> My review of the first 16% of https://cr.openjdk.java.net/~weijun/6722928/webrev.02/ is below. - First, I noticed this in the gssapi.h in the JDK: typedef void * gss_name_t; typedef void * gss_cred_id_t; typedef void * gss_ctx_id_t; This is not good! We long ago discovered that this is MUCH better as it engages C type safety rather than defeating it: typedef struct gss_name gss_name_t; typedef struct gss_cred gss_cred_id_t; typedef struct gss_ctx gss_ctx_id_t; RFC 2744 allows this. When we made that change in Solaris we actually found at least one bug that was only not catastrophic by sheer luck. Especially now that you're implementing a GSS-API provider in the OpenJDK, you'll really want to make this change to the OpenJDK's gssapi.h. Another benefit of this is that you then get to define those structs in your GSS provider / mechanism implementation, and then you don't need casts: struct gss_name { SEC_WCHAR* name; }; - Comments on sspi.cpp are inline below: /* * Copyright (c) 2018, 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 * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ // This library is client-side only, and only supports the default credentials. // It only speaks krb5 internally, and SPNEGO is supported by creating its own // NetTokenInit and parsing incoming NegTokenResp tokens. This ensures no other // mechanism (Ex: NTLM) is chosen. // // This library can be built directly with the following command: // cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp \ // -link -dll -out:sspi_bridge.dll #define UNICODE #define _UNICODE #include #include #include #include #include #define GSS_DLL_FILE #include #define SECURITY_WIN32 #include #pragma comment(lib, "secur32.lib") // A debugging macro #define PP(fmt, ...) \ if (trace) { \ ---> fprintf(stdout, "[SSPI:%ld] "fmt"\n", __LINE__, ##__VA_ARGS__); \ ---> fflush(stdout); \ } Why stdout instead of stderr? #define SEC_SUCCESS(Status) (*minor_status = Status, (Status) >= 0) --->#ifdef __cplusplus extern "C" { #endif /* __cplusplus */ The file extension is .cpp. // When KRB5_TRACE is set, debug info goes to stdout. The value is ignored. --->char* trace = getenv("KRB5_TRACE"); Global variable initialization with non-const expressions is C++ but not valid C. This is inside the extern "C" block. How does this build? If you want this to be C, make the file extension .c and make sure it builds with a C compiler. A thread-local `trace' variable would be better anyways, then you could toggle tracing by setting/clearing the env var (the JDK doesn't really give you a way to do this, but the JGSS JNI shim could arrange to expose the debug property to the native C GSS provider somehow, such as by setting/clearing the env var). void --->dump(LPSTR title, PBYTE data, DWORD len) You're only using dump() to dump a gss_OID. The length of a gss_OID is an OM_uint32 (which can be larger than uint32_t, but here it's always the same as uint32_t). Why not just use size_t instead of DWARD? For C constant string literals I'd use const char * instead of LPSTR. LPSTR is not const. I like const correctness. { if (trace) { printf("==== %s ====\n", title); for (DWORD i = 0; i < len; i++) { if (i != 0 && i % 16 == 0) { printf("\n"); } printf("%02X ", *(data + i) & 0xff); } printf("\n"); } } gss_OID_desc KRB5_OID = {9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"}; gss_OID_desc SPNEGO_OID = {6, "\x2b\x06\x01\x05\x05\x02"}; gss_OID_desc USER_NAME_OID = {10, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x01\x01"}; gss_OID_desc KRB5_NAME_OID = {10, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x01"}; gss_OID_desc HOST_SERVICE_NAME_OID = {10, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x01\x04"}; gss_OID_desc EXPORT_NAME_OID = {6, "\x2b\x06\x01\x05\x06\x04"}; I've checked KRB5_NAME_OID too, and it's correct. // gss_name_t is Name*. type is always KRB5_NAME --->typedef struct { SEC_WCHAR* name; } Name; See commentary above about gssapi.h's declarations of GSS handle types. You should change gss_name_t to be a typedef of struct gss_name *, then you should change this to be struct gss_name { SEC_WCHAR* name; }; You won't need to case any gss_name_t values. // gss_ctx_id_t is Context* --->typedef struct { CredHandle* phCred; CtxtHandle hCtxt; DWORD cbMaxMessage; SecPkgContext_Sizes SecPkgContextSizes; SecPkgContext_NativeNames nnames; BOOLEAN established; } Context; See above commentary. // gss_cred_id_t is Credential* --->typedef struct { CredHandle* phCred; long time; } Credential; See above commentary. --->/* This section holds supporting functions that are not exported */ Why not make these functions static then? // Prepend ASN.1 tag+length to data. // // [in, out] data: the data, which already had enough allocated space before // its head when called. Head moved backwards after called. --->// [in, out] pLen: a counter to maintain --->// [in] len: the ASN.1 length (MUST be less than 2^16) Can you add support for up to 2^24? // [in] tag: the ASN.1 tag void --->add_der_head(char** data, int* pLen, int len, int tag) I don't like that there's no size of the buffer pointed to by *data. I'd rather have arguments for: a) the `size_t' length of `*data', b) the `size_t *' number of bytes that can be prepended to `*data'. And add_der_head() should have a non-void return value by which to indicate that it could not write because there wasn't enough room or because the length to write was bigger than the limit you implemented for DER length encoding. `tag' should be unsigned. { char* pos = *data; int lenlen; if (len <= 0x7f) { pos[-1] = (char)len; lenlen = 1; } else if (len < 256) { pos[-1] = (char)len; pos[-2] = (char)0x81; lenlen = 2; } else { pos[-1] = (char)(len & 0xff); pos[-2] = (char)(len >> 8); pos[-3] = (char)0x82; lenlen = 3; } pos[-1-lenlen] = (char)tag; *pLen += 1 + lenlen; *data = pos - 1 - lenlen; } My UNTESTED version, written here as a stream of thought and attempting to support all of the DER tag and length encoding rules: typedef enum { UNIVERSAL = 0, APPLICATION, CONTEXT, PRIVATE } asn1_tag_class; // Prepend ASN.1 tag+length to data. See x.690 sections 8.1.2.x // and 8.1.3.x. // // x.690: // // https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-199407-S!!PDF-E&type=items // // [in, out] data: `*data' is the data to prepend a DER Tag&Length // to, and which has `*pLen' bytes of room // available in front; mutated to point to the // prepended DER Tag // [in, out] pLen: `*pLen' is the number of bytes of room // available in front of `*data'; mutated to // subtract the number of bytes prepended // [in] len: the ASN.1 length (MUST be less than 2^16) // [in] tag: the ASN.1 tag (MUST be less than 30) // [in] class: the class of the ASN.1 tag // [in] constructed: whether `*data' is a SEQUENCE or SET // encoding // // returns: number of bytes added (zero on failure) size_t add_der_head(unsigned char **data, size_t *pLen, size_t len, unsigned int tag, asn1_tag_class class, int constructed) { unsigned char *pos = *data; size_t lenNeeded = 1; size_t tagNeeded = 1; int lenOctect1; int tagOctect1 = /* first three bits of first tag byte, x.690 section 8.1.2.3 */ (class & 0x03) << 6 | (constructed ? 1 << 5 : 0); if (len <= 0x7f) { /* Short form definite length, x.690 section 8.1.3.4 */ lenOctect1 = 0x80 | len; } else { size_t bits = 0; size_t n = len; /* Long form definite length, x.690 section 8.1.3.5 */ while (n) { lenNeeded++; bits = (bits << 1) | 1; n >>= 8; } if (bits > 0x7e) return 0; lenOctect1 = 0x80 + bits; } if (tag <= 30) { /* Small tag, x.690 section 8.1.2.3 */ tagOctect1 |= tag; } else { size_t n = tag; /* Large tag, x.690 section 8.1.2.4 */ tagOctect1 |= 0x1f; while (n) { tagNeeded++; n >>= 7; } } if (*pLen < lenNeeded + tagNeeded) return 0; *pLen -= (lenNeeded + tagNeeded); while (lenNeeded > 1 && len) { *(pos--) = len & 0xff; len >>= 8; } *(pos--) = lenOctect1; while (tagNeeded > 1 && tag) { *(pos--) = tag & 0x7f; tag >>= 7; } *(pos--) = tagOctect1; *data = pos; return tagNeeded + lenNeeded; } // Prepend bytes to data. // // [in, out] data: the data, which already had enough allocated space before // its head when called. Head moved backwards after called. // [in, out] pLen: a counter to maintain // [in] in: a block of bytes // [in] len: length of in void --->add_data(char** data, int* pLen, char* in, int len) I'd also make similar changes here. { char* pos = *data; memcpy_s(pos - len, len, in, len); *pLen += len; *data = pos - len; } // Wrap a krb5 token into NegTokenInit // Returns 1 for success, 0 for failure // --->// Implements a very small subset of RFC 4178, negotiating exactly --->// one mechanism (Kerberos, which is RFCs 1964 and 4121). --->// --->// https://tools.ietf.org/html/rfc4178 The above are my additions. int --->krb5_to_spnego(gss_buffer_t input, gss_buffer_t output) I've still got to review this carefully. { int len = (int)input->length; if (len > 60000) { // Too long, need 3 bytes DER length return 0; } // Just enough for a token with 2-bytes length int maxLen = len + 43; ---> char* buffer = new char[maxLen]; More non-C C++ (new not malloc()/calloc()) -- you don't have to make this C, but there's no need to keep the extern "C" if you don't, right? memcpy_s(buffer + maxLen - len, len, input->value, len); char* pos = buffer + maxLen - len; ---> It might be nice to explain that we're encoding from right to left. I know, it was obvious to me. It's also good to explain that we're excluding the mechListMIC field of NegTokenInit (which is OPTIONAL) because it's not needed when we only offer one mechanism. // mechToken [2] OCTET STRING OPTIONAL, ---> add_der_head(&pos, &len, len, 4); ---> add_der_head(&pos, &len, len, 0xA2); This deserves some explanation. RFC 4178 says that SPNEGO uses DER and EXPLICIT tagging, which means we get two tag-lengths here: one for the Kerberos mechanism token as an OCTET STRING, which is tagged as [UNIVERSAL 4], and one for the mechToken field's explicit tag from the NegTokenInit SEQUENCE from RFC 4178, which is tagged as [CONTEXT 2]. My variant of add_der_head() would make the tag class and tag (and constructed vs. primitive) all much more readable. Obviously, if you take my variant of add_der_head() and add_data(), then you'll need to check whether they return 0 or 1. However, you could check just the last call's return value because it doesn't matter if the all fail -- the last one can only succeed if the all succeeded. Also worth noting: we're skipping the reqFlags field of NegTokenInit, which is OPTIONAL. // mechTypes [0] MechTypeList, add_data(&pos, &len, (char*)KRB5_OID.elements, KRB5_OID.length); ---> add_der_head(&pos, &len, KRB5_OID.length, 6); Do note in a comment that this is the OBJECT IDENTIFIER [UNIVERSAL 6] tag. ---> add_der_head(&pos, &len, KRB5_OID.length + 2, 0x30); This is the SEQUENCE [UNIVERSAL 16] tag. The + 2 should really be + length returned by my version of add_der_head(). ---> add_der_head(&pos, &len, KRB5_OID.length + 4, 0xA0); This is the [CONTEXT 0] tag of the mechTypes field of NegTokenInit. // NegTokenInit ::= SEQUENCE { ... } add_der_head(&pos, &len, len, 0x30); Now I understand why your add_der_head() outputs the new length of the data. With my version you'd be doing: len += add_der_head(&pos, &plen, len, 0, CONTEXT, 0); ---> // negTokenInit [0] NegTokenInit, add_der_head(&pos, &len, len, 0xA0); Nice comment. Yeah, this is the negTokenInit arm of the NegotiationToken CHOICE. ---> // [APPLICATION 0] IMPLICIT SEQUENCE { // thisMech MechType, // innerContextToken ANY DEFINED BY thisMech This should say that this that is from RFC 2743, section 3.1. add_data(&pos, &len, (char*)SPNEGO_OID.elements, SPNEGO_OID.length); add_der_head(&pos, &len, SPNEGO_OID.length, 6); add_der_head(&pos, &len, len, 0x60); if (len != maxLen) { char* result = new char[len]; memcpy_s(result, len, buffer + maxLen - len, len); delete[] buffer; buffer = result; } output->value = buffer; output->length = len; return 1; } OK, I've read the SPNEGO code. That took hours to double check. I would very much prefer a safer add_der_head(). Please feel free to fixup my version and use it. // Skip ASN.1 tag and length bytes // // [in, out] data: An ASN.1 encoding. Head moved to data after call. --->// Returns the length value s/ value/ of the value/ --->int I would prefer that this be a size_t and that on error this return 0 (since the DER tag and length can never be fewer than two bytes, zero is a perfectly valid indication of failure by a function whose job is to parse a DER tag and length. --->skip_tag_len(char** data) This function absolutely must take a `size_t' argument that is the length of the buffer pointed to by `*data', and the function body *must* check this length as it goes. If the encoded length can be decoded but the rest of the buffer is not long enough to contain a payload of the encoded value length, then this function *must* fail. This is why I'm very suspicious of hand-coded DER codecs. It's extremely difficult to get right. I've spent three plus hours reading ~1.5Kloc (16%) of sspi.cpp because that's how carefully one has to read hand-coded DER codecs. You might consider using the Heimdal ASN.1 compiler and library... An alternative would be to rototill the Java side of the JGSS stack to support Java-coded SPNEGO with JNI GSS/Kerberos. That would require first accepting and pushing our contribution. { char* pos = *data; ---> pos++; You really have to decode the tag byte so you can know how many bytes the tag takes up. Assume a malicious peer. int n = *pos & 0xff; Here it's find to not have more correct DER length decoding: the response token should never be very large at all and it's OK to return an error when they are. if (n < 128) { pos++; } else if (n == 0x81) { pos++; n = *pos & 0xff; pos++; } else if (n == 0x82) { pos++; n = *pos & 0xff; pos++; n = (n << 8) | (*pos & 0xff); pos++; } else { return -1; } *data = pos; return n; } // Extract a krb5 token from a NegTokenResp. Returns the negState, // or -1 if there is no negState. int spnego_to_krb5(gss_buffer_t input, gss_buffer_t output) { int result = -1; ---> char* data = (char*)input->value; It's worth noting that we parse left to right -- the opposite of how we encode. ---> skip_tag_len(&data); ---> skip_tag_len(&data); You *really* have to check for errors every time you parse data fed to you by an attacker. Not checking is not an option. ---> while (data - (char*)input->value < (int)input->length) { This loop is looking for the responseToken field of NegTokenResp. But a loop is not appropriate. This is a SEQUENCE, so look for the negState field, then the supportedMech field, and so on. Yes, they are optional. I would much prefer this sort of code: /* Skip negState */ if (/* check that *data points to at least one byte */ && *data == (char)0xA0) { if (skip_tag_len(&data, &datalen) == 0) goto fail; /* or whatever */ } /* Skip supportedMech */ if (/* check that *data points to at least one byte */ && *data == (char)0xA1) { if (skip_tag_len(&data, &datalen) == 0) goto fail; /* or whatever */ } if (/* check that *data points to at least one byte */ && *data != (char)0xA2) goto fail; /* responseToken is missing! */ output->length = skip_tag_len(&data, &datalen); if (output->length == 0) goto fail; output->value = data; ... Back to your code: if (*data == (char)0xA2) { ---> skip_tag_len(&data); See above. output->length = skip_tag_len(&data); output->value = data; ---> if (input->length - ((char*)output->value - (char*)input->value) < output->length) { // inner token has a length field longer than outer token break; This will be unnecessary with my variant above. } return result; ---> } else { This too. if (*data == (char)0xA0) { result = data[4]; } int tagAndLen = skip_tag_len(&data); data += tagAndLen; } } output->length = 0; output->value = NULL; return result; } That's it for today. That's about 16% of the way through. Nico -- From weijun.wang at oracle.com Wed Dec 12 01:18:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Dec 2018 09:18:19 +0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe In-Reply-To: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> References: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> Message-ID: <3F77EFF1-59E4-4214-BB02-3CD6061DC244@oracle.com> Hi Valerie, > On Dec 12, 2018, at 6:21 AM, Valerie Peng wrote: > > Hi Max, > > > > - Comments (line 60-63) missed SHA224withECDSA? Oops. > > - Line 430: should be "ECPublicKey" Oops again. > > - Line 919, 922: is it really necessary to have two methods with algorithm name argument? It seems they are functionally the same but one calls CAPI vs CNG. Can they be merged? Yes. > > > > - generateECBlob() method (line 110-148), is the extra 1 due to the sign bit added by the BigInteger.toByteArray()? I recall BigInteger adds an extra 00 byte sometimes to indicate the positive value, but why is there an extra 1? Are the bytes for x, y, bs longer than the allocated "keyLen" length? You're right. I was thinking about the sign bit but got it wrong. > > > > - line 627, shouldn't 'C' be at buffer[1]? If not, what is at buffer[1]? len value is not checked, not sure how useful it is. It's a Unicode algorithm name, so buffer[1] is zero. I didn't check len because 32 is always enough for an algorithm name and there are at least 3 bytes there. Thanks, Max > > Thanks, > > Valerie > > On 12/3/2018 7:14 AM, Weijun Wang wrote: >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ >> >> A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. >> >> Not supported: >> >> 1. No EC KeyPairGenerator yet. >> >> 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. >> >> 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. >> >> 4. NONEwithECDSA not supported. >> >> Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. >> >> Thanks >> Max >> From sha.jiang at oracle.com Wed Dec 12 07:35:04 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 12 Dec 2018 15:35:04 +0800 Subject: RFR[12] JDK-8214520: [TEST_BUG] sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java failed with incorrect jtreg tags order Message-ID: Hi, When run this test on Windows, jtreg complains that '@library' must appear before first action tag. So, just adjust the tag positions. Issue: https://bugs.openjdk.java.net/browse/JDK-8214520 diff -r a6182c464b31 test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java --- a/test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java Wed Dec 12 10:13:11 2018 +0530 +++ b/test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java Wed Dec 12 15:32:06 2018 +0800 @@ -23,11 +23,11 @@ ?/* ? * @test - * @ignore Uses certutil.exe that isn't guaranteed to be installed ? * @bug 6483657 8154113 ? * @requires os.family == "windows" ? * @library /test/lib ? * @summary Test "keytool -list" displays correctly same named certificates + * @ignore Uses certutil.exe that isn't guaranteed to be installed ? */ ?import jdk.test.lib.process.ProcessTools; Best regards, John Jiang From norman.maurer at googlemail.com Wed Dec 12 07:59:53 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 12 Dec 2018 08:59:53 +0100 Subject: Possible bug in SSLEngine / SSLSession implementation Message-ID: Hi all, While working on some unit tests in netty I noticed that there may be a bug in the JDK implementation of SSLEngine / SSLSession. If its not a but it is at least surprising I would say. So it seems like before the handshake all values that are set on the SSLSession via putValue are shared across SSLEngine instances. Is this by design or a bug ? I could not find anything I the java docs that would tell me this is by design. It only states: "Until the initial handshake has completed, this method returns a session object which reports an invalid cipher suite of ?SSL_NULL_WITH_NULL_NULL?. This does not sound like it will be the same object every time and so it would share the values. You can find a reproducer which will throw an exception here: https://github.com/normanmaurer/jdk_ssl_session_reproducer I did reproduce this with the latest java8 and java11 releases but I am almost sure it also exists in other versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 12 10:09:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 10:09:31 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> <73833f4b-6586-01a7-4654-ffdfaccf441b@oracle.com> Message-ID: On 11/12/2018 20:00, Sean Mullan wrote: > > These exceptions are generated from a very low level part of the > native JDK Windows or Unix FileSystem implementations. That is a > concern. The previous usages of this property were more focused and > confined to smaller parts of the code resulting in fewer code paths to > analyze. > > I think we need to take a step back. I think we need to reconsider > whether the jdk.includeInExceptions security property is appropriate > for this type of enhancement. > > Therefore, I oppose this change as-is. I'm happy to participate in a > more involved discussion where we start with use cases and motivation > before jumping to solutions. I also dislike this patch and you are probably right that jdk.includeInExceptions needs to be re-examined or pulled out completely. In addition to the surprise leakage issue, this patch is inconsistent as it hanges the exception for only a subset of the file system operations. -Alan From jamil.j.nimeh at oracle.com Wed Dec 12 14:35:37 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 12 Dec 2018 06:35:37 -0800 Subject: Possible bug in SSLEngine / SSLSession implementation In-Reply-To: References: Message-ID: <4dd3a000-de8c-c49c-98b8-553ef247812b@oracle.com> Hi Norman, the new handshaker does return a new SSLSession object. Part of JDK-8212885 fixes the lack of propagation of session values across session objects, though that fix was largely in the context of TLS 1.3.? There is a backport set for it, but it is not yet complete as far as I'm aware.? Are you doing TLS 1.3 sessions?? If so, are you able to try it with the latest JDK? One of the items we're going to be tacking soon is better TLS session object management and new session ticket management so we can avoid these value propagation issues in the future. --Jamil On 12/11/2018 11:59 PM, Norman Maurer wrote: > Hi all, > > While working on some unit tests in netty I noticed that there may be > a bug in the JDK implementation of SSLEngine / SSLSession. If its not > a but it is at least surprising I would say. > > > So it seems like before the handshake all values that are set on the > SSLSession via putValue are shared across SSLEngine instances. Is this > by design or a bug ? I could not find anything I the java docs that > would tell me this is by design. It only states: "Until the initial > handshake has completed, this method returns a session object which > reports an invalid cipher suite of??SSL_NULL_WITH_NULL_NULL?. This > does not sound like it will be the same object every time and so it > would share the values. > > You can find a reproducer which will throw an exception here: > > https://github.com/normanmaurer/jdk_ssl_session_reproducer > > > I did reproduce this with the latest java8 and java11 releases but I > am almost sure it also exists in other versions. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Dec 12 14:40:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Dec 2018 22:40:55 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <52708621-F7B5-4231-A925-651FE101518D@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> Message-ID: <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> The latest webrev is at https://cr.openjdk.java.net/~weijun/8076190/webrev.07 The major change since webrev.05 is that the properties are no longer read into static fields, they are read on-demand. This means they will never be read if store() is not called. I've also added more test cases. Thanks, Max > On Oct 8, 2018, at 11:26 PM, Weijun Wang wrote: > > CSR updated. Please take a review. > > https://bugs.openjdk.java.net/browse/JDK-8202590 > > A slightly updated webrev at > > https://cr.openjdk.java.net/~weijun/8076190/webrev.05 > > Thanks > Max > >> On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: >> >> On 10/1/18 8:02 PM, Weijun Wang wrote: >>> >>> >>>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: >>>> >>>> Looks good. After you update the CSR with these changes, I can review it. >>> >>> Sure. >>> >>> How do you think of the following change? Shall I also add it? >> >> Yes. >>> >>> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java >>> --- a/src/java.base/share/classes/java/security/KeyStore.java >>> +++ b/src/java.base/share/classes/java/security/KeyStore.java >>> @@ -318,7 +318,7 @@ >>> * for a given keystore type is set using the >>> * {@code 'keystore..keyProtectionAlgorithm'} security property. >>> * For example, the >>> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the >>> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the >>> * name of the default key protection algorithm used for PKCS12 >>> * keystores. If the security property is not set, an >>> * implementation-specific algorithm will be used. >>> >>> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? >> No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. >> >> --Sean >>> >>> If yes, there will also be some text for its compatibility risk. >>> >>> Thanks >>> Max >>> >>>> >>>> --Sean >>>> >>>> On 9/28/18 9:36 AM, Weijun Wang wrote: >>>>> Webrev updated at >>>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>>>> Major changes: >>>>> 1. Comment out key=value lines in java.security >>>>> 2. Fix a bug in PBES2Parameters.java >>>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >>>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >>>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>>>> Thanks >>>>> Max >>> >>> > From norman.maurer at googlemail.com Wed Dec 12 14:42:58 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 12 Dec 2018 15:42:58 +0100 Subject: Possible bug in SSLEngine / SSLSession implementation In-Reply-To: <4dd3a000-de8c-c49c-98b8-553ef247812b@oracle.com> References: <4dd3a000-de8c-c49c-98b8-553ef247812b@oracle.com> Message-ID: Hi Jamil, This was just noticed during a test which uses TLS1.2. > On 12. Dec 2018, at 15:35, Jamil Nimeh wrote: > > Hi Norman, the new handshaker does return a new SSLSession object. Part of JDK-8212885 fixes the lack of propagation of session values across session objects, though that fix was largely in the context of TLS 1.3. There is a backport set for it, but it is not yet complete as far as I'm aware. Are you doing TLS 1.3 sessions? If so, are you able to try it with the latest JDK? > > One of the items we're going to be tacking soon is better TLS session object management and new session ticket management so we can avoid these value propagation issues in the future. > > --Jamil > > On 12/11/2018 11:59 PM, Norman Maurer wrote: >> Hi all, >> >> While working on some unit tests in netty I noticed that there may be a bug in the JDK implementation of SSLEngine / SSLSession. If its not a but it is at least surprising I would say. >> >> >> So it seems like before the handshake all values that are set on the SSLSession via putValue are shared across SSLEngine instances. Is this by design or a bug ? I could not find anything I the java docs that would tell me this is by design. It only states: "Until the initial handshake has completed, this method returns a session object which reports an invalid cipher suite of ?SSL_NULL_WITH_NULL_NULL?. This does not sound like it will be the same object every time and so it would share the values. >> >> You can find a reproducer which will throw an exception here: >> >> https://github.com/normanmaurer/jdk_ssl_session_reproducer >> >> >> I did reproduce this with the latest java8 and java11 releases but I am almost sure it also exists in other versions. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Dec 12 15:01:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Dec 2018 10:01:13 -0500 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> Message-ID: <5940fc0f-cf42-5fe8-3c59-7e386e8d02d4@oracle.com> Looks good. --Sean On 12/12/18 9:40 AM, Weijun Wang wrote: > The latest webrev is at > > https://cr.openjdk.java.net/~weijun/8076190/webrev.07 > > The major change since webrev.05 is that the properties are no longer read into static fields, they are read on-demand. This means they will never be read if store() is not called. > > I've also added more test cases. > > Thanks, > Max > > >> On Oct 8, 2018, at 11:26 PM, Weijun Wang wrote: >> >> CSR updated. Please take a review. >> >> https://bugs.openjdk.java.net/browse/JDK-8202590 >> >> A slightly updated webrev at >> >> https://cr.openjdk.java.net/~weijun/8076190/webrev.05 >> >> Thanks >> Max >> >>> On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: >>> >>> On 10/1/18 8:02 PM, Weijun Wang wrote: >>>> >>>> >>>>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: >>>>> >>>>> Looks good. After you update the CSR with these changes, I can review it. >>>> >>>> Sure. >>>> >>>> How do you think of the following change? Shall I also add it? >>> >>> Yes. >>>> >>>> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java >>>> --- a/src/java.base/share/classes/java/security/KeyStore.java >>>> +++ b/src/java.base/share/classes/java/security/KeyStore.java >>>> @@ -318,7 +318,7 @@ >>>> * for a given keystore type is set using the >>>> * {@code 'keystore..keyProtectionAlgorithm'} security property. >>>> * For example, the >>>> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the >>>> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the >>>> * name of the default key protection algorithm used for PKCS12 >>>> * keystores. If the security property is not set, an >>>> * implementation-specific algorithm will be used. >>>> >>>> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? >>> No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. >>> >>> --Sean >>>> >>>> If yes, there will also be some text for its compatibility risk. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> --Sean >>>>> >>>>> On 9/28/18 9:36 AM, Weijun Wang wrote: >>>>>> Webrev updated at >>>>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>>>>> Major changes: >>>>>> 1. Comment out key=value lines in java.security >>>>>> 2. Fix a bug in PBES2Parameters.java >>>>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >>>>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >>>>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>>>>> Thanks >>>>>> Max >>>> >>>> >> > From weijun.wang at oracle.com Wed Dec 12 15:57:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Dec 2018 23:57:13 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <5940fc0f-cf42-5fe8-3c59-7e386e8d02d4@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> <5940fc0f-cf42-5fe8-3c59-7e386e8d02d4@oracle.com> Message-ID: <50097F7C-B78A-4B62-B4D3-54C7B3738DA9@oracle.com> Thanks. Will you please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8215293? --Max > On Dec 12, 2018, at 11:01 PM, Sean Mullan wrote: > > Looks good. > > --Sean > > On 12/12/18 9:40 AM, Weijun Wang wrote: >> The latest webrev is at >> https://cr.openjdk.java.net/~weijun/8076190/webrev.07 >> The major change since webrev.05 is that the properties are no longer read into static fields, they are read on-demand. This means they will never be read if store() is not called. >> I've also added more test cases. >> Thanks, >> Max >>> On Oct 8, 2018, at 11:26 PM, Weijun Wang wrote: >>> >>> CSR updated. Please take a review. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8202590 >>> >>> A slightly updated webrev at >>> >>> https://cr.openjdk.java.net/~weijun/8076190/webrev.05 >>> >>> Thanks >>> Max >>> >>>> On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: >>>> >>>> On 10/1/18 8:02 PM, Weijun Wang wrote: >>>>> >>>>> >>>>>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: >>>>>> >>>>>> Looks good. After you update the CSR with these changes, I can review it. >>>>> >>>>> Sure. >>>>> >>>>> How do you think of the following change? Shall I also add it? >>>> >>>> Yes. >>>>> >>>>> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java >>>>> --- a/src/java.base/share/classes/java/security/KeyStore.java >>>>> +++ b/src/java.base/share/classes/java/security/KeyStore.java >>>>> @@ -318,7 +318,7 @@ >>>>> * for a given keystore type is set using the >>>>> * {@code 'keystore..keyProtectionAlgorithm'} security property. >>>>> * For example, the >>>>> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the >>>>> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the >>>>> * name of the default key protection algorithm used for PKCS12 >>>>> * keystores. If the security property is not set, an >>>>> * implementation-specific algorithm will be used. >>>>> >>>>> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? >>>> No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. >>>> >>>> --Sean >>>>> >>>>> If yes, there will also be some text for its compatibility risk. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>> --Sean >>>>>> >>>>>> On 9/28/18 9:36 AM, Weijun Wang wrote: >>>>>>> Webrev updated at >>>>>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>>>>>> Major changes: >>>>>>> 1. Comment out key=value lines in java.security >>>>>>> 2. Fix a bug in PBES2Parameters.java >>>>>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >>>>>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >>>>>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>>>>>> Thanks >>>>>>> Max >>>>> >>>>> >>> From claes.redestad at oracle.com Wed Dec 12 16:53:11 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 17:53:11 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base Message-ID: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Hi, please review this patch to use String.isEmpty when applicable: Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Why? - It reads better :-) - Better startup/warmup due fewer method invocations - Better peak performance: String.isEmpty is ~1.2x faster than String.length Most changes are simple search and replace, but I took the liberty to clean out some dead/pointless uses and improve formatting in places due the shorter expression length. Instances of "".equals(string) were only changed when it was immediately obvious that string is not null, e.g., due a preceding null check. Thanks! /Claes From daniel.fuchs at oracle.com Wed Dec 12 16:54:29 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Dec 2018 16:54:29 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Hi Claes, It might read even better if things like: + resultString = !specarg.isEmpty() ? specarg.intern(): opt; were changed into: + resultString = specarg.isEmpty() ? opt : specarg.intern(); best regards, -- daniel On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. > > Thanks! > > /Claes From Alan.Bateman at oracle.com Wed Dec 12 16:56:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 16:56:17 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. In Checks.java, the parameter change from CharSequence to String means that "cs" needs to be renamed. -Alan. From claes.redestad at oracle.com Wed Dec 12 17:04:33 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:04:33 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <10eafdbe-f524-2534-3bea-3744c06fbc81@oracle.com> On 2018-12-12 17:56, Alan Bateman wrote: > In Checks.java, the parameter change from CharSequence to String means > that "cs" needs to be renamed. Changed to 'str' /Claes From claes.redestad at oracle.com Wed Dec 12 17:06:24 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:06:24 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Message-ID: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> On 2018-12-12 17:54, Daniel Fuchs wrote: > Hi Claes, > > It might read even better if things like: > > +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; > > were changed into: > > +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); > > best regards, I only found this pattern in this file, so incremental diff will look like the below. I will update in place due hugeness of webrev. Thanks! /Claes diff -r 732b03e40349 src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 17:41:46 2018 +0100 +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 18:03:57 2018 +0100 @@ -641,10 +641,10 @@ String specarg = spec.substring(sidx); switch (specop) { case '.': // terminate the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): opt; + resultString = specarg.isEmpty() ? opt : specarg.intern(); break doArgs; case '?': // abort the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): arg; + resultString = specarg.isEmpty() ? arg : specarg.intern(); isError = true; break eachSpec; case '@': // change the effective opt name @@ -655,7 +655,7 @@ val = ""; break; case '!': // negation option - String negopt = !specarg.isEmpty() ? specarg.intern(): opt; + String negopt = specarg.isEmpty() ? opt : specarg.intern(); properties.remove(negopt); properties.put(negopt, null); // leave placeholder didAction = true; From xuelei.fan at oracle.com Wed Dec 12 18:12:04 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 12 Dec 2018 10:12:04 -0800 Subject: RFR[12] JDK-8214520: [TEST_BUG] sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java failed with incorrect jtreg tags order In-Reply-To: References: Message-ID: <5d63df4a-4790-e97a-b1d4-372914f38e17@oracle.com> looks fine to me. thanks, xuelei On 12/11/2018 11:35 PM, sha.jiang at oracle.com wrote: > Hi, > When run this test on Windows, jtreg complains that '@library' must > appear before first action tag. > So, just adjust the tag positions. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8214520 > > diff -r a6182c464b31 > test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java > --- > a/test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java > Wed Dec 12 10:13:11 2018 +0530 > +++ > b/test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java > Wed Dec 12 15:32:06 2018 +0800 > @@ -23,11 +23,11 @@ > > ?/* > ? * @test > - * @ignore Uses certutil.exe that isn't guaranteed to be installed > ? * @bug 6483657 8154113 > ? * @requires os.family == "windows" > ? * @library /test/lib > ? * @summary Test "keytool -list" displays correctly same named > certificates > + * @ignore Uses certutil.exe that isn't guaranteed to be installed > ? */ > > ?import jdk.test.lib.process.ProcessTools; > > Best regards, > John Jiang > From valerie.peng at oracle.com Wed Dec 12 19:48:26 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 12 Dec 2018 11:48:26 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> Message-ID: <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> If anyone is still reviewing this and need more time, please let me know soon. Otherwise, I will proceed with integration this afternoon. Thanks, Valerie On 12/6/2018 7:27 PM, Valerie Peng wrote: > Hi Sean, > > Thanks for your review, I have removed the stale comment from the > VerificationProvider. > > As for your concern on race condition, legacyChanged and the > String/String legacy mapping are still synchronized on the provider > object. Only the service mapping is managed by the ConcurrentHashMap. > I have also changed serviceChanged to be volatile. For those methods > which no longer have synchronized keywords, they still have > synchronized blocks around the legacy mapping related code. In > general, the provider mappings are populated during construction time > and rarely updated afterwards. In addition, most if not all, they > either use all legacy or all service. The mixing of them makes the > code un-necessarily complicated, oh-well. > > Latest webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.01 > > Valerie > > On 12/4/2018 2:29 PM, Sean Mullan wrote: >> I haven't reviewed all of this, but had a couple of comments so far: >> >> - VerificationProvider.java >> >> 77???????? // the provider. Otherwise, create a temporary map and use a >> >> This comment is now stale so it needs to be removed/updated. >> >> - Provider.java >> >> You removed synchronized from several of the methods, but some of >> those methods modified fields such as servicesChanged and >> legacyChanged. Are there any concurrency issues or race conditions >> now that those methods are not synchronized? >> >> --Sean >> >> >> On 11/21/18 1:05 PM, Valerie Peng wrote: >>> Hi, >>> >>> Can someone help reviewing this fix? >>> >>> Besides changing the Provider class to use ConcurrentHashMap in >>> order to reduce the lock contention on Provider.getService() calls, >>> I also changed the security providers in java.base module to >>> register through putService(...) calls. Performance is manually >>> verified and mach5 run is clean. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 >>> Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ >>> >>> Thanks, >>> Valerie >>> >>> >>> >>> >>> From valerie.peng at oracle.com Wed Dec 12 22:20:24 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 12 Dec 2018 14:20:24 -0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: Hi Max, - the DER related code is very hard to read... Would be nice to use constants/enum for commonly used tag or use some method to construct them. - line 449, I think you mean to use "c" instead of "cred_handle" - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable naming convention starts with lower case? the argument qop_state may be non-null but is not set?|| - gss_indicate_mechs: the SSPI docs that I found mentioned that you need to call FreeContextBuffer on pkgInfo after calling QuerySecurityPackageInfo(). Local variable "minor" not used and can be removed? - gss_inquire_names_for_mech: why does the PP output has "IMPLEMENTED" wording, other methods do not. Is this intentional? - gss_create_empty_oid_set: do we need to check the specified oid_set for existing content and free if not-empty before wiping it out? This is called by a few other gss api methods also, it may be better to defend against user errors. - gss_add_oid_set_member: add "const" to the 2nd argument? - gss_release_buffer: maybe set buffer->length = 0 outside the if-block. Do we need to check for GSS_C_NO_BUFFER in addition to null? - gss_display_status: add "const" to the 4th argument? As for the impl, I have a question, this particular method is for displaying text output for gssapi error codes, but the FormatMessage() call takes window specific message id. Are they the same? I am still going through the rest of sspi.cpp, but thought that I will send you what I have first. Good that you have this targeted to 13 as there is almost no time left for RFEs to get into JDK12. Thanks, Valerie On 11/19/2018 5:56 PM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ > > We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. > > No regression tests included. A Windows Active Directory server is needed. > > Thanks > Max > > [1]https://bugs.openjdk.java.net/browse/JDK-8200468 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Dec 13 00:55:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Dec 2018 08:55:59 +0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe In-Reply-To: <3F77EFF1-59E4-4214-BB02-3CD6061DC244@oracle.com> References: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> <3F77EFF1-59E4-4214-BB02-3CD6061DC244@oracle.com> Message-ID: <6A9D04D7-5538-4661-859A-8F20BE53392A@oracle.com> Hi Valerie, The updated webrev is at https://cr.openjdk.java.net/~weijun/8213010/webrev.01/ I haven't merged importPublicKey and importECPublicKey because the content is so different and we expect someday to remove the CAPI method at all. The interdiff.patch has some problem since I haven't really changed SunMSCAPI.java. Maybe a bug of the interdiff tool. Thanks Max > On Dec 12, 2018, at 9:18 AM, Weijun Wang wrote: > > Hi Valerie, > >> On Dec 12, 2018, at 6:21 AM, Valerie Peng wrote: >> >> Hi Max, >> >> >> >> - Comments (line 60-63) missed SHA224withECDSA? > > Oops. > >> >> - Line 430: should be "ECPublicKey" > > Oops again. > >> >> - Line 919, 922: is it really necessary to have two methods with algorithm name argument? It seems they are functionally the same but one calls CAPI vs CNG. Can they be merged? > > Yes. > >> >> >> >> - generateECBlob() method (line 110-148), is the extra 1 due to the sign bit added by the BigInteger.toByteArray()? I recall BigInteger adds an extra 00 byte sometimes to indicate the positive value, but why is there an extra 1? Are the bytes for x, y, bs longer than the allocated "keyLen" length? > > You're right. I was thinking about the sign bit but got it wrong. > >> >> >> >> - line 627, shouldn't 'C' be at buffer[1]? If not, what is at buffer[1]? len value is not checked, not sure how useful it is. > > It's a Unicode algorithm name, so buffer[1] is zero. I didn't check len because 32 is always enough for an algorithm name and there are at least 3 bytes there. > > Thanks, > Max > >> >> Thanks, >> >> Valerie >> >> On 12/3/2018 7:14 AM, Weijun Wang wrote: >>> Please take a review at >>> >>> https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ >>> >>> A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. >>> >>> Not supported: >>> >>> 1. No EC KeyPairGenerator yet. >>> >>> 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. >>> >>> 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. >>> >>> 4. NONEwithECDSA not supported. >>> >>> Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. >>> >>> Thanks >>> Max >>> > From valerie.peng at oracle.com Thu Dec 13 02:07:30 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 12 Dec 2018 18:07:30 -0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe In-Reply-To: <6A9D04D7-5538-4661-859A-8F20BE53392A@oracle.com> References: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> <3F77EFF1-59E4-4214-BB02-3CD6061DC244@oracle.com> <6A9D04D7-5538-4661-859A-8F20BE53392A@oracle.com> Message-ID: <8e3277b0-62bd-96c7-cafb-f38e85e677aa@oracle.com> The updated webrev looks fine. Would prefer to have importPublicKey and importECPublicKey methods merged as other methods do. But not a deal breaker as it does not affect functionality. Also, would be nice to use a http URL for the EC public key blob format. Thanks, Valerie On 12/12/2018 4:55 PM, Weijun Wang wrote: > Hi Valerie, > > The updated webrev is at > > https://cr.openjdk.java.net/~weijun/8213010/webrev.01/ > > I haven't merged importPublicKey and importECPublicKey because the content is so different and we expect someday to remove the CAPI method at all. > > The interdiff.patch has some problem since I haven't really changed SunMSCAPI.java. Maybe a bug of the interdiff tool. > > Thanks > Max > >> On Dec 12, 2018, at 9:18 AM, Weijun Wang wrote: >> >> Hi Valerie, >> >>> On Dec 12, 2018, at 6:21 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> >>> >>> - Comments (line 60-63) missed SHA224withECDSA? >> Oops. >> >>> - Line 430: should be "ECPublicKey" >> Oops again. >> >>> - Line 919, 922: is it really necessary to have two methods with algorithm name argument? It seems they are functionally the same but one calls CAPI vs CNG. Can they be merged? >> Yes. >> >>> >>> >>> - generateECBlob() method (line 110-148), is the extra 1 due to the sign bit added by the BigInteger.toByteArray()? I recall BigInteger adds an extra 00 byte sometimes to indicate the positive value, but why is there an extra 1? Are the bytes for x, y, bs longer than the allocated "keyLen" length? >> You're right. I was thinking about the sign bit but got it wrong. >> >>> >>> >>> - line 627, shouldn't 'C' be at buffer[1]? If not, what is at buffer[1]? len value is not checked, not sure how useful it is. >> It's a Unicode algorithm name, so buffer[1] is zero. I didn't check len because 32 is always enough for an algorithm name and there are at least 3 bytes there. >> >> Thanks, >> Max >> >>> Thanks, >>> >>> Valerie >>> >>> On 12/3/2018 7:14 AM, Weijun Wang wrote: >>>> Please take a review at >>>> >>>> https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ >>>> >>>> A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. >>>> >>>> Not supported: >>>> >>>> 1. No EC KeyPairGenerator yet. >>>> >>>> 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. >>>> >>>> 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. >>>> >>>> 4. NONEwithECDSA not supported. >>>> >>>> Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. >>>> >>>> Thanks >>>> Max >>>> From weijun.wang at oracle.com Thu Dec 13 02:12:24 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Dec 2018 10:12:24 +0800 Subject: RFR 8213010: [cng] Supporting keys created with certmgr.exe In-Reply-To: <8e3277b0-62bd-96c7-cafb-f38e85e677aa@oracle.com> References: <26a91a52-cb60-aeec-f627-343d2f3232ff@oracle.com> <3F77EFF1-59E4-4214-BB02-3CD6061DC244@oracle.com> <6A9D04D7-5538-4661-859A-8F20BE53392A@oracle.com> <8e3277b0-62bd-96c7-cafb-f38e85e677aa@oracle.com> Message-ID: > On Dec 13, 2018, at 10:07 AM, Valerie Peng wrote: > > > The updated webrev looks fine. > > Would prefer to have importPublicKey and importECPublicKey methods merged as other methods do. But not a deal breaker as it does not affect functionality. > > Also, would be nice to use a http URL for the EC public key blob format. I've updated it to https://docs.microsoft.com/en-us/windows/desktop/api/bcrypt/ns-bcrypt-_bcrypt_ecckey_blob in my local repo. Thanks for catching it. --Max > > Thanks, > Valerie > > > On 12/12/2018 4:55 PM, Weijun Wang wrote: >> Hi Valerie, >> >> The updated webrev is at >> >> https://cr.openjdk.java.net/~weijun/8213010/webrev.01/ >> >> I haven't merged importPublicKey and importECPublicKey because the content is so different and we expect someday to remove the CAPI method at all. >> >> The interdiff.patch has some problem since I haven't really changed SunMSCAPI.java. Maybe a bug of the interdiff tool. >> >> Thanks >> Max >> >>> On Dec 12, 2018, at 9:18 AM, Weijun Wang wrote: >>> >>> Hi Valerie, >>> >>>> On Dec 12, 2018, at 6:21 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> >>>> >>>> - Comments (line 60-63) missed SHA224withECDSA? >>> Oops. >>> >>>> - Line 430: should be "ECPublicKey" >>> Oops again. >>> >>>> - Line 919, 922: is it really necessary to have two methods with algorithm name argument? It seems they are functionally the same but one calls CAPI vs CNG. Can they be merged? >>> Yes. >>> >>>> >>>> >>>> - generateECBlob() method (line 110-148), is the extra 1 due to the sign bit added by the BigInteger.toByteArray()? I recall BigInteger adds an extra 00 byte sometimes to indicate the positive value, but why is there an extra 1? Are the bytes for x, y, bs longer than the allocated "keyLen" length? >>> You're right. I was thinking about the sign bit but got it wrong. >>> >>>> >>>> >>>> - line 627, shouldn't 'C' be at buffer[1]? If not, what is at buffer[1]? len value is not checked, not sure how useful it is. >>> It's a Unicode algorithm name, so buffer[1] is zero. I didn't check len because 32 is always enough for an algorithm name and there are at least 3 bytes there. >>> >>> Thanks, >>> Max >>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> On 12/3/2018 7:14 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8213010/webrev.00/ >>>>> >>>>> A Windows keystore is now able to load EC keys and uses them in signing and verifying with SHAwithECDSA. >>>>> >>>>> Not supported: >>>>> >>>>> 1. No EC KeyPairGenerator yet. >>>>> >>>>> 2. Cannot store a EC key (from SunEC) into a Windows keystore. I still haven't figured out how to call NCryptImportKey, NCryptCreatePersistedKey and CertAddCertificateContextToStore together correctly to associate a EC private key to a cert and store them. >>>>> >>>>> 3. SHAwithECDSAinP1363Format not supported, but it's easy to add them. >>>>> >>>>> 4. NONEwithECDSA not supported. >>>>> >>>>> Currently I can only use certmgr.exe to import a pkcs12 file and then run a manual test with it. Therefore no automatic test is included. Like RSA support in SunMSCAPI, Signature::initSign only support native keys. Signature::initVerify supports both native and SunEC keys. That said, since we do not have EC KeyPairGenerator yet you won't meet a real native EC public key. >>>>> >>>>> Thanks >>>>> Max >>>>> From weijun.wang at oracle.com Thu Dec 13 02:25:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Dec 2018 10:25:19 +0800 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties In-Reply-To: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> References: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> Message-ID: <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> Ping again. This is an RFE so needs to be fixed today unless we request for an approval. Thanks, Max > On Dec 7, 2018, at 11:21 PM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8214568/webrev.00 > > Thanks > Max From sha.jiang at oracle.com Thu Dec 13 03:14:02 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 13 Dec 2018 11:14:02 +0800 Subject: RFR[12] JDK-8214937: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed due to unexpected expiration date Message-ID: <61cd50e8-1d79-14e4-3689-1e5a35699f7f@oracle.com> Hi, This test should determine the cert expiration date from the cert itself, but not try to calculate that date. Issue: https://bugs.openjdk.java.net/browse/JDK-8214937 Webrev: http://cr.openjdk.java.net/~jjiang/8214937/webrev.00/ Best regards, John Jiang From Xuelei.Fan at Oracle.Com Thu Dec 13 03:59:36 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 12 Dec 2018 19:59:36 -0800 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties In-Reply-To: <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> References: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> Message-ID: Looks fine to me. Xuelei > On Dec 12, 2018, at 6:25 PM, Weijun Wang wrote: > > Ping again. > > This is an RFE so needs to be fixed today unless we request for an approval. > > Thanks, > Max > >> On Dec 7, 2018, at 11:21 PM, Weijun Wang wrote: >> >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8214568/webrev.00 >> >> Thanks >> Max > From Xuelei.Fan at Oracle.Com Thu Dec 13 04:02:08 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 12 Dec 2018 20:02:08 -0800 Subject: RFR[12] JDK-8214937: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed due to unexpected expiration date In-Reply-To: <61cd50e8-1d79-14e4-3689-1e5a35699f7f@oracle.com> References: <61cd50e8-1d79-14e4-3689-1e5a35699f7f@oracle.com> Message-ID: <82BBEEDF-E2D8-4836-8FED-663FB1A1025A@Oracle.Com> Nice catch and looks good to me. Xuelei > On Dec 12, 2018, at 7:14 PM, sha.jiang at oracle.com wrote: > > Hi, > This test should determine the cert expiration date from the cert itself, but not try to calculate that date. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8214937 > Webrev: http://cr.openjdk.java.net/~jjiang/8214937/webrev.00/ > > Best regards, > John Jiang > From goetz.lindenmaier at sap.com Thu Dec 13 07:50:43 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Dec 2018 07:50:43 +0000 Subject: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR Message-ID: Hi, These tests lack @requires vm.hasJFR, thus they are failing on AIX. http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ Please review. I will push this to jdk12 as it is a testbug if I miss the RDP deadline. Best regards, Goetz. From sundararajan.athijegannathan at oracle.com Thu Dec 13 08:46:36 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 13 Dec 2018 14:16:36 +0530 Subject: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR In-Reply-To: References: Message-ID: <5C121C6C.7010204@oracle.com> Looks good. PS. I just checked that there are other tests with the same requires clause. -Sundar On 13/12/18, 1:20 PM, Lindenmaier, Goetz wrote: > Hi, > > These tests lack @requires vm.hasJFR, thus they are failing on AIX. > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ > > Please review. > I will push this to jdk12 as it is a testbug if I miss the RDP deadline. > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Thu Dec 13 08:38:49 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Dec 2018 08:38:49 +0000 Subject: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR In-Reply-To: <5C121C6C.7010204@oracle.com> References: <5C121C6C.7010204@oracle.com> Message-ID: <6d1b7054a36a47379aa2c5c8515bfc02@sap.com> Thanks Sundar! Best regards Goetz > -----Original Message----- > From: Sundararajan Athijegannathan > > Sent: Thursday, December 13, 2018 9:47 AM > To: Lindenmaier, Goetz > Cc: security-dev at openjdk.java.net; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: 8215534: [testbug] some jfr test don't check @requires > vm.hasJFR > > Looks good. > > PS. I just checked that there are other tests with the same requires clause. > > -Sundar > > On 13/12/18, 1:20 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > These tests lack @requires vm.hasJFR, thus they are failing on AIX. > > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ > > > > Please review. > > I will push this to jdk12 as it is a testbug if I miss the RDP deadline. > > > > Best regards, > > Goetz. > > From erik.gahlin at oracle.com Thu Dec 13 11:34:07 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 13 Dec 2018 12:34:07 +0100 Subject: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR In-Reply-To: References: Message-ID: <5C1243AF.6010100@oracle.com> Looks good. Erik > Hi, > > These tests lack @requires vm.hasJFR, thus they are failing on AIX. > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ > > Please review. > I will push this to jdk12 as it is a testbug if I miss the RDP deadline. > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Thu Dec 13 11:57:37 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Dec 2018 11:57:37 +0000 Subject: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR In-Reply-To: <5C1243AF.6010100@oracle.com> References: <5C1243AF.6010100@oracle.com> Message-ID: <3072253043ce4b218da8bf1b2173acea@sap.com> Thanks Erik! Pushed. Best regards, Goetz > -----Original Message----- > From: serviceability-dev On > Behalf Of Erik Gahlin > Sent: Thursday, December 13, 2018 12:34 PM > To: security-dev at openjdk.java.net; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: 8215534: [testbug] some jfr test don't check @requires > vm.hasJFR > > Looks good. > > Erik > > > Hi, > > > > These tests lack @requires vm.hasJFR, thus they are failing on AIX. > > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/ > > > > Please review. > > I will push this to jdk12 as it is a testbug if I miss the RDP deadline. > > > > Best regards, > > Goetz. > > From daniel.fuchs at oracle.com Thu Dec 13 13:06:07 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Dec 2018 13:06:07 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> Message-ID: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Looks good Claes! I eyeballed the rest of the patch and found nothing wrong - but with a patch this size it would be easy to miss something. Were you able to measure any improvement after patching? best regards, -- daniel On 12/12/2018 17:06, Claes Redestad wrote: > > > On 2018-12-12 17:54, Daniel Fuchs wrote: >> Hi Claes, >> >> It might read even better if things like: >> >> +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; >> >> were changed into: >> >> +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); >> >> best regards, > > I only found this pattern in this file, so incremental > diff will look like the below. I will update in place due hugeness of > webrev. > > Thanks! > > /Claes > > diff -r 732b03e40349 > src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 17:41:46 2018 +0100 > +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 18:03:57 2018 +0100 > @@ -641,10 +641,10 @@ > ???????????????????? String specarg = spec.substring(sidx); > ???????????????????? switch (specop) { > ???????????????????? case '.':? // terminate the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? resultString = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? break doArgs; > ???????????????????? case '?':? // abort the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): arg; > +??????????????????????? resultString = specarg.isEmpty() ? arg : > specarg.intern(); > ???????????????????????? isError = true; > ???????????????????????? break eachSpec; > ???????????????????? case '@':? // change the effective opt name > @@ -655,7 +655,7 @@ > ???????????????????????? val = ""; > ???????????????????????? break; > ???????????????????? case '!':? // negation option > -??????????????????????? String negopt = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? String negopt = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? properties.remove(negopt); > ???????????????????????? properties.put(negopt, null);? // leave > placeholder > ???????????????????????? didAction = true; From claes.redestad at oracle.com Thu Dec 13 13:17:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 13 Dec 2018 14:17:05 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Message-ID: <3917b2c2-127a-8ed2-dfec-fb4e1f4631f2@oracle.com> On 2018-12-13 14:06, Daniel Fuchs wrote: > Looks good Claes! Thanks! > I eyeballed the rest of the patch and found > nothing wrong - but with a patch this size > it would be easy to miss something. Yes, I've gone through it a couple of times now to be sure. > > Were you able to measure any improvement after > patching? There's a tiny reduction in bytecode executed in initPhase1, but on any real measures any improvement is in the noise. /Claes > > best regards, > > -- daniel From Roger.Riggs at oracle.com Thu Dec 13 14:33:05 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2018 09:33:05 -0500 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties In-Reply-To: References: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> Message-ID: Hi, Thanks for converting the package doc. There is XML commented text in the package-info.java that should be removed. It would show up in the javadoc. And there are links that can now use {@link}. It probably worth? % make docs-javadoc and checking the result in images/docs/api. Thanks, Roger p.s. Documentation and test issues p1-p5, can be fixed after RPD1. [1]?? https://openjdk.java.net/jeps/3 On 12/12/2018 10:59 PM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > >> On Dec 12, 2018, at 6:25 PM, Weijun Wang wrote: >> >> Ping again. >> >> This is an RFE so needs to be fixed today unless we request for an approval. >> >> Thanks, >> Max >> >>> On Dec 7, 2018, at 11:21 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> https://cr.openjdk.java.net/~weijun/8214568/webrev.00 >>> >>> Thanks >>> Max From weijun.wang at oracle.com Thu Dec 13 15:35:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Dec 2018 23:35:12 +0800 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties In-Reply-To: References: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> Message-ID: <6EFA18EC-6D2E-4F24-8A17-4C6211AA85D8@oracle.com> Hi Roger, I didn't run "make docs-javadoc" but I have a script that directly call the javadoc command. While the comment still exists in the output HTML, it is still a comment, and therefore invisible on the page. Can {@link} be used to link to a URL? I only know about using it to link to class and method names. Thanks, Max > On Dec 13, 2018, at 10:33 PM, Roger Riggs wrote: > > Hi, > > Thanks for converting the package doc. > > There is XML commented text in the package-info.java that should be removed. > It would show up in the javadoc. > > And there are links that can now use {@link}. > It probably worth % make docs-javadoc and checking the result in images/docs/api. > > Thanks, Roger > > p.s. > > Documentation and test issues p1-p5, can be fixed after RPD1. > > [1] https://openjdk.java.net/jeps/3 > > > > > > > On 12/12/2018 10:59 PM, Xuelei Fan wrote: >> Looks fine to me. >> >> Xuelei >> >>> On Dec 12, 2018, at 6:25 PM, Weijun Wang wrote: >>> >>> Ping again. >>> >>> This is an RFE so needs to be fixed today unless we request for an approval. >>> >>> Thanks, >>> Max >>> >>>> On Dec 7, 2018, at 11:21 PM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> https://cr.openjdk.java.net/~weijun/8214568/webrev.00 >>>> >>>> Thanks >>>> Max > From Roger.Riggs at oracle.com Thu Dec 13 15:49:51 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 13 Dec 2018 10:49:51 -0500 Subject: RFR 8214568: Use {@systemProperty} for definitions of system properties In-Reply-To: <6EFA18EC-6D2E-4F24-8A17-4C6211AA85D8@oracle.com> References: <79110A0F-FC7C-4AE9-8C2B-E44FB343C2BE@oracle.com> <09509A5C-5DC0-4A65-B668-8DF74C9F2FA2@oracle.com> <6EFA18EC-6D2E-4F24-8A17-4C6211AA85D8@oracle.com> Message-ID: Hi Max, On 12/13/2018 10:35 AM, Weijun Wang wrote: > Hi Roger, > > I didn't run "make docs-javadoc" but I have a script that directly call the javadoc command. While the comment still exists in the output HTML, it is still a comment, and therefore invisible on the page. True, but the comments are still leftovers from some previous process and here's a chance to clean it up. > > Can {@link} be used to link to a URL? I only know about using it to link to class and method names. ok as is, @link is only within the javadoc. Thanks, Roger > > Thanks, > Max > >> On Dec 13, 2018, at 10:33 PM, Roger Riggs wrote: >> >> Hi, >> >> Thanks for converting the package doc. >> >> There is XML commented text in the package-info.java that should be removed. >> It would show up in the javadoc. >> >> And there are links that can now use {@link}. >> It probably worth % make docs-javadoc and checking the result in images/docs/api. >> >> Thanks, Roger >> >> p.s. >> >> Documentation and test issues p1-p5, can be fixed after RPD1. >> >> [1] https://openjdk.java.net/jeps/3 >> >> >> >> >> >> >> On 12/12/2018 10:59 PM, Xuelei Fan wrote: >>> Looks fine to me. >>> >>> Xuelei >>> >>>> On Dec 12, 2018, at 6:25 PM, Weijun Wang wrote: >>>> >>>> Ping again. >>>> >>>> This is an RFE so needs to be fixed today unless we request for an approval. >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Dec 7, 2018, at 11:21 PM, Weijun Wang wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8214568/webrev.00 >>>>> >>>>> Thanks >>>>> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Thu Dec 13 17:02:09 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 13 Dec 2018 17:02:09 +0000 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> Message-ID: <20181213170209.GH22527@twosigma.com> On Wed, Dec 12, 2018 at 11:48:26AM -0800, Valerie Peng wrote: > If anyone is still reviewing this and need more time, please let me know > soon. Otherwise, I will proceed with integration this afternoon. One comment: - checkInitialized() in java.security.Provider seems pointless -- initialized is always set to true in all the Provider the constructors here's your chance to remove it. Nico -- From Nico.Williams at twosigma.com Thu Dec 13 22:17:10 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 13 Dec 2018 22:17:10 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181212004054.GG22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> Message-ID: <20181213221710.GI22527@twosigma.com> Another way to avoid hand-coded SPNEGO here would be to use SSPI for SPNEGO. That could negotiate Kerberos or NTLM, but I do believe there's a way to tell it to only negotiate Kerberos -- I'm not terribly familiar with the details, but I'm pretty sure that Martin Rex's GSS->SSPI shim handles this. Nico -- From valerie.peng at oracle.com Thu Dec 13 23:53:24 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 13 Dec 2018 15:53:24 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <20181213170209.GH22527@twosigma.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> <20181213170209.GH22527@twosigma.com> Message-ID: <8fbaf9cc-7bc2-20cc-f20f-e15a15aa6c3a@oracle.com> If I recall correctly, "initialized" and checkInitialized() method are meant to prevent unauthorized creation of Provider object either through inheritance or deserialization. Thus, they should not be removed unless we are sure that the original issue are no longer of concern. Thanks, Valerie On 12/13/2018 9:02 AM, Nico Williams wrote: > On Wed, Dec 12, 2018 at 11:48:26AM -0800, Valerie Peng wrote: >> If anyone is still reviewing this and need more time, please let me know >> soon. Otherwise, I will proceed with integration this afternoon. > One comment: > > - checkInitialized() in java.security.Provider seems pointless -- initialized > is always set to true in all the Provider the constructors > > here's your chance to remove it. > > Nico From ecki at zusammenkunft.net Fri Dec 14 14:09:50 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 14 Dec 2018 14:09:50 +0000 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <8fbaf9cc-7bc2-20cc-f20f-e15a15aa6c3a@oracle.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> <20181213170209.GH22527@twosigma.com>, <8fbaf9cc-7bc2-20cc-f20f-e15a15aa6c3a@oracle.com> Message-ID: Maybe a comment should point to the description of this pattern (if it applies): https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Valerie Peng Gesendet: Freitag, Dezember 14, 2018 1:53 AM An: Nico Williams Cc: security-dev at openjdk.java.net Betreff: Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" If I recall correctly, "initialized" and checkInitialized() method are meant to prevent unauthorized creation of Provider object either through inheritance or deserialization. Thus, they should not be removed unless we are sure that the original issue are no longer of concern. Thanks, Valerie On 12/13/2018 9:02 AM, Nico Williams wrote: > On Wed, Dec 12, 2018 at 11:48:26AM -0800, Valerie Peng wrote: >> If anyone is still reviewing this and need more time, please let me know >> soon. Otherwise, I will proceed with integration this afternoon. > One comment: > > - checkInitialized() in java.security.Provider seems pointless -- initialized > is always set to true in all the Provider the constructors > > here's your chance to remove it. > > Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Dec 14 16:14:32 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 08:14:32 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException Message-ID: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> Hi, Please review the update: http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ In some cases, the SSLProtocolException or SSLHandshakeException may be thrown if the underlying socket run into problems. An application may depends on the exception class for further action, for example retry the connection with different parameters. This update is trying to separate the socket problem from the TLS protocol or handshake problem, by using different exception classes. Thanks, Xuelei From xuelei.fan at oracle.com Fri Dec 14 17:00:02 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 09:00:02 -0800 Subject: Code Review Request, JDK-8213782: NullPointerException in sun.security.ssl.OutputRecord.changeWriteCiphers Message-ID: <3a0d7138-6e4b-7737-1bb5-7c215d7505cb@oracle.com> Hi, Could I have the fix reviewed? http://cr.openjdk.java.net/~xuelei/8213782/webrev.00/ The SSLCipher.createReadCipher() and createWriteCipher() could return null if the cipher is not supported or the cipher is not available for a certain protocol version. The caller should check the null value, and send back a "illegal_parameter" alert for such cases. I did not add new regression test. The update is straightforward, while constructing an illegal handshake message for such cases is complicated. Thanks, Xuelei From Nico.Williams at twosigma.com Fri Dec 14 18:57:32 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 14 Dec 2018 18:57:32 +0000 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> <20181213170209.GH22527@twosigma.com> <8fbaf9cc-7bc2-20cc-f20f-e15a15aa6c3a@oracle.com> Message-ID: <20181214185732.GJ22527@twosigma.com> On Fri, Dec 14, 2018 at 02:09:50PM +0000, Bernd Eckenfels wrote: > Maybe a comment should point to the description of this pattern (if it > applies): > https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 +1 Do document what initialized/checkInitialized() are about. Now I'm wondering whether it's been thought through well enough and whether assumptions when that was written still hold. (And maybe the language needs syntactic support for this pattern.) Nico -- From jamil.j.nimeh at oracle.com Fri Dec 14 19:49:01 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 14 Dec 2018 11:49:01 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> Message-ID: <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> Looks pretty good.? I did have one question about a few of the methods in KeyShareExtension and PreSharedKeyExtension, specifically where you return nulls on error branches with the make-compiler-happy comments.? In those cases would it be a bit cleaner to set a byte[] variable to null at the beginning of the method and then in the successful code path set the value to whatever byte array comes back from hmacs or hkdf operations?? At the end of the method you only need one return statement, rather than a return null on every error branch, many of which won't be executed due to method calls which always throw exceptions.? Not a big deal if you wish to leave things as they are since I know the current approach is used in many places in the code that this review doesn't touch. --Jamil On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: > Hi, > > Please review the update: > ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ > > In some cases, the SSLProtocolException or SSLHandshakeException may > be thrown if the underlying socket run into problems.? An application > may depends on the exception class for further action, for example > retry the connection with different parameters. > > This update is trying to separate the socket problem from the TLS > protocol or handshake problem, by using different exception classes. > > Thanks, > Xuelei From anthony.scarpino at oracle.com Fri Dec 14 19:57:33 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 14 Dec 2018 11:57:33 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> Message-ID: My nit is I?d remove the ?make compiler happy? comment. If this was something for Xcomp, I?d understand, but this is standard return value requirement. Otherwise I?m fine with this Tony > On Dec 14, 2018, at 11:49 AM, Jamil Nimeh wrote: > > Looks pretty good. I did have one question about a few of the methods in KeyShareExtension and PreSharedKeyExtension, specifically where you return nulls on error branches with the make-compiler-happy comments. In those cases would it be a bit cleaner to set a byte[] variable to null at the beginning of the method and then in the successful code path set the value to whatever byte array comes back from hmacs or hkdf operations? At the end of the method you only need one return statement, rather than a return null on every error branch, many of which won't be executed due to method calls which always throw exceptions. Not a big deal if you wish to leave things as they are since I know the current approach is used in many places in the code that this review doesn't touch. > > --Jamil > >> On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >> Hi, >> >> Please review the update: >> http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >> >> In some cases, the SSLProtocolException or SSLHandshakeException may be thrown if the underlying socket run into problems. An application may depends on the exception class for further action, for example retry the connection with different parameters. >> >> This update is trying to separate the socket problem from the TLS protocol or handshake problem, by using different exception classes. >> >> Thanks, >> Xuelei > From anthony.scarpino at oracle.com Fri Dec 14 20:26:59 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 14 Dec 2018 12:26:59 -0800 Subject: Code Review Request, JDK-8213782: NullPointerException in sun.security.ssl.OutputRecord.changeWriteCiphers In-Reply-To: <3a0d7138-6e4b-7737-1bb5-7c215d7505cb@oracle.com> References: <3a0d7138-6e4b-7737-1bb5-7c215d7505cb@oracle.com> Message-ID: <1E808E51-6669-4A09-93BB-17AEB19A4C95@oracle.com> Other than my nit about the ?make the compiler happy?, this all looks fine. For KeyUpdate, shouldn?t it never be null given the suite and protocol are already known good? I have not problem with the check to be cautious even if it should never happen. Tony > On Dec 14, 2018, at 9:00 AM, Xue-Lei Fan wrote: > > Hi, > > Could I have the fix reviewed? > http://cr.openjdk.java.net/~xuelei/8213782/webrev.00/ > > The SSLCipher.createReadCipher() and createWriteCipher() could return null if the cipher is not supported or the cipher is not available for a certain protocol version. The caller should check the null value, and send back a "illegal_parameter" alert for such cases. > > I did not add new regression test. The update is straightforward, while constructing an illegal handshake message for such cases is complicated. > > Thanks, > Xuelei From sean.mullan at oracle.com Fri Dec 14 21:09:53 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Dec 2018 16:09:53 -0500 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <50097F7C-B78A-4B62-B4D3-54C7B3738DA9@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> <5940fc0f-cf42-5fe8-3c59-7e386e8d02d4@oracle.com> <50097F7C-B78A-4B62-B4D3-54C7B3738DA9@oracle.com> Message-ID: <4dbe1d94-9c3a-c90e-71ad-3608cacfe41e@oracle.com> On 12/12/18 10:57 AM, Weijun Wang wrote: > Thanks. Will you please also take a look at the release note athttps://bugs.openjdk.java.net/browse/JDK-8215293? I'm not sure about including the second sentence: "In particular, the algorithm for certificate protection and MacData can be set to "NONE" so that a PKCS #12 keystore that only contains certificates does not require a password." I would probably remove this sentence and leave specific details and use cases like that to the programming guides. --Sean From xuelei.fan at oracle.com Fri Dec 14 21:16:13 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 13:16:13 -0800 Subject: Code Review Request, JDK-8213782: NullPointerException in sun.security.ssl.OutputRecord.changeWriteCiphers In-Reply-To: <1E808E51-6669-4A09-93BB-17AEB19A4C95@oracle.com> References: <3a0d7138-6e4b-7737-1bb5-7c215d7505cb@oracle.com> <1E808E51-6669-4A09-93BB-17AEB19A4C95@oracle.com> Message-ID: <5c104ab2-e0bd-9d2a-4744-f1297127da28@oracle.com> On 12/14/2018 12:26 PM, Anthony Scarpino wrote: > Other than my nit about the ?make the compiler happy?, this all looks fine. > It makes sense to me. I will remove the comment while pushing. > For KeyUpdate, shouldn?t it never be null given the suite and protocol are already known good? I have not problem with the check to be cautious even if it should never happen. > Right, it should never be null in some cases. I added them is in case I missed some scenarios I'm not aware of. I would like to keep them for safe. Thanks for the review. Xuelei > Tony > >> On Dec 14, 2018, at 9:00 AM, Xue-Lei Fan wrote: >> >> Hi, >> >> Could I have the fix reviewed? >> http://cr.openjdk.java.net/~xuelei/8213782/webrev.00/ >> >> The SSLCipher.createReadCipher() and createWriteCipher() could return null if the cipher is not supported or the cipher is not available for a certain protocol version. The caller should check the null value, and send back a "illegal_parameter" alert for such cases. >> >> I did not add new regression test. The update is straightforward, while constructing an illegal handshake message for such cases is complicated. >> >> Thanks, >> Xuelei > From xuelei.fan at oracle.com Fri Dec 14 21:46:22 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 13:46:22 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> Message-ID: <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> Hi, The purpose of combination of the two lines together: shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "..."); return null; // make the complier happy is actually for the reading of the code. If one don't know the fatal() always throw an exception (compiler is one of them), he may continue reading the following code, and may be confusing about the code logic. The "return" statement could never be executed actually. It could be easier to catch the idea if using a format like: throw new SSLException("there is an alert") - return null; But we need the fatal() method to wrap something more. We used a lot comments similar to: return; // fatal() always throws, make the compiler happy. and the abbreviate comment: return; // make the compiler happy misses the part "fatal() always throws", and then it may look weird. I'm fine to remove the comment, or use the full comment instead "fatal() always throws, make the compiler happy". Which one is your preference? On 12/14/2018 11:49 AM, Jamil Nimeh wrote: > Looks pretty good.? I did have one question about a few of the methods > in KeyShareExtension and PreSharedKeyExtension, specifically where you > return nulls on error branches with the make-compiler-happy comments. In > those cases would it be a bit cleaner to set a byte[] variable to null > at the beginning of the method and then in the successful code path set > the value to whatever byte array comes back from hmacs or hkdf > operations?? At the end of the method you only need one return > statement, rather than a return null on every error branch, many of > which won't be executed due to method calls which always throw > exceptions. Hm, I see your points. As the return statement could never be executed, it may not worthy to declare the byte[] variable earlier. See above. Is it a reasonable coding style to you as well? Thanks, Xuelei > Not a big deal if you wish to leave things as they are > since I know the current approach is used in many places in the code > that this review doesn't touch. > > --Jamil > > On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >> Hi, >> >> Please review the update: >> ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >> >> In some cases, the SSLProtocolException or SSLHandshakeException may >> be thrown if the underlying socket run into problems.? An application >> may depends on the exception class for further action, for example >> retry the connection with different parameters. >> >> This update is trying to separate the socket problem from the TLS >> protocol or handshake problem, by using different exception classes. >> >> Thanks, >> Xuelei > From xuelei.fan at oracle.com Fri Dec 14 21:56:00 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 13:56:00 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> Message-ID: <957d9564-e220-1eca-accc-f79796b56bc2@oracle.com> On 12/14/2018 1:46 PM, Xue-Lei Fan wrote: > Hi, > > The purpose of combination of the two lines together: > > ??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "..."); > ??? return null;??? // make the complier happy > > is actually for the reading of the code.? If one don't know the fatal() > always throw an exception (compiler is one of them), he may continue > reading the following code, and may be confusing about the code logic. > > The "return" statement could never be executed actually.? It could be > easier to catch the idea if using a format like: > > ?? throw new SSLException("there is an alert") > -? return null; > > But we need the fatal() method to wrap something more. > > We used a lot comments similar to: > > ?? return;???? // fatal() always throws, make the compiler happy. > > and the abbreviate comment: > ?? return;??? // make the compiler happy > > misses the part "fatal() always throws", and then it may look weird. > > I'm fine to remove the comment, or use the full comment instead "fatal() > always throws, make the compiler happy".? Which one is your preference? > > > On 12/14/2018 11:49 AM, Jamil Nimeh wrote: >> Looks pretty good.? I did have one question about a few of the methods >> in KeyShareExtension and PreSharedKeyExtension, specifically where you >> return nulls on error branches with the make-compiler-happy comments. >> In those cases would it be a bit cleaner to set a byte[] variable to >> null at the beginning of the method and then in the successful code >> path set the value to whatever byte array comes back from hmacs or >> hkdf operations?? At the end of the method you only need one return >> statement, rather than a return null on every error branch, many of >> which won't be executed due to method calls which always throw >> exceptions. > Hm, I see your points.? As the return statement could never be executed, > it may not worthy to declare the byte[] variable earlier. > I mean that we can remove the "return" statement as it is never executed, if not for code reading or compiler. In some other places, the compiler may not happy because it cannot tell that the fatal() throws exception. So we may still need the "return" statement a little bit. But I think most of them could be removed if we don't like it. Xuelei > See above. Is it a reasonable coding style to you as well? > > Thanks, > Xuelei > >> Not a big deal if you wish to leave things as they are since I know >> the current approach is used in many places in the code that this >> review doesn't touch. >> >> --Jamil >> >> On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >>> Hi, >>> >>> Please review the update: >>> ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >>> >>> In some cases, the SSLProtocolException or SSLHandshakeException may >>> be thrown if the underlying socket run into problems.? An application >>> may depends on the exception class for further action, for example >>> retry the connection with different parameters. >>> >>> This update is trying to separate the socket problem from the TLS >>> protocol or handshake problem, by using different exception classes. >>> >>> Thanks, >>> Xuelei >> From jamil.j.nimeh at oracle.com Sat Dec 15 00:16:27 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 14 Dec 2018 16:16:27 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <957d9564-e220-1eca-accc-f79796b56bc2@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> <957d9564-e220-1eca-accc-f79796b56bc2@oracle.com> Message-ID: <5c9e2003-ac3f-f25f-9bc2-b0fa7badd602@oracle.com> Hi Xuelei, thanks for the clarification.? If you want to keep the structure as-is, then the comment "fatal() always throws, make the compiler happy" is fine.? I think that's a little more helpful to a future maintainer who might be new to the code. Thanks, --Jamil On 12/14/2018 1:56 PM, Xue-Lei Fan wrote: > On 12/14/2018 1:46 PM, Xue-Lei Fan wrote: >> Hi, >> >> The purpose of combination of the two lines together: >> >> ???? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "..."); >> ???? return null;??? // make the complier happy >> >> is actually for the reading of the code.? If one don't know the >> fatal() always throw an exception (compiler is one of them), he may >> continue reading the following code, and may be confusing about the >> code logic. >> >> The "return" statement could never be executed actually.? It could be >> easier to catch the idea if using a format like: >> >> ??? throw new SSLException("there is an alert") >> -? return null; >> >> But we need the fatal() method to wrap something more. >> >> We used a lot comments similar to: >> >> ??? return;???? // fatal() always throws, make the compiler happy. >> >> and the abbreviate comment: >> ??? return;??? // make the compiler happy >> >> misses the part "fatal() always throws", and then it may look weird. >> >> I'm fine to remove the comment, or use the full comment instead >> "fatal() always throws, make the compiler happy".? Which one is your >> preference? >> >> >> On 12/14/2018 11:49 AM, Jamil Nimeh wrote: >>> Looks pretty good.? I did have one question about a few of the >>> methods in KeyShareExtension and PreSharedKeyExtension, specifically >>> where you return nulls on error branches with the >>> make-compiler-happy comments. In those cases would it be a bit >>> cleaner to set a byte[] variable to null at the beginning of the >>> method and then in the successful code path set the value to >>> whatever byte array comes back from hmacs or hkdf operations?? At >>> the end of the method you only need one return statement, rather >>> than a return null on every error branch, many of which won't be >>> executed due to method calls which always throw exceptions. >> Hm, I see your points.? As the return statement could never be >> executed, it may not worthy to declare the byte[] variable earlier. >> > I mean that we can remove the "return" statement as it is never > executed, if not for code reading or compiler. > > In some other places, the compiler may not happy because it cannot > tell that the fatal() throws exception.? So we may still need the > "return" statement a little bit.? But I think most of them could be > removed if we don't like it. > > Xuelei > >> See above. Is it a reasonable coding style to you as well? >> >> Thanks, >> Xuelei >> >>> Not a big deal if you wish to leave things as they are since I know >>> the current approach is used in many places in the code that this >>> review doesn't touch. >>> >>> --Jamil >>> >>> On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >>>> Hi, >>>> >>>> Please review the update: >>>> ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >>>> >>>> In some cases, the SSLProtocolException or SSLHandshakeException >>>> may be thrown if the underlying socket run into problems.? An >>>> application may depends on the exception class for further action, >>>> for example retry the connection with different parameters. >>>> >>>> This update is trying to separate the socket problem from the TLS >>>> protocol or handshake problem, by using different exception classes. >>>> >>>> Thanks, >>>> Xuelei >>> From xuelei.fan at oracle.com Sat Dec 15 00:47:59 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 14 Dec 2018 16:47:59 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <5c9e2003-ac3f-f25f-9bc2-b0fa7badd602@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> <957d9564-e220-1eca-accc-f79796b56bc2@oracle.com> <5c9e2003-ac3f-f25f-9bc2-b0fa7badd602@oracle.com> Message-ID: <6933a551-e862-e4fa-ae41-c8e4c00de375@oracle.com> Hi Jamil, Thanks for the code review. Okay, I will go ahead with the comment "fatal() always throws, make the compiler happy" for this update, and file a new bug and see if we could make an improvement in the future. Thanks, Xuelei On 12/14/2018 4:16 PM, Jamil Nimeh wrote: > Hi Xuelei, thanks for the clarification.? If you want to keep the > structure as-is, then the comment "fatal() always throws, make the > compiler happy" is fine.? I think that's a little more helpful to a > future maintainer who might be new to the code. > > Thanks, > --Jamil > > On 12/14/2018 1:56 PM, Xue-Lei Fan wrote: >> On 12/14/2018 1:46 PM, Xue-Lei Fan wrote: >>> Hi, >>> >>> The purpose of combination of the two lines together: >>> >>> ???? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "..."); >>> ???? return null;??? // make the complier happy >>> >>> is actually for the reading of the code.? If one don't know the >>> fatal() always throw an exception (compiler is one of them), he may >>> continue reading the following code, and may be confusing about the >>> code logic. >>> >>> The "return" statement could never be executed actually.? It could be >>> easier to catch the idea if using a format like: >>> >>> ??? throw new SSLException("there is an alert") >>> -? return null; >>> >>> But we need the fatal() method to wrap something more. >>> >>> We used a lot comments similar to: >>> >>> ??? return;???? // fatal() always throws, make the compiler happy. >>> >>> and the abbreviate comment: >>> ??? return;??? // make the compiler happy >>> >>> misses the part "fatal() always throws", and then it may look weird. >>> >>> I'm fine to remove the comment, or use the full comment instead >>> "fatal() always throws, make the compiler happy".? Which one is your >>> preference? >>> >>> >>> On 12/14/2018 11:49 AM, Jamil Nimeh wrote: >>>> Looks pretty good.? I did have one question about a few of the >>>> methods in KeyShareExtension and PreSharedKeyExtension, specifically >>>> where you return nulls on error branches with the >>>> make-compiler-happy comments. In those cases would it be a bit >>>> cleaner to set a byte[] variable to null at the beginning of the >>>> method and then in the successful code path set the value to >>>> whatever byte array comes back from hmacs or hkdf operations?? At >>>> the end of the method you only need one return statement, rather >>>> than a return null on every error branch, many of which won't be >>>> executed due to method calls which always throw exceptions. >>> Hm, I see your points.? As the return statement could never be >>> executed, it may not worthy to declare the byte[] variable earlier. >>> >> I mean that we can remove the "return" statement as it is never >> executed, if not for code reading or compiler. >> >> In some other places, the compiler may not happy because it cannot >> tell that the fatal() throws exception.? So we may still need the >> "return" statement a little bit.? But I think most of them could be >> removed if we don't like it. >> >> Xuelei >> >>> See above. Is it a reasonable coding style to you as well? >>> >>> Thanks, >>> Xuelei >>> >>>> Not a big deal if you wish to leave things as they are since I know >>>> the current approach is used in many places in the code that this >>>> review doesn't touch. >>>> >>>> --Jamil >>>> >>>> On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the update: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >>>>> >>>>> In some cases, the SSLProtocolException or SSLHandshakeException >>>>> may be thrown if the underlying socket run into problems.? An >>>>> application may depends on the exception class for further action, >>>>> for example retry the connection with different parameters. >>>>> >>>>> This update is trying to separate the socket problem from the TLS >>>>> protocol or handshake problem, by using different exception classes. >>>>> >>>>> Thanks, >>>>> Xuelei >>>> > From dean.long at oracle.com Sat Dec 15 00:59:33 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 14 Dec 2018 16:59:33 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 Message-ID: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8214583 http://cr.openjdk.java.net/~dlong/8214583/webrev This change includes two new regression test that demonstrate the problem, and a fix that allows the tests to pass. The problem happens when the JIT compiler's escape analysis eliminates the allocation of the AccessControlContext object passed to doPrivileged.? The compiler thinks this is safe because it does not see that the object "escapes".? However, getContext needs to be able to find the object using a stack walk, so we need a way to tell the compiler that it does indeed escape.? To do this we pass the value to a native method that does nothing. Microbenchmark results: jdk12-b18: Benchmark??????????????? Mode? Cnt??? Score?? Error? Units DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op jdk12-b19: Benchmark??????????????? Mode? Cnt? Score??? Error? Units DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op this fix: Benchmark??????????????? Mode? Cnt? Score??? Error? Units DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op dl From claes.redestad at oracle.com Sat Dec 15 14:48:38 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 15 Dec 2018 15:48:38 +0100 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> Message-ID: Hi Dean, to avoid escape analysis-eliminated allocations in the past @DontInline has been sufficient. This means a simpler patch (no changes to native code needed - added assertions notwithstanding) and passes your tests with C2 (it'd concern me if Graal's EA sees through this trick, as it might break some existing places where DontInline is used to this effect): /** * The value needs to be physically located in the frame, so that it * can be found by a stack walk. */ @Hidden @DontInline private static void ensureMaterializedForStackWalk(Object o) {} Thanks! /Claes On 2018-12-15 01:59, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8214583 > http://cr.openjdk.java.net/~dlong/8214583/webrev > > This change includes two new regression test that demonstrate the > problem, and a fix that allows the tests > to pass. > > The problem happens when the JIT compiler's escape analysis eliminates > the allocation of the AccessControlContext object passed to > doPrivileged.? The compiler thinks this is safe because it does not see > that the object "escapes".? However, getContext needs to be able to find > the object using a stack walk, so we need a way to tell the compiler > that it does indeed escape.? To do this we pass the value to a native > method that does nothing. > > Microbenchmark results: > > jdk12-b18: > > Benchmark??????????????? Mode? Cnt??? Score?? Error? Units > DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op > DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op > > > jdk12-b19: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op > > this fix: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op > > > dl From xuelei.fan at oracle.com Sat Dec 15 15:51:37 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Sat, 15 Dec 2018 07:51:37 -0800 Subject: Code Review Request JDK-8215443: The use of TransportContext.fatal() leads to bad coding style Message-ID: <5d018528-e304-7edc-9d1c-61409c2aac51@oracle.com> Hi, Could I have the update reviewed? http://cr.openjdk.java.net/~xuelei/8215443/webrev.00/ The TransportContext.fatal() methods always throw exception. While the compiler does not aware of it, and may not happy without following a return statement. Currently, a lot never executable return statements are inserted. As make the code hard to read (thanks for Jamil and Tony's points). For example: shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); return null; // fatal() always throws, make the compiler happy. In this update, I changed the fatal() method with a return value: - void fatal(Alert alert, ... + SSLException fatal(Alert alert, ... Then we can change the use of method as: - shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); - return null; // fatal() always throws, make the compiler happy. + throw shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); The changeset is mostly about removing the never executed return statements and add the 'throw' keyword to lines that use the fatal() methods. Thanks, Xuelei From anthony.scarpino at oracle.com Sat Dec 15 19:42:37 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Sat, 15 Dec 2018 11:42:37 -0800 Subject: Code Review Request, JDK-8214339 : SSLSocketImpl erroneously wraps SocketException In-Reply-To: <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> References: <87cfe72e-d608-6217-a693-461332101b53@oracle.com> <91c5e297-531f-69a0-0851-4ff9b27a034b@oracle.com> <5afe49ef-90a6-4101-29a1-7ae17084bf61@oracle.com> Message-ID: Just the complete the thread. Says "fatal() throws exception" is fine. If this all only trying to make the compiler happy, you could just have one "return null" at the bottom of the method. It is not necessary to put a return after each fatal(). I will admit it could be less readable. Or fatal could return the exception, then the calling method would throw it: throw shc.conContext.fatal(); But that's a larger change that I don't expected changed here. Tony On 12/14/18 1:46 PM, Xue-Lei Fan wrote: > Hi, > > The purpose of combination of the two lines together: > > ??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "..."); > ??? return null;??? // make the complier happy > > is actually for the reading of the code.? If one don't know the fatal() > always throw an exception (compiler is one of them), he may continue > reading the following code, and may be confusing about the code logic. > > The "return" statement could never be executed actually.? It could be > easier to catch the idea if using a format like: > > ?? throw new SSLException("there is an alert") > -? return null; > > But we need the fatal() method to wrap something more. > > We used a lot comments similar to: > > ?? return;???? // fatal() always throws, make the compiler happy. > > and the abbreviate comment: > ?? return;??? // make the compiler happy > > misses the part "fatal() always throws", and then it may look weird. > > I'm fine to remove the comment, or use the full comment instead "fatal() > always throws, make the compiler happy".? Which one is your preference? > > > On 12/14/2018 11:49 AM, Jamil Nimeh wrote: >> Looks pretty good.? I did have one question about a few of the methods >> in KeyShareExtension and PreSharedKeyExtension, specifically where you >> return nulls on error branches with the make-compiler-happy comments. >> In those cases would it be a bit cleaner to set a byte[] variable to >> null at the beginning of the method and then in the successful code >> path set the value to whatever byte array comes back from hmacs or >> hkdf operations?? At the end of the method you only need one return >> statement, rather than a return null on every error branch, many of >> which won't be executed due to method calls which always throw >> exceptions. > Hm, I see your points.? As the return statement could never be executed, > it may not worthy to declare the byte[] variable earlier. > > See above. Is it a reasonable coding style to you as well? > > Thanks, > Xuelei > >> Not a big deal if you wish to leave things as they are since I know >> the current approach is used in many places in the code that this >> review doesn't touch. >> >> --Jamil >> >> On 12/14/2018 8:14 AM, Xue-Lei Fan wrote: >>> Hi, >>> >>> Please review the update: >>> ?? http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/ >>> >>> In some cases, the SSLProtocolException or SSLHandshakeException may >>> be thrown if the underlying socket run into problems.? An application >>> may depends on the exception class for further action, for example >>> retry the connection with different parameters. >>> >>> This update is trying to separate the socket problem from the TLS >>> protocol or handshake problem, by using different exception classes. >>> >>> Thanks, >>> Xuelei >> From david.holmes at oracle.com Mon Dec 17 00:06:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 10:06:22 +1000 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> Message-ID: <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8214583 > http://cr.openjdk.java.net/~dlong/8214583/webrev > > This change includes two new regression test that demonstrate the > problem, and a fix that allows the tests > to pass. > > The problem happens when the JIT compiler's escape analysis eliminates > the allocation of the AccessControlContext object passed to > doPrivileged.? The compiler thinks this is safe because it does not see > that the object "escapes". Then surely the compiler's notion of "escapes" needs to be updated! David ----- ? However, getContext needs to be able to find > the object using a stack walk, so we need a way to tell the compiler > that it does indeed escape.? To do this we pass the value to a native > method that does nothing. > > Microbenchmark results: > > jdk12-b18: > > Benchmark??????????????? Mode? Cnt??? Score?? Error? Units > DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op > DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op > > > jdk12-b19: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op > > this fix: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op > > > dl From dean.long at oracle.com Mon Dec 17 02:49:49 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 18:49:49 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> Message-ID: <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> On 12/16/18 4:06 PM, David Holmes wrote: > On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214583 >> http://cr.openjdk.java.net/~dlong/8214583/webrev >> >> This change includes two new regression test that demonstrate the >> problem, and a fix that allows the tests >> to pass. >> >> The problem happens when the JIT compiler's escape analysis >> eliminates the allocation of the AccessControlContext object passed >> to doPrivileged.? The compiler thinks this is safe because it does >> not see that the object "escapes". > > Then surely the compiler's notion of "escapes" needs to be updated! > The compiler can inline the callee method and see that the value doesn't escape.? This is a valid optimization in cases where the callee method is known. dl > David > ----- > > ? However, getContext needs to be able to find >> the object using a stack walk, so we need a way to tell the compiler >> that it does indeed escape.? To do this we pass the value to a native >> method that does nothing. >> >> Microbenchmark results: >> >> jdk12-b18: >> >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >> >> >> jdk12-b19: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >> >> this fix: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >> >> >> dl From david.holmes at oracle.com Mon Dec 17 03:03:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 13:03:30 +1000 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> Message-ID: <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> On 17/12/2018 12:49 pm, dean.long at oracle.com wrote: > On 12/16/18 4:06 PM, David Holmes wrote: >> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>> >>> This change includes two new regression test that demonstrate the >>> problem, and a fix that allows the tests >>> to pass. >>> >>> The problem happens when the JIT compiler's escape analysis >>> eliminates the allocation of the AccessControlContext object passed >>> to doPrivileged.? The compiler thinks this is safe because it does >>> not see that the object "escapes". >> >> Then surely the compiler's notion of "escapes" needs to be updated! >> > > The compiler can inline the callee method and see that the value doesn't > escape.? This is a valid optimization in cases where the callee method > is known. But it's not a valid optimization in this case, so my comment stands. Is this stack walking something this is guaranteed by the spec to be always valid (and hence the JIT is violating the rules), or is the stack walking code making assumptions about whether it will find the context object in the stack? If we have to hack around this with an annotation I'd rather see a specific annotation that addresses the problematic usecase than a generic "don't inline" one. E.g. @StackVisible or something like that. Cheers, David > > dl > >> David >> ----- >> >> ? However, getContext needs to be able to find >>> the object using a stack walk, so we need a way to tell the compiler >>> that it does indeed escape.? To do this we pass the value to a native >>> method that does nothing. >>> >>> Microbenchmark results: >>> >>> jdk12-b18: >>> >>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>> >>> >>> jdk12-b19: >>> >>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>> >>> this fix: >>> >>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>> >>> >>> dl > From dean.long at oracle.com Mon Dec 17 03:39:31 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 19:39:31 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> Message-ID: On 12/16/18 7:03 PM, David Holmes wrote: > On 17/12/2018 12:49 pm, dean.long at oracle.com wrote: >> On 12/16/18 4:06 PM, David Holmes wrote: >>> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>> >>>> This change includes two new regression test that demonstrate the >>>> problem, and a fix that allows the tests >>>> to pass. >>>> >>>> The problem happens when the JIT compiler's escape analysis >>>> eliminates the allocation of the AccessControlContext object passed >>>> to doPrivileged.? The compiler thinks this is safe because it does >>>> not see that the object "escapes". >>> >>> Then surely the compiler's notion of "escapes" needs to be updated! >>> >> >> The compiler can inline the callee method and see that the value >> doesn't escape.? This is a valid optimization in cases where the >> callee method is known. > > But it's not a valid optimization in this case, so my comment stands. > > Is this stack walking something this is guaranteed by the spec to be > always valid (and hence the JIT is violating the rules), or is the > stack walking code making assumptions about whether it will find the > context object in the stack? > The stack walking is in the VM and is an internal implementation detail, not part of the AccessController API spec.? A different thread running normal Java code would never be able to see a non-escaping value.? The stack walking code does need to find the context object in the stack.? Non-escaping objects won't show up in the stack. > If we have to hack around this with an annotation I'd rather see a > specific annotation that addresses the problematic usecase than a > generic "don't inline" one. E.g. @StackVisible or something like that. > That sounds like a good idea for 13, but would require changes to both C2 and Graal, and it seems a little risky compared to using existing mechanisms. dl > Cheers, > David > >> >> dl >> >>> David >>> ----- >>> >>> ? However, getContext needs to be able to find >>>> the object using a stack walk, so we need a way to tell the >>>> compiler that it does indeed escape. To do this we pass the value >>>> to a native method that does nothing. >>>> >>>> Microbenchmark results: >>>> >>>> jdk12-b18: >>>> >>>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>>> >>>> >>>> jdk12-b19: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>>> >>>> this fix: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>>> >>>> >>>> dl >> From dean.long at oracle.com Mon Dec 17 04:45:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 20:45:02 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> Message-ID: <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> Unfortunately, I don't think @DontInline on an empty method is sufficient here.? If other code is relying on @DontInline for the same purpose then we might need to reexamine that code.? My understanding from discussing with other compiler engineers is that using a native method is the safest technique that the compilers can't see through.? The problem with @DontInline is that C2 looks at the bytecodes of the target method, even if it isn't inlined (see BCEscapeAnalyzer and the EstimateArgEscape flag). There may be a way to make it work, but that would require more investigation, and I'm not sure the benefit outweighs the risk. dl On 12/15/18 6:48 AM, Claes Redestad wrote: > Hi Dean, > > to avoid escape analysis-eliminated allocations in the past @DontInline > has been sufficient. This means a simpler patch (no changes to native > code needed - added assertions notwithstanding) and passes your tests > with C2 (it'd concern me if Graal's EA sees through this trick, as it > might break some existing places where DontInline is used to this > effect): > > ??? /** > ???? * The value needs to be physically located in the frame, so that it > ???? * can be found by a stack walk. > ???? */ > ??? @Hidden > ??? @DontInline > ??? private static void ensureMaterializedForStackWalk(Object o) {} > > Thanks! > > /Claes > > On 2018-12-15 01:59, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214583 >> http://cr.openjdk.java.net/~dlong/8214583/webrev >> >> This change includes two new regression test that demonstrate the >> problem, and a fix that allows the tests >> to pass. >> >> The problem happens when the JIT compiler's escape analysis >> eliminates the allocation of the AccessControlContext object passed >> to doPrivileged.? The compiler thinks this is safe because it does >> not see that the object "escapes".? However, getContext needs to be >> able to find the object using a stack walk, so we need a way to tell >> the compiler that it does indeed escape.? To do this we pass the >> value to a native method that does nothing. >> >> Microbenchmark results: >> >> jdk12-b18: >> >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >> >> >> jdk12-b19: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >> >> this fix: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >> >> >> dl From dean.long at oracle.com Mon Dec 17 04:47:59 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 20:47:59 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> Message-ID: On 12/16/18 7:39 PM, dean.long at oracle.com wrote: > On 12/16/18 7:03 PM, David Holmes wrote: >> On 17/12/2018 12:49 pm, dean.long at oracle.com wrote: >>> On 12/16/18 4:06 PM, David Holmes wrote: >>>> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>>> >>>>> This change includes two new regression test that demonstrate the >>>>> problem, and a fix that allows the tests >>>>> to pass. >>>>> >>>>> The problem happens when the JIT compiler's escape analysis >>>>> eliminates the allocation of the AccessControlContext object >>>>> passed to doPrivileged.? The compiler thinks this is safe because >>>>> it does not see that the object "escapes". >>>> >>>> Then surely the compiler's notion of "escapes" needs to be updated! >>>> >>> >>> The compiler can inline the callee method and see that the value >>> doesn't escape.? This is a valid optimization in cases where the >>> callee method is known. >> >> But it's not a valid optimization in this case, so my comment stands. >> >> Is this stack walking something this is guaranteed by the spec to be >> always valid (and hence the JIT is violating the rules), or is the >> stack walking code making assumptions about whether it will find the >> context object in the stack? >> > > The stack walking is in the VM and is an internal implementation > detail, not part of the AccessController API spec.? A different thread > running normal Java code would never be able to see a non-escaping > value.? The stack walking code does need to find the context object in > the stack.? Non-escaping objects won't show up in the stack. > >> If we have to hack around this with an annotation I'd rather see a >> specific annotation that addresses the problematic usecase than a >> generic "don't inline" one. E.g. @StackVisible or something like that. >> > > That sounds like a good idea for 13, but would require changes to both > C2 and Graal, and it seems a little risky compared to using existing > mechanisms. > I forgot to address this in my last reply, but I'm not suggesting a @DontInline annotation.? That was Claes.? My fixes uses a native method. dl > dl > >> Cheers, >> David >> >>> >>> dl >>> >>>> David >>>> ----- >>>> >>>> ? However, getContext needs to be able to find >>>>> the object using a stack walk, so we need a way to tell the >>>>> compiler that it does indeed escape. To do this we pass the value >>>>> to a native method that does nothing. >>>>> >>>>> Microbenchmark results: >>>>> >>>>> jdk12-b18: >>>>> >>>>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>>>> >>>>> >>>>> jdk12-b19: >>>>> >>>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>>>> >>>>> this fix: >>>>> >>>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>>>> >>>>> >>>>> dl >>> > From claes.redestad at oracle.com Mon Dec 17 05:52:22 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Dec 2018 06:52:22 +0100 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> Message-ID: <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> Fair enough, I wasn't aware EA was looking beyond the inlined code like this (which means it can't be "dead" or the JIT might see through the trick at some point). I've skimmed the existing usages in the JDK and can't find anything that seems to be dependent on DontInline defeating EA - maybe there was in the past, or I simply misremembered. Either way, it might be nice to have a more explicit facility for this in a future release, as David suggested. Say an @Escaping local variable/parameter annotation. /Claes On 2018-12-17 05:45, dean.long at oracle.com wrote: > Unfortunately, I don't think @DontInline on an empty method is sufficient > here.? If other code is relying on @DontInline for the same purpose then > we might need to reexamine that code.? My understanding from discussing > with other compiler engineers is that using a native method is the safest > technique that the compilers can't see through.? The problem with > @DontInline is that C2 looks at the bytecodes of the target method, even > if it isn't inlined (see BCEscapeAnalyzer and the EstimateArgEscape flag). > There may be a way to make it work, but that would require more > investigation, and I'm not sure the benefit outweighs the risk. > > dl > > On 12/15/18 6:48 AM, Claes Redestad wrote: >> Hi Dean, >> >> to avoid escape analysis-eliminated allocations in the past @DontInline >> has been sufficient. This means a simpler patch (no changes to native >> code needed - added assertions notwithstanding) and passes your tests >> with C2 (it'd concern me if Graal's EA sees through this trick, as it >> might break some existing places where DontInline is used to this >> effect): >> >> ??? /** >> ???? * The value needs to be physically located in the frame, so that it >> ???? * can be found by a stack walk. >> ???? */ >> ??? @Hidden >> ??? @DontInline >> ??? private static void ensureMaterializedForStackWalk(Object o) {} >> >> Thanks! >> >> /Claes >> >> On 2018-12-15 01:59, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>> >>> This change includes two new regression test that demonstrate the >>> problem, and a fix that allows the tests >>> to pass. >>> >>> The problem happens when the JIT compiler's escape analysis >>> eliminates the allocation of the AccessControlContext object passed >>> to doPrivileged.? The compiler thinks this is safe because it does >>> not see that the object "escapes".? However, getContext needs to be >>> able to find the object using a stack walk, so we need a way to tell >>> the compiler that it does indeed escape.? To do this we pass the >>> value to a native method that does nothing. >>> >>> Microbenchmark results: >>> >>> jdk12-b18: >>> >>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>> >>> >>> jdk12-b19: >>> >>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>> >>> this fix: >>> >>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>> >>> >>> dl > From dean.long at oracle.com Mon Dec 17 05:54:57 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 21:54:57 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> Message-ID: <8fcf6de6-4cfa-ebbe-84ac-6025924047c4@oracle.com> On 12/16/18 9:52 PM, Claes Redestad wrote: > > Either way, it might be nice to have a more explicit facility for this > in a future release, as David suggested. Say an @Escaping local > variable/parameter annotation. > I agree.? I suggested @Escapes or @StackWalkable in JDK-8214585. @Escaping or @StackVisible sound just as reasonable. dl > /Claes > > On 2018-12-17 05:45, dean.long at oracle.com wrote: >> Unfortunately, I don't think @DontInline on an empty method is >> sufficient >> here.? If other code is relying on @DontInline for the same purpose then >> we might need to reexamine that code.? My understanding from discussing >> with other compiler engineers is that using a native method is the >> safest >> technique that the compilers can't see through.? The problem with >> @DontInline is that C2 looks at the bytecodes of the target method, even >> if it isn't inlined (see BCEscapeAnalyzer and the EstimateArgEscape >> flag). >> There may be a way to make it work, but that would require more >> investigation, and I'm not sure the benefit outweighs the risk. >> >> dl >> >> On 12/15/18 6:48 AM, Claes Redestad wrote: >>> Hi Dean, >>> >>> to avoid escape analysis-eliminated allocations in the past @DontInline >>> has been sufficient. This means a simpler patch (no changes to native >>> code needed - added assertions notwithstanding) and passes your tests >>> with C2 (it'd concern me if Graal's EA sees through this trick, as it >>> might break some existing places where DontInline is used to this >>> effect): >>> >>> ??? /** >>> ???? * The value needs to be physically located in the frame, so >>> that it >>> ???? * can be found by a stack walk. >>> ???? */ >>> ??? @Hidden >>> ??? @DontInline >>> ??? private static void ensureMaterializedForStackWalk(Object o) {} >>> >>> Thanks! >>> >>> /Claes >>> >>> On 2018-12-15 01:59, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>> >>>> This change includes two new regression test that demonstrate the >>>> problem, and a fix that allows the tests >>>> to pass. >>>> >>>> The problem happens when the JIT compiler's escape analysis >>>> eliminates the allocation of the AccessControlContext object passed >>>> to doPrivileged.? The compiler thinks this is safe because it does >>>> not see that the object "escapes".? However, getContext needs to be >>>> able to find the object using a stack walk, so we need a way to >>>> tell the compiler that it does indeed escape.? To do this we pass >>>> the value to a native method that does nothing. >>>> >>>> Microbenchmark results: >>>> >>>> jdk12-b18: >>>> >>>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>>> >>>> >>>> jdk12-b19: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>>> >>>> this fix: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>>> >>>> >>>> dl >> From dean.long at oracle.com Mon Dec 17 06:28:40 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 22:28:40 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> Message-ID: <30ef0a6a-68cf-d8a8-9c98-f83d220a52d5@oracle.com> On 12/16/18 9:52 PM, Claes Redestad wrote: > Fair enough, I wasn't aware EA was looking beyond the inlined code like > this (which means it can't be "dead" or the JIT might see through the > trick at some point). I've skimmed the existing usages in the JDK and > can't find anything that seems to be dependent on DontInline defeating > EA - maybe there was in the past, or I simply misremembered. Were you thinking of the pre-jdk11 implementation of Reference.reachabilityFence() perhaps? dl From matthias.baesken at sap.com Mon Dec 17 08:59:18 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 17 Dec 2018 08:59:18 +0000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release Message-ID: Hello, please review the following change. I noticed that we miss at some places (for example in case of early returns) where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements call. In VirtualMachineImpl.c I also removed a check for isCopy (is the returned byte array a copy ?) because from what I read at https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html the ReleaseByteArrayElements routine should always be called. bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8215411 http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Dec 17 17:52:31 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 17 Dec 2018 09:52:31 -0800 Subject: Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close In-Reply-To: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> References: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> Message-ID: ping ... On 12/10/2018 1:14 PM, Xue-Lei Fan wrote: > Hi, > > Please review the TLS 1.3 half-close issue in JDK. > > ??? http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/ > > While trying to duplex close a TLS connection upon the half-close > policy, there might be pending receiving data in the closing side, and > result in a TCP RST during closing.? The TCP RST may then cause the peer > reading failure.? For example: > 1. client and server establish a TLS 1.3 connection. > 2. server sending the post-handshake NewSessionTicket message. > 3. client send the application data, and then close the connection. > 4. as the client does not call to read the post-handshake message, the > connection close will cause a TCP RST. > 5. server trying to read the client application data, but the socket may > be impacted by the TCP RST, and the reading can fail. > > It would not be an issue any more if the client could read the > post-handshake message, explicit or implicit. > > I would like applications consider to use half-close policy, and moving > away from the duplex-close policy. > > The basic idea of the fix is trying to use up buffered network input > before close the socket.? As is an implicit behavior to consume the > post-handshake message, and mitigate the impact of it. > > This fix is not a perfect one.? It is just a workaround for > duplex-close.? I'm open to hear more ideas. > > Thanks, > Xuelei From norman.maurer at googlemail.com Mon Dec 17 19:13:14 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Dec 2018 20:13:14 +0100 Subject: Possible bug in SSLEngine / SSLSession implementation In-Reply-To: References: <4dd3a000-de8c-c49c-98b8-553ef247812b@oracle.com> Message-ID: <74038A5B-8170-4746-ABFF-3F55637458EA@googlemail.com> So is what I see something that should be fixed in general ? Like I said it does not matter if its TLSv1.3 or earlier. Bye Norman > On 12. Dec 2018, at 15:42, Norman Maurer wrote: > > Hi Jamil, > > This was just noticed during a test which uses TLS1.2. > >> On 12. Dec 2018, at 15:35, Jamil Nimeh > wrote: >> >> Hi Norman, the new handshaker does return a new SSLSession object. Part of JDK-8212885 fixes the lack of propagation of session values across session objects, though that fix was largely in the context of TLS 1.3. There is a backport set for it, but it is not yet complete as far as I'm aware. Are you doing TLS 1.3 sessions? If so, are you able to try it with the latest JDK? >> >> One of the items we're going to be tacking soon is better TLS session object management and new session ticket management so we can avoid these value propagation issues in the future. >> >> --Jamil >> >> On 12/11/2018 11:59 PM, Norman Maurer wrote: >>> Hi all, >>> >>> While working on some unit tests in netty I noticed that there may be a bug in the JDK implementation of SSLEngine / SSLSession. If its not a but it is at least surprising I would say. >>> >>> >>> So it seems like before the handshake all values that are set on the SSLSession via putValue are shared across SSLEngine instances. Is this by design or a bug ? I could not find anything I the java docs that would tell me this is by design. It only states: "Until the initial handshake has completed, this method returns a session object which reports an invalid cipher suite of ?SSL_NULL_WITH_NULL_NULL?. This does not sound like it will be the same object every time and so it would share the values. >>> >>> You can find a reproducer which will throw an exception here: >>> >>> https://github.com/normanmaurer/jdk_ssl_session_reproducer >>> >>> >>> I did reproduce this with the latest java8 and java11 releases but I am almost sure it also exists in other versions. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Dec 17 19:28:46 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Dec 2018 11:28:46 -0800 Subject: Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> Message-ID: <36ffd45a-bf7d-5c96-7353-d6a50597ac4c@oracle.com> Hi Xuelei, just a couple questions: * SSLSocketImpl o 611: Are you sure conContext.inputRecord should go into a try-with-resources?? As far as I can tell, the inheritence chain is SSLSocketInputRecord->InputRecord and that directly or by extension implements the SSLRecord, Record and Closeable interfaces.? I thought that you needed to implement AutoCloseable in order to get that automatic closure benefit from leaving the try block.? Am I missing something? * SSLContextTemplate o 505: Is there any benefit to initializing the SSLContext using a PKIXParameters object with the date fixed to sometime in between 2018 and 2028 (the soonest expiration date of all the certs in the test).? This way you'd never have to worry about things expiring.? I know we don't do this in most of our tests, dunno why it just occurred to me now. The rest looks OK to me. --Jamil On 12/17/2018 9:52 AM, Xue-Lei Fan wrote: > ping ... > > On 12/10/2018 1:14 PM, Xue-Lei Fan wrote: >> Hi, >> >> Please review the TLS 1.3 half-close issue in JDK. >> >> ???? http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/ >> >> While trying to duplex close a TLS connection upon the half-close >> policy, there might be pending receiving data in the closing side, >> and result in a TCP RST during closing.? The TCP RST may then cause >> the peer reading failure.? For example: >> 1. client and server establish a TLS 1.3 connection. >> 2. server sending the post-handshake NewSessionTicket message. >> 3. client send the application data, and then close the connection. >> 4. as the client does not call to read the post-handshake message, >> the connection close will cause a TCP RST. >> 5. server trying to read the client application data, but the socket >> may be impacted by the TCP RST, and the reading can fail. >> >> It would not be an issue any more if the client could read the >> post-handshake message, explicit or implicit. >> >> I would like applications consider to use half-close policy, and >> moving away from the duplex-close policy. >> >> The basic idea of the fix is trying to use up buffered network input >> before close the socket.? As is an implicit behavior to consume the >> post-handshake message, and mitigate the impact of it. >> >> This fix is not a perfect one.? It is just a workaround for >> duplex-close.? I'm open to hear more ideas. >> >> Thanks, >> Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Dec 17 20:11:07 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 17 Dec 2018 12:11:07 -0800 Subject: Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close In-Reply-To: <36ffd45a-bf7d-5c96-7353-d6a50597ac4c@oracle.com> References: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> <36ffd45a-bf7d-5c96-7353-d6a50597ac4c@oracle.com> Message-ID: On 12/17/2018 11:28 AM, Jamil Nimeh wrote: > Hi Xuelei, just a couple questions: > > * SSLSocketImpl > o 611: Are you sure conContext.inputRecord should go into a > try-with-resources?? As far as I can tell, the inheritence chain > is SSLSocketInputRecord->InputRecord and that directly or by > extension implements the SSLRecord, Record and Closeable > interfaces.? I thought that you needed to implement > AutoCloseable in order to get that automatic closure benefit > from leaving the try block.? Am I missing something? Closeable was updated to extend AutoCloseable, so using either AutoCloseable or Closeable is fine for try-with-resources statement. public interface Closeable extends AutoCloseable > * SSLContextTemplate > o 505: Is there any benefit to initializing the SSLContext using a > PKIXParameters object with the date fixed to sometime in between > 2018 and 2028 (the soonest expiration date of all the certs in > the test).? This way you'd never have to worry about things > expiring.? I know we don't do this in most of our tests, dunno > why it just occurred to me now. > Good point! It's a really nice enhancement! I had pushed this template in another bug fix. Let's do it separately. I filed a new bug for tracking this enhancement. https://bugs.openjdk.java.net/browse/JDK-8215509 Thanks, Xuelei > The rest looks OK to me. > > --Jamil > > On 12/17/2018 9:52 AM, Xue-Lei Fan wrote: >> ping ... >> >> On 12/10/2018 1:14 PM, Xue-Lei Fan wrote: >>> Hi, >>> >>> Please review the TLS 1.3 half-close issue in JDK. >>> >>> http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/ >>> >>> While trying to duplex close a TLS connection upon the half-close >>> policy, there might be pending receiving data in the closing side, >>> and result in a TCP RST during closing.? The TCP RST may then cause >>> the peer reading failure.? For example: >>> 1. client and server establish a TLS 1.3 connection. >>> 2. server sending the post-handshake NewSessionTicket message. >>> 3. client send the application data, and then close the connection. >>> 4. as the client does not call to read the post-handshake message, >>> the connection close will cause a TCP RST. >>> 5. server trying to read the client application data, but the socket >>> may be impacted by the TCP RST, and the reading can fail. >>> >>> It would not be an issue any more if the client could read the >>> post-handshake message, explicit or implicit. >>> >>> I would like applications consider to use half-close policy, and >>> moving away from the duplex-close policy. >>> >>> The basic idea of the fix is trying to use up buffered network input >>> before close the socket.? As is an implicit behavior to consume the >>> post-handshake message, and mitigate the impact of it. >>> >>> This fix is not a perfect one.? It is just a workaround for >>> duplex-close.? I'm open to hear more ideas. >>> >>> Thanks, >>> Xuelei > From ecki at zusammenkunft.net Mon Dec 17 20:42:18 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 17 Dec 2018 21:42:18 +0100 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrongvalue after JDK-8212605 In-Reply-To: <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> Message-ID: <5c180a2a.1c69fb81.c57e.5ba0@mx.google.com> In a related matter, are the existing tests reliable to detect the Situation (at least for the Default runtime/compiler behavior). i.e. are the testcases covering stack Evaluation in a compiled context where EA would elimiiminate it? Gruss Bernd -- http://bernd.eckenfels.net Von: dean.long at oracle.com Gesendet: Montag, 17. Dezember 2018 05:56 An: Claes Redestad; security-dev at openjdk.java.net; hotspot-dev developers Betreff: Re: 12 RFR(M) 8214583: AccessController.getContext may return wrongvalue after JDK-8212605 Unfortunately, I don't think @DontInline on an empty method is sufficient here.? If other code is relying on @DontInline for the same purpose then we might need to reexamine that code.? My understanding from discussing with other compiler engineers is that using a native method is the safest technique that the compilers can't see through.? The problem with @DontInline is that C2 looks at the bytecodes of the target method, even if it isn't inlined (see BCEscapeAnalyzer and the EstimateArgEscape flag). There may be a way to make it work, but that would require more investigation, and I'm not sure the benefit outweighs the risk. dl On 12/15/18 6:48 AM, Claes Redestad wrote: > Hi Dean, > > to avoid escape analysis-eliminated allocations in the past @DontInline > has been sufficient. This means a simpler patch (no changes to native > code needed - added assertions notwithstanding) and passes your tests > with C2 (it'd concern me if Graal's EA sees through this trick, as it > might break some existing places where DontInline is used to this > effect): > > ??? /** > ???? * The value needs to be physically located in the frame, so that it > ???? * can be found by a stack walk. > ???? */ > ??? @Hidden > ??? @DontInline > ??? private static void ensureMaterializedForStackWalk(Object o) {} > > Thanks! > > /Claes > > On 2018-12-15 01:59, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214583 >> http://cr.openjdk.java.net/~dlong/8214583/webrev >> >> This change includes two new regression test that demonstrate the >> problem, and a fix that allows the tests >> to pass. >> >> The problem happens when the JIT compiler's escape analysis >> eliminates the allocation of the AccessControlContext object passed >> to doPrivileged.? The compiler thinks this is safe because it does >> not see that the object "escapes".? However, getContext needs to be >> able to find the object using a stack walk, so we need a way to tell >> the compiler that it does indeed escape.? To do this we pass the >> value to a native method that does nothing. >> >> Microbenchmark results: >> >> jdk12-b18: >> >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >> >> >> jdk12-b19: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >> >> this fix: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >> >> >> dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Dec 17 21:17:32 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 17 Dec 2018 13:17:32 -0800 Subject: Code Review Request JDK-8215443: The use of TransportContext.fatal() leads to bad coding style In-Reply-To: <5d018528-e304-7edc-9d1c-61409c2aac51@oracle.com> References: <5d018528-e304-7edc-9d1c-61409c2aac51@oracle.com> Message-ID: <7b3043f3-c3d9-ea76-0a7b-8b136994d9d4@oracle.com> It looks like in TransportContext.java:68, you had a mistype that added "fa" to the end of a comment. Also in fatal():267, did you plan to return the exception and have the calling method throw the exception? As is, the exception is never return and fatal() continues to throw the exceptions. Tony On 12/15/18 7:51 AM, Xue-Lei Fan wrote: > Hi, > > Could I have the update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8215443/webrev.00/ > > The TransportContext.fatal() methods always throw exception. While the > compiler does not aware of it, and may not happy without following a > return statement.? Currently, a lot never executable return statements > are inserted.? As make the code hard to read (thanks for Jamil and > Tony's points).? For example: > > ??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); > ??? return null;??? // fatal() always throws, make the compiler happy. > > In this update, I changed the fatal() method with a return value: > > -??? void fatal(Alert alert, ... > +??? SSLException fatal(Alert alert, ... > > Then we can change the use of method as: > > -??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); > -??? return null;??? // fatal() always throws, make the compiler happy. > +??? throw shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); > > The changeset is mostly about removing the never executed return > statements and add the 'throw' keyword to lines that use the fatal() > methods. > > Thanks, > Xuelei From sean.mullan at oracle.com Mon Dec 17 21:21:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Dec 2018 16:21:54 -0500 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" In-Reply-To: <20181214185732.GJ22527@twosigma.com> References: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> <601f2ddd-0115-6d81-6c3b-9b32dbe83c2a@oracle.com> <0c204efc-add4-977c-58d4-533bbc61e362@oracle.com> <5d599556-1669-6ec1-db27-f5cc41a6fb6a@oracle.com> <20181213170209.GH22527@twosigma.com> <8fbaf9cc-7bc2-20cc-f20f-e15a15aa6c3a@oracle.com> <20181214185732.GJ22527@twosigma.com> Message-ID: On 12/14/18 1:57 PM, Nico Williams wrote: > On Fri, Dec 14, 2018 at 02:09:50PM +0000, Bernd Eckenfels wrote: >> Maybe a comment should point to the description of this pattern (if it >> applies): >> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 > > +1 > > Do document what initialized/checkInitialized() are about. Now I'm wondering > whether it's been thought through well enough and whether assumptions when that > was written still hold. I am pretty sure it can be removed and that it is no longer necessary, but things like this are usually worth another closer look before removing. In any case, I opened a follow-on issue to look into removing this: https://bugs.openjdk.java.net/browse/JDK-8215512 --Sean > > (And maybe the language needs syntactic support for this pattern.) > > Nico > From jamil.j.nimeh at oracle.com Mon Dec 17 22:21:07 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Dec 2018 14:21:07 -0800 Subject: Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <50f9efcc-0976-721c-94d0-420fbe7703f9@oracle.com> <36ffd45a-bf7d-5c96-7353-d6a50597ac4c@oracle.com> Message-ID: Hi Xuelei, comments in-line. On 12/17/2018 12:11 PM, Xue-Lei Fan wrote: > On 12/17/2018 11:28 AM, Jamil Nimeh wrote: >> Hi Xuelei, just a couple questions: >> >> ? * SSLSocketImpl >> ????? o 611: Are you sure conContext.inputRecord should go into a >> ??????? try-with-resources?? As far as I can tell, the inheritence chain >> ??????? is SSLSocketInputRecord->InputRecord and that directly or by >> ??????? extension implements the SSLRecord, Record and Closeable >> ??????? interfaces.? I thought that you needed to implement >> ??????? AutoCloseable in order to get that automatic closure benefit >> ??????? from leaving the try block.? Am I missing something? > Closeable was updated to extend AutoCloseable, so using either > AutoCloseable or Closeable is fine for try-with-resources statement. > ??? public interface Closeable extends AutoCloseable Yep, I see what you're talking about.? I completely missed that interface relationship. > >> ? * SSLContextTemplate >> ????? o 505: Is there any benefit to initializing the SSLContext using a >> ??????? PKIXParameters object with the date fixed to sometime in between >> ??????? 2018 and 2028 (the soonest expiration date of all the certs in >> ??????? the test).? This way you'd never have to worry about things >> ??????? expiring.? I know we don't do this in most of our tests, dunno >> ??????? why it just occurred to me now. >> > Good point!? It's a really nice enhancement! > > I had pushed this template in another bug fix. Let's do it separately. > I filed a new bug for tracking this enhancement. > ??? https://bugs.openjdk.java.net/browse/JDK-8215509 Sounds good to me.? The review as a whole looks good. --Jamil > > Thanks, > Xuelei > > >> The rest looks OK to me. >> >> --Jamil >> >> On 12/17/2018 9:52 AM, Xue-Lei Fan wrote: >>> ping ... >>> >>> On 12/10/2018 1:14 PM, Xue-Lei Fan wrote: >>>> Hi, >>>> >>>> Please review the TLS 1.3 half-close issue in JDK. >>>> >>>> http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/ >>>> >>>> While trying to duplex close a TLS connection upon the half-close >>>> policy, there might be pending receiving data in the closing side, >>>> and result in a TCP RST during closing. The TCP RST may then cause >>>> the peer reading failure.? For example: >>>> 1. client and server establish a TLS 1.3 connection. >>>> 2. server sending the post-handshake NewSessionTicket message. >>>> 3. client send the application data, and then close the connection. >>>> 4. as the client does not call to read the post-handshake message, >>>> the connection close will cause a TCP RST. >>>> 5. server trying to read the client application data, but the >>>> socket may be impacted by the TCP RST, and the reading can fail. >>>> >>>> It would not be an issue any more if the client could read the >>>> post-handshake message, explicit or implicit. >>>> >>>> I would like applications consider to use half-close policy, and >>>> moving away from the duplex-close policy. >>>> >>>> The basic idea of the fix is trying to use up buffered network >>>> input before close the socket.? As is an implicit behavior to >>>> consume the post-handshake message, and mitigate the impact of it. >>>> >>>> This fix is not a perfect one.? It is just a workaround for >>>> duplex-close.? I'm open to hear more ideas. >>>> >>>> Thanks, >>>> Xuelei >> From jamil.j.nimeh at oracle.com Mon Dec 17 22:23:04 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Dec 2018 14:23:04 -0800 Subject: Possible bug in SSLEngine / SSLSession implementation In-Reply-To: <74038A5B-8170-4746-ABFF-3F55637458EA@googlemail.com> References: <4dd3a000-de8c-c49c-98b8-553ef247812b@oracle.com> <74038A5B-8170-4746-ABFF-3F55637458EA@googlemail.com> Message-ID: <4613be88-4caa-c37f-9d0a-518260142d6c@oracle.com> Yes, I think so.? I'm not sure if we're going to make a separate issue for this specifically or handle it as part of a larger session management improvement we're working on. --Jamil On 12/17/2018 11:13 AM, Norman Maurer wrote: > So is what I see something that should be fixed in general ? > > Like I said it does not matter if its TLSv1.3 or earlier. > > Bye > Norman > > >> On 12. Dec 2018, at 15:42, Norman Maurer >> > >> wrote: >> >> Hi Jamil, >> >> This was just noticed during a test which uses TLS1.2. >> >>> On 12. Dec 2018, at 15:35, Jamil Nimeh >> > wrote: >>> >>> Hi Norman, the new handshaker does return a new SSLSession object.? >>> Part of JDK-8212885 fixes the lack of propagation of session values >>> across session objects, though that fix was largely in the context >>> of TLS 1.3.? There is a backport set for it, but it is not yet >>> complete as far as I'm aware.? Are you doing TLS 1.3 sessions?? If >>> so, are you able to try it with the latest JDK? >>> >>> One of the items we're going to be tacking soon is better TLS >>> session object management and new session ticket management so we >>> can avoid these value propagation issues in the future. >>> >>> --Jamil >>> >>> On 12/11/2018 11:59 PM, Norman Maurer wrote: >>>> Hi all, >>>> >>>> While working on some unit tests in netty I noticed that there may >>>> be a bug in the JDK implementation of SSLEngine / SSLSession. If >>>> its not a but it is at least surprising I would say. >>>> >>>> >>>> So it seems like before the handshake all values that are set on >>>> the SSLSession via putValue are shared across SSLEngine instances. >>>> Is this by design or a bug ? I could not find anything I the java >>>> docs that would tell me this is by design. It only states: "Until >>>> the initial handshake has completed, this method returns a session >>>> object which reports an invalid cipher suite >>>> of??SSL_NULL_WITH_NULL_NULL?. This does not sound like it will be >>>> the same object every time and so it would share the values. >>>> >>>> You can find a reproducer which will throw an exception here: >>>> >>>> https://github.com/normanmaurer/jdk_ssl_session_reproducer >>>> >>>> >>>> I did reproduce this with the latest java8 and java11 releases but >>>> I am almost sure it also exists in other versions. >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Dec 17 22:25:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 08:25:01 +1000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: References: Message-ID: Hi Matthias, On 17/12/2018 6:59 pm, Baesken, Matthias wrote: > Hello, please review the following change. > I noticed that we miss at some places (for example in case of early returns) > where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements call. > > In VirtualMachineImpl.c I also removed a check for isCopy (is the returned byte array a copy ?) > because from what I read at > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html > > the ReleaseByteArrayElements routine should always be called. That's not clear to me. My reading is that you only need to release if you have changes you need to ensure are written back and that is only needed if a copy was made. That said, the change seem semantically correct and harmless in this case. --- src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. Also you change seem wrong to me because it will commit the changes in the buffer even if we "abort" here: 735 if (bytesRead != numBytes) { 736 return 0; 737 } so it seems to me if you really want to release on all paths then the error paths should use a mode of JNI_ABORT and only the success path should use mode 0. --- src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m This change seems okay, though again potentially not necessary - as we never commit any changes. Thanks, David ----- > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8215411 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ > > > Thanks, Matthias > From dean.long at oracle.com Mon Dec 17 22:49:54 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 17 Dec 2018 14:49:54 -0800 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client Message-ID: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8214329 http://cr.openjdk.java.net/~dlong/8214329/webrev/ In "8212605: Pure-Java implementation of AccessController.doPrivileged", the stackwalk in JVM_GetStackAccessControlContext was changed from using a vframeStream to using a javaVFrame, so that it could access locals. However this caused a regression because javaVFrame has more overhead.?? JDK-8215205 fixes the problem by allowing the use of javaVFrame only when needed. This change reverts JVM_GetStackAccessControlContext back to using vframeStream, and uses the new API in JDK-8215205 to get a javaVFrame lazily.? It also removes two unnecessary calls to java_sender(). dl From mandy.chung at oracle.com Mon Dec 17 22:55:30 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Dec 2018 14:55:30 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> Message-ID: <1dd75b6f-35d7-98be-2fde-10a57a6a816b@oracle.com> This looks okay to me. Mandy On 12/14/18 4:59 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8214583 > http://cr.openjdk.java.net/~dlong/8214583/webrev > > This change includes two new regression test that demonstrate the > problem, and a fix that allows the tests > to pass. > > The problem happens when the JIT compiler's escape analysis eliminates > the allocation of the AccessControlContext object passed to > doPrivileged.? The compiler thinks this is safe because it does not > see that the object "escapes".? However, getContext needs to be able > to find the object using a stack walk, so we need a way to tell the > compiler that it does indeed escape.? To do this we pass the value to > a native method that does nothing. > > Microbenchmark results: > > jdk12-b18: > > Benchmark??????????????? Mode? Cnt??? Score?? Error? Units > DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op > DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op > > > jdk12-b19: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op > > this fix: > > Benchmark??????????????? Mode? Cnt? Score??? Error? Units > DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op > DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op > > > dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Mon Dec 17 23:30:40 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 17 Dec 2018 15:30:40 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <1dd75b6f-35d7-98be-2fde-10a57a6a816b@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <1dd75b6f-35d7-98be-2fde-10a57a6a816b@oracle.com> Message-ID: <7f090392-e6aa-dfcb-47d3-92e27fe4cb76@oracle.com> Thanks Mandy. dl On 12/17/18 2:55 PM, Mandy Chung wrote: > This looks okay to me. > > Mandy > > On 12/14/18 4:59 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214583 >> http://cr.openjdk.java.net/~dlong/8214583/webrev >> >> This change includes two new regression test that demonstrate the >> problem, and a fix that allows the tests >> to pass. >> >> The problem happens when the JIT compiler's escape analysis >> eliminates the allocation of the AccessControlContext object passed >> to doPrivileged.? The compiler thinks this is safe because it does >> not see that the object "escapes".? However, getContext needs to be >> able to find the object using a stack walk, so we need a way to tell >> the compiler that it does indeed escape.? To do this we pass the >> value to a native method that does nothing. >> >> Microbenchmark results: >> >> jdk12-b18: >> >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >> >> >> jdk12-b19: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >> >> this fix: >> >> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >> >> >> dl > From david.holmes at oracle.com Tue Dec 18 00:19:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 10:19:51 +1000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: References: Message-ID: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> Correction ... On 18/12/2018 8:25 am, David Holmes wrote: > Hi Matthias, > > On 17/12/2018 6:59 pm, Baesken, Matthias wrote: >> Hello, please review the following change. >> I noticed that we miss at some places (for example in case of early >> returns) >> where GetByteArrayElements is used,? the corresponding >> ReleaseByteArrayElements? call. >> >> In VirtualMachineImpl.c? I also removed a check for isCopy (is the >> returned byte array a copy ?) >> because from what I read at >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html >> >> >> the ReleaseByteArrayElements? routine should always be called. > > That's not clear to me. My reading is that you only need to release if > you have changes you need to ensure are written back and that is only > needed if a copy was made. Jc pointed out to me that if a copy is made you may need to release to avoid a memory leak. But that is where the mode flags come in - and again only relevant if a copy was made. But as per: https://developer.android.com/training/articles/perf-jni if a copy is not made and pinning is used (as with the "critical" variants) then you also need to release to un-pin. So code should call release, with an appropriate mode, based on whether isCopy was true**, and whether changed data should be written back. ** mode is ignored if not working on a copy so you can just set it assuming a copy was made. Note that the hotspot implementation always makes a copy for GextXXXArrayElements, and the ReleaseXXXArrayElements knows this and so will always free the buffer that is passed in (other than for mode JNI_COMMIT of course). Cheers, David ----- > That said, the change seem semantically correct and harmless in this case. > --- > > src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp > > AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and > THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. > > Also you change seem wrong to me because it will commit the changes in > the buffer even if we "abort" here: > > 735?? if (bytesRead != numBytes) { > ?736????? return 0; > ?737?? } > > so it seems to me if you really want to release on all paths then the > error paths should use a mode of JNI_ABORT and only the success path > should use mode 0. > > --- > > ?src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > > This change seems okay, though again potentially not necessary - as we > never commit any changes. > > Thanks, > David > ----- > >> >> bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8215411 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ >> >> >> Thanks, Matthias >> From valerie.peng at oracle.com Tue Dec 18 00:41:51 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 17 Dec 2018 16:41:51 -0800 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails Message-ID: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ Regards, Valerie From xuelei.fan at oracle.com Tue Dec 18 01:26:16 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 17 Dec 2018 17:26:16 -0800 Subject: Code Review Request JDK-8215443: The use of TransportContext.fatal() leads to bad coding style In-Reply-To: <7b3043f3-c3d9-ea76-0a7b-8b136994d9d4@oracle.com> References: <5d018528-e304-7edc-9d1c-61409c2aac51@oracle.com> <7b3043f3-c3d9-ea76-0a7b-8b136994d9d4@oracle.com> Message-ID: <246fedfa-8230-20e4-6a3f-1fbca164047f@oracle.com> On 12/17/2018 1:17 PM, Anthony Scarpino wrote: > It looks like in TransportContext.java:68, you had a mistype that added > "fa" to the end of a comment. > Oops, I will update it. > Also in fatal():267, did you plan to return the exception and have the > calling method throw the exception?? As is, the exception is never > return and fatal() continues to throw the exceptions. > I considered to return the exception. I'm not very confident with if I searched out all use of the fatal() methods. For safe, I kept to use thrown exception instead. If the method is updated later that there is a case that now exception get thrown, there will be a compiling issue. Are you OK with it? Thanks, Xuelei > Tony > > On 12/15/18 7:51 AM, Xue-Lei Fan wrote: >> Hi, >> >> Could I have the update reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8215443/webrev.00/ >> >> The TransportContext.fatal() methods always throw exception. While the >> compiler does not aware of it, and may not happy without following a >> return statement.? Currently, a lot never executable return statements >> are inserted.? As make the code hard to read (thanks for Jamil and >> Tony's points).? For example: >> >> ???? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >> ???? return null;??? // fatal() always throws, make the compiler happy. >> >> In this update, I changed the fatal() method with a return value: >> >> -??? void fatal(Alert alert, ... >> +??? SSLException fatal(Alert alert, ... >> >> Then we can change the use of method as: >> >> -??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >> -??? return null;??? // fatal() always throws, make the compiler happy. >> +??? throw shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >> >> The changeset is mostly about removing the never executed return >> statements and add the 'throw' keyword to lines that use the fatal() >> methods. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Tue Dec 18 03:14:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Dec 2018 11:14:06 +0800 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> Message-ID: <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> Hi Valerie, Please put lines 87 and 100 into the if-not-null block. Otherwise fine. Do you think we can enhance the Signature::setParameter method and claim a null parameter is not meaningful at all and should not have any effect on the internal state of the signature object? Otherwise an application really has no idea whether to call it. Thanks, Max > On Dec 18, 2018, at 8:41 AM, Valerie Peng wrote: > > Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 > > Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ > > Regards, > Valerie > > From Alan.Bateman at oracle.com Tue Dec 18 07:21:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Dec 2018 07:21:46 +0000 Subject: RFR: 8214570 : Use {@systemProperty} for definitions of system properties In-Reply-To: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> References: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> Message-ID: <85116d83-7d73-4fbe-fa17-f9f0ab729d87@oracle.com> This looks okay to me (cc'ing security-dev as that is where the smart card I/O API is maintained) On 18/12/2018 05:23, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review the changes for > https://bugs.openjdk.java.net/browse/JDK-8214570 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214570/webrev.00/ > > Thanks, > Priya > > From matthias.baesken at sap.com Tue Dec 18 08:52:46 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 08:52:46 +0000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> References: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> Message-ID: Hi JC / David, thanks for the input . I'm not really sure what you want me to change David, am I right that I can keep the changes to src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c but adjust src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp to also handle theis potential early return 723 IDebugDataSpaces* ptrIDebugDataSpaces = (IDebugDataSpaces*) env->GetLongField(obj, 724 ptrIDebugDataSpaces_ID); 725 CHECK_EXCEPTION_(0); ? > > Also you change seem wrong to me because it will commit the changes in > > the buffer even if we "abort" here: > > > > 735 if (bytesRead != numBytes) { > > 736 return 0; > > 737 } > > The spec says : https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html >ReleaseArrayElements Routines >void ReleaseArrayElements(JNIEnv *env, ArrayType array, NativeType *elems, jint mode); > >A family of functions that informs the VM that the native code no longer needs access to elems. The elems argument is a pointer derived from array using the corresponding > GetArrayElements() function. If necessary, this function copies back all changes made to elems to the original array. So shouldn't I tell the VM , that the native code no longer needs access to bytePtr before returning here 735 if (bytesRead != numBytes) { 736 return 0; 737 } ? Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 18. Dezember 2018 01:20 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; serviceability- > dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss > corresponding Release > > Correction ... > > On 18/12/2018 8:25 am, David Holmes wrote: > > Hi Matthias, > > > > On 17/12/2018 6:59 pm, Baesken, Matthias wrote: > >> Hello, please review the following change. > >> I noticed that we miss at some places (for example in case of early > >> returns) > >> where GetByteArrayElements is used,? the corresponding > >> ReleaseByteArrayElements? call. > >> > >> In VirtualMachineImpl.c? I also removed a check for isCopy (is the > >> returned byte array a copy ?) > >> because from what I read at > >> > >> > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function > s.html > >> > >> > >> the ReleaseByteArrayElements? routine should always be called. > > > > That's not clear to me. My reading is that you only need to release if > > you have changes you need to ensure are written back and that is only > > needed if a copy was made. > > Jc pointed out to me that if a copy is made you may need to release to > avoid a memory leak. But that is where the mode flags come in - and > again only relevant if a copy was made. > > But as per: > > https://developer.android.com/training/articles/perf-jni > > if a copy is not made and pinning is used (as with the "critical" > variants) then you also need to release to un-pin. > > So code should call release, with an appropriate mode, based on whether > isCopy was true**, and whether changed data should be written back. > > ** mode is ignored if not working on a copy so you can just set it > assuming a copy was made. > > Note that the hotspot implementation always makes a copy for > GextXXXArrayElements, and the ReleaseXXXArrayElements knows this and > so > will always free the buffer that is passed in (other than for mode > JNI_COMMIT of course). > > Cheers, > David > ----- > > > That said, the change seem semantically correct and harmless in this case. > > --- > > > > src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp > > > > AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and > > THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. > > > > Also you change seem wrong to me because it will commit the changes in > > the buffer even if we "abort" here: > > > > 735?? if (bytesRead != numBytes) { > > ?736????? return 0; > > ?737?? } > > > > so it seems to me if you really want to release on all paths then the > > error paths should use a mode of JNI_ABORT and only the success path > > should use mode 0. > > > > --- > > > > ?src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > > > > This change seems okay, though again potentially not necessary - as we > > never commit any changes. > > > > Thanks, > > David > > ----- > > > >> > >> bug/webrev : > >> > >> https://bugs.openjdk.java.net/browse/JDK-8215411 > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ > >> > >> > >> Thanks, Matthias > >> From david.holmes at oracle.com Tue Dec 18 09:03:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 19:03:48 +1000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: References: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> Message-ID: <7c2f5dc2-9bbe-29f9-8be0-2613267f60dc@oracle.com> Hi Matthias, On 18/12/2018 6:52 pm, Baesken, Matthias wrote: > Hi JC / David, thanks for the input . > > I'm not really sure what you want me to change David, am I right that I can keep the changes to > > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c Yes. > but adjust > > src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp > > to also handle theis potential early return > > 723 IDebugDataSpaces* ptrIDebugDataSpaces = (IDebugDataSpaces*) env->GetLongField(obj, > 724 ptrIDebugDataSpaces_ID); > 725 CHECK_EXCEPTION_(0); > > ? And I think: 730 THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: ReadVirtual failed!", 0); as I assume that won't actually return normally. >>> Also you change seem wrong to me because it will commit the changes in >>> the buffer even if we "abort" here: >>> >>> 735 if (bytesRead != numBytes) { >>> 736 return 0; >>> 737 } >>> > > The spec says : > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html > >> ReleaseArrayElements Routines >> void ReleaseArrayElements(JNIEnv *env, ArrayType array, NativeType *elems, jint mode); >> >> A family of functions that informs the VM that the native code no longer needs access to elems. The elems argument is a pointer derived from array using the corresponding >> GetArrayElements() function. If necessary, this function copies back all changes made to elems to the original array. > > So shouldn't I tell the VM , that the native code no longer needs access to bytePtr before returning here > > 735 if (bytesRead != numBytes) { > 736 return 0; > 737 } > > ? There are two aspects to release: 1. the actual release (or "I don't need this any more") 2. committing any changes made back to the original array This code does: 728 if (ptrIDebugDataSpaces->ReadVirtual((ULONG64) address, (PVOID) bytePtr, 729 (ULONG)numBytes, &bytesRead) != S_OK) { which writes into the array. It then checks if we wrote what we expected: 735 if (bytesRead != numBytes) { 736 return 0; 737 } If we didn't read what was expected what should happen to the original array? Should it be left untouched or updated with the unexpected input? I would say left untouched and that is what the original code did. If everything succeeds you should do the release with mode 0; but if taking an error exit the release should use mode JNI_ABORT so no changes are written back. Cheers, David > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 18. Dezember 2018 01:20 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' ; serviceability- >> dev at openjdk.java.net; security-dev at openjdk.java.net >> Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss >> corresponding Release >> >> Correction ... >> >> On 18/12/2018 8:25 am, David Holmes wrote: >>> Hi Matthias, >>> >>> On 17/12/2018 6:59 pm, Baesken, Matthias wrote: >>>> Hello, please review the following change. >>>> I noticed that we miss at some places (for example in case of early >>>> returns) >>>> where GetByteArrayElements is used,? the corresponding >>>> ReleaseByteArrayElements? call. >>>> >>>> In VirtualMachineImpl.c? I also removed a check for isCopy (is the >>>> returned byte array a copy ?) >>>> because from what I read at >>>> >>>> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function >> s.html >>>> >>>> >>>> the ReleaseByteArrayElements? routine should always be called. >>> >>> That's not clear to me. My reading is that you only need to release if >>> you have changes you need to ensure are written back and that is only >>> needed if a copy was made. >> >> Jc pointed out to me that if a copy is made you may need to release to >> avoid a memory leak. But that is where the mode flags come in - and >> again only relevant if a copy was made. >> >> But as per: >> >> https://developer.android.com/training/articles/perf-jni >> >> if a copy is not made and pinning is used (as with the "critical" >> variants) then you also need to release to un-pin. >> >> So code should call release, with an appropriate mode, based on whether >> isCopy was true**, and whether changed data should be written back. >> >> ** mode is ignored if not working on a copy so you can just set it >> assuming a copy was made. >> >> Note that the hotspot implementation always makes a copy for >> GextXXXArrayElements, and the ReleaseXXXArrayElements knows this and >> so >> will always free the buffer that is passed in (other than for mode >> JNI_COMMIT of course). >> >> Cheers, >> David >> ----- >> >>> That said, the change seem semantically correct and harmless in this case. >>> --- >>> >>> src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp >>> >>> AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and >>> THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. >>> >>> Also you change seem wrong to me because it will commit the changes in >>> the buffer even if we "abort" here: >>> >>> 735?? if (bytesRead != numBytes) { >>> ?736????? return 0; >>> ?737?? } >>> >>> so it seems to me if you really want to release on all paths then the >>> error paths should use a mode of JNI_ABORT and only the success path >>> should use mode 0. >>> >>> --- >>> >>> ?src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m >>> >>> This change seems okay, though again potentially not necessary - as we >>> never commit any changes. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8215411 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ >>>> >>>> >>>> Thanks, Matthias >>>> From weijun.wang at oracle.com Tue Dec 18 09:49:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Dec 2018 17:49:05 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <4dbe1d94-9c3a-c90e-71ad-3608cacfe41e@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <4C812EA6-4FCC-476F-81DF-8E45B7523888@oracle.com> <5940fc0f-cf42-5fe8-3c59-7e386e8d02d4@oracle.com> <50097F7C-B78A-4B62-B4D3-54C7B3738DA9@oracle.com> <4dbe1d94-9c3a-c90e-71ad-3608cacfe41e@oracle.com> Message-ID: <93624FC7-186C-4886-83D2-ACCD49D6AF6E@oracle.com> > On Dec 15, 2018, at 5:09 AM, Sean Mullan wrote: > > On 12/12/18 10:57 AM, Weijun Wang wrote: >> Thanks. Will you please also take a look at the release note athttps://bugs.openjdk.java.net/browse/JDK-8215293? > > I'm not sure about including the second sentence: "In particular, the algorithm for certificate protection and MacData can be set to "NONE" so that a PKCS #12 keystore that only contains certificates does not require a password." OK. Release note updated. > > I would probably remove this sentence and leave specific details and use cases like that to the programming guides. We can add some examples to the keytool doc once cacerts is migrated to password-less. Thanks, Max > > --Sean From sean.mullan at oracle.com Tue Dec 18 12:30:24 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 07:30:24 -0500 Subject: RFR: 8214570 : Use {@systemProperty} for definitions of system properties In-Reply-To: <85116d83-7d73-4fbe-fa17-f9f0ab729d87@oracle.com> References: <2af2f47c-2f22-2c6e-b8ee-65226a6e0e70@oracle.com> <85116d83-7d73-4fbe-fa17-f9f0ab729d87@oracle.com> Message-ID: <95ed2219-2a20-67b4-0d65-dc689bbe4c4c@oracle.com> Update the copyright date. Otherwise looks fine. --Sean On 12/18/18 2:21 AM, Alan Bateman wrote: > This looks okay to me > > (cc'ing security-dev as that is where the smart card I/O API is maintained) > > > On 18/12/2018 05:23, Priya Lakshmi Muthuswamy wrote: >> Hi, >> >> Kindly review the changes for >> https://bugs.openjdk.java.net/browse/JDK-8214570 >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214570/webrev.00/ >> >> Thanks, >> Priya >> >> > From sean.mullan at oracle.com Tue Dec 18 13:06:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 08:06:19 -0500 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> Message-ID: <8ee1d497-f139-1026-923d-3356215f9c20@oracle.com> Looks good. --Sean On 12/17/18 7:41 PM, Valerie Peng wrote: > Any one has time to review this straightforward fix? Details on cause > and fix is elaborated in the link below: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 > > Webrev can be found at > http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ > > Regards, > Valerie > > From sean.mullan at oracle.com Tue Dec 18 13:14:49 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 08:14:49 -0500 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> Message-ID: On 12/17/18 10:14 PM, Weijun Wang wrote: > Hi Valerie, > > Please put lines 87 and 100 into the if-not-null block. Otherwise fine. > > Do you think we can enhance the Signature::setParameter method and claim a null parameter is not meaningful at all and should not have any effect on the internal state of the signature object? Otherwise an application really has no idea whether to call it. That would be a specification change, so it can't be as part of this fix, since it is past RDP. It is also has a somewhat high compatibility risk, since it would require existing 3rd-party providers (such as BouncyCastle) that throw NPE to change their implementation. It is unfortunate that the behavior of a null parameter was never clearly defined. --Sean > > Thanks, > Max > >> On Dec 18, 2018, at 8:41 AM, Valerie Peng wrote: >> >> Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 >> >> Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ >> >> Regards, >> Valerie >> >> > From weijun.wang at oracle.com Tue Dec 18 13:22:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Dec 2018 21:22:54 +0800 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> Message-ID: <52A908E8-07C9-468D-990E-E2C4CD5144E0@oracle.com> > On Dec 18, 2018, at 9:14 PM, Sean Mullan wrote: > > On 12/17/18 10:14 PM, Weijun Wang wrote: >> Hi Valerie, >> Please put lines 87 and 100 into the if-not-null block. Otherwise fine. >> Do you think we can enhance the Signature::setParameter method and claim a null parameter is not meaningful at all and should not have any effect on the internal state of the signature object? Otherwise an application really has no idea whether to call it. > > That would be a specification change, so it can't be as part of this fix, since it is past RDP. I understand. > It is also has a somewhat high compatibility risk, since it would require existing 3rd-party providers (such as BouncyCastle) that throw NPE to change their implementation. Even if we do not specify that a certain exception must be thrown when null is used, we need to make sure setParameter(null) is completely useless, which means an implementation shall not use it to do any meaningful thing to set (or reset, or reinitialize) anything. The following codes must be equivalent to no-op: try { sig.setParameter(null); } catch (Exception e) { // } Thanks, Max > > It is unfortunate that the behavior of a null parameter was never clearly defined. > > --Sean > >> Thanks, >> Max >>> On Dec 18, 2018, at 8:41 AM, Valerie Peng wrote: >>> >>> Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 >>> >>> Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ >>> >>> Regards, >>> Valerie >>> >>> From sean.mullan at oracle.com Tue Dec 18 15:12:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 10:12:13 -0500 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> Message-ID: <0ecece2d-4f29-4e3a-2306-eb07e91cc7c5@oracle.com> Looks good, although I think someone from the HotSpot Group should also review it. On the bug, can you add the details below into the Description? Also, since you have no regression test, you will need a noreg label (I guess noreg-perf would be appropriate). Also, the bug says it is BlockedBy JDK-8215205 which should probably be removed. Thanks, Sean On 12/17/18 5:49 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8214329 > http://cr.openjdk.java.net/~dlong/8214329/webrev/ > > In "8212605: Pure-Java implementation of AccessController.doPrivileged", > the stackwalk in JVM_GetStackAccessControlContext was changed from using > a vframeStream to using a javaVFrame, so that it could access locals. > However this caused a regression because javaVFrame has more overhead. > JDK-8215205 fixes the problem by allowing the use of javaVFrame only > when needed. > > This change reverts JVM_GetStackAccessControlContext back to using > vframeStream, and uses the new API in JDK-8215205 to get a javaVFrame > lazily.? It also removes two unnecessary calls to java_sender(). > > dl From dean.long at oracle.com Tue Dec 18 16:26:26 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Dec 2018 08:26:26 -0800 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> Message-ID: <0c8463a0-2da0-60ec-e182-91d81f45c337@oracle.com> Thanks Tobias. dl On 12/18/18 4:08 AM, Tobias Hartmann wrote: > Hi Dean, > > this looks good to me. > > Best regards, > Tobias > > On 17.12.18 23:49, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214329 >> http://cr.openjdk.java.net/~dlong/8214329/webrev/ >> >> In "8212605: Pure-Java implementation of AccessController.doPrivileged", the stackwalk in >> JVM_GetStackAccessControlContext was changed from using a vframeStream to using a javaVFrame, so >> that it could access locals. However this caused a regression because javaVFrame has more >> overhead.?? JDK-8215205 fixes the problem by allowing the use of javaVFrame only when needed. >> >> This change reverts JVM_GetStackAccessControlContext back to using vframeStream, and uses the new >> API in JDK-8215205 to get a javaVFrame lazily.? It also removes two unnecessary calls to java_sender(). >> >> dl From dean.long at oracle.com Tue Dec 18 16:33:07 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Dec 2018 08:33:07 -0800 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: <0ecece2d-4f29-4e3a-2306-eb07e91cc7c5@oracle.com> References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> <0ecece2d-4f29-4e3a-2306-eb07e91cc7c5@oracle.com> Message-ID: <1ae3919b-33a2-c142-950e-03751cbfcfd7@oracle.com> On 12/18/18 7:12 AM, Sean Mullan wrote: > Looks good, although I think someone from the HotSpot Group should > also review it. > Thanks Sean.? Tobias reviewed it. > On the bug, can you add the details below into the Description? Sure. > Also, since you have no regression test, you will need a noreg label > (I guess noreg-perf would be appropriate). OK, thanks. > Also, the bug says it is BlockedBy JDK-8215205 which should probably > be removed. > That's because JDK-8215205 hasn't been pushed yet. dl > Thanks, > Sean > > On 12/17/18 5:49 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8214329 >> http://cr.openjdk.java.net/~dlong/8214329/webrev/ >> >> In "8212605: Pure-Java implementation of >> AccessController.doPrivileged", the stackwalk in >> JVM_GetStackAccessControlContext was changed from using a >> vframeStream to using a javaVFrame, so that it could access locals. >> However this caused a regression because javaVFrame has more >> overhead. JDK-8215205 fixes the problem by allowing the use of >> javaVFrame only when needed. >> >> This change reverts JVM_GetStackAccessControlContext back to using >> vframeStream, and uses the new API in JDK-8215205 to get a javaVFrame >> lazily.? It also removes two unnecessary calls to java_sender(). >> >> dl From matthias.baesken at sap.com Tue Dec 18 17:19:21 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 17:19:21 +0000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: <7c2f5dc2-9bbe-29f9-8be0-2613267f60dc@oracle.com> References: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> <7c2f5dc2-9bbe-29f9-8be0-2613267f60dc@oracle.com> Message-ID: Hello, here is an updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.1/ sawindbg.cpp has been adjusted . The exception cases mentioned now also call env->ReleaseByteArrayElements . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 18. Dezember 2018 10:04 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; serviceability- > dev at openjdk.java.net; security-dev at openjdk.java.net; JC Beyler > > Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss > corresponding Release > > Hi Matthias, > > On 18/12/2018 6:52 pm, Baesken, Matthias wrote: > > Hi JC / David, thanks for the input . > > > > I'm not really sure what you want me to change David, am I right that I can > keep the changes to > > > > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > > src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c > > Yes. > > > but adjust > > > > src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp > > > > to also handle theis potential early return > > > > 723 IDebugDataSpaces* ptrIDebugDataSpaces = (IDebugDataSpaces*) > env->GetLongField(obj, > > 724 ptrIDebugDataSpaces_ID); > > 725 CHECK_EXCEPTION_(0); > > > > ? > > And I think: > > 730 THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: ReadVirtual > failed!", 0); > > as I assume that won't actually return normally. > > >>> Also you change seem wrong to me because it will commit the changes > in > >>> the buffer even if we "abort" here: > >>> > >>> 735 if (bytesRead != numBytes) { > >>> 736 return 0; > >>> 737 } > >>> > > > > The spec says : > > > > > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function > s.html > > > >> ReleaseArrayElements Routines > >> void ReleaseArrayElements(JNIEnv *env, ArrayType > array, NativeType *elems, jint mode); > >> > >> A family of functions that informs the VM that the native code no longer > needs access to elems. The elems argument is a pointer derived from array > using the corresponding > >> GetArrayElements() function. If necessary, this function > copies back all changes made to elems to the original array. > > > > So shouldn't I tell the VM , that the native code no longer needs access to > bytePtr before returning here > > > > 735 if (bytesRead != numBytes) { > > 736 return 0; > > 737 } > > > > ? > > There are two aspects to release: > 1. the actual release (or "I don't need this any more") > 2. committing any changes made back to the original array > > This code does: > > 728 if (ptrIDebugDataSpaces->ReadVirtual((ULONG64) address, (PVOID) > bytePtr, > 729 (ULONG)numBytes, &bytesRead) != > S_OK) { > > which writes into the array. It then checks if we wrote what we expected: > > 735 if (bytesRead != numBytes) { > 736 return 0; > 737 } > > If we didn't read what was expected what should happen to the original > array? Should it be left untouched or updated with the unexpected input? > I would say left untouched and that is what the original code did. > > If everything succeeds you should do the release with mode 0; but if > taking an error exit the release should use mode JNI_ABORT so no changes > are written back. > > Cheers, > David > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Dienstag, 18. Dezember 2018 01:20 > >> To: Baesken, Matthias ; 'hotspot- > >> dev at openjdk.java.net' ; serviceability- > >> dev at openjdk.java.net; security-dev at openjdk.java.net > >> Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss > >> corresponding Release > >> > >> Correction ... > >> > >> On 18/12/2018 8:25 am, David Holmes wrote: > >>> Hi Matthias, > >>> > >>> On 17/12/2018 6:59 pm, Baesken, Matthias wrote: > >>>> Hello, please review the following change. > >>>> I noticed that we miss at some places (for example in case of early > >>>> returns) > >>>> where GetByteArrayElements is used,? the corresponding > >>>> ReleaseByteArrayElements? call. > >>>> > >>>> In VirtualMachineImpl.c? I also removed a check for isCopy (is the > >>>> returned byte array a copy ?) > >>>> because from what I read at > >>>> > >>>> > >> > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function > >> s.html > >>>> > >>>> > >>>> the ReleaseByteArrayElements? routine should always be called. > >>> > >>> That's not clear to me. My reading is that you only need to release if > >>> you have changes you need to ensure are written back and that is only > >>> needed if a copy was made. > >> > >> Jc pointed out to me that if a copy is made you may need to release to > >> avoid a memory leak. But that is where the mode flags come in - and > >> again only relevant if a copy was made. > >> > >> But as per: > >> > >> https://developer.android.com/training/articles/perf-jni > >> > >> if a copy is not made and pinning is used (as with the "critical" > >> variants) then you also need to release to un-pin. > >> > >> So code should call release, with an appropriate mode, based on whether > >> isCopy was true**, and whether changed data should be written back. > >> > >> ** mode is ignored if not working on a copy so you can just set it > >> assuming a copy was made. > >> > >> Note that the hotspot implementation always makes a copy for > >> GextXXXArrayElements, and the ReleaseXXXArrayElements knows this > and > >> so > >> will always free the buffer that is passed in (other than for mode > >> JNI_COMMIT of course). > >> > >> Cheers, > >> David > >> ----- > >> > >>> That said, the change seem semantically correct and harmless in this > case. > >>> --- > >>> > >>> src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp > >>> > >>> AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and > >>> THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. > >>> > >>> Also you change seem wrong to me because it will commit the changes > in > >>> the buffer even if we "abort" here: > >>> > >>> 735?? if (bytesRead != numBytes) { > >>> ?736????? return 0; > >>> ?737?? } > >>> > >>> so it seems to me if you really want to release on all paths then the > >>> error paths should use a mode of JNI_ABORT and only the success path > >>> should use mode 0. > >>> > >>> --- > >>> > >>> ?src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > >>> > >>> This change seems okay, though again potentially not necessary - as we > >>> never commit any changes. > >>> > >>> Thanks, > >>> David > >>> ----- > >>> > >>>> > >>>> bug/webrev : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8215411 > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ > >>>> > >>>> > >>>> Thanks, Matthias > >>>> From anthony.scarpino at oracle.com Tue Dec 18 17:18:36 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 18 Dec 2018 09:18:36 -0800 Subject: Code Review Request JDK-8215443: The use of TransportContext.fatal() leads to bad coding style In-Reply-To: <246fedfa-8230-20e4-6a3f-1fbca164047f@oracle.com> References: <5d018528-e304-7edc-9d1c-61409c2aac51@oracle.com> <7b3043f3-c3d9-ea76-0a7b-8b136994d9d4@oracle.com> <246fedfa-8230-20e4-6a3f-1fbca164047f@oracle.com> Message-ID: <28388de1-45dc-07ca-1620-9a8c61f594ea@oracle.com> On 12/17/18 5:26 PM, Xue-Lei Fan wrote: > On 12/17/2018 1:17 PM, Anthony Scarpino wrote: >> It looks like in TransportContext.java:68, you had a mistype that >> added "fa" to the end of a comment. >> > Oops, I will update it. > >> Also in fatal():267, did you plan to return the exception and have the >> calling method throw the exception?? As is, the exception is never >> return and fatal() continues to throw the exceptions. >> > I considered to return the exception.? I'm not very confident with if I > searched out all use of the fatal() methods.? For safe, I kept to use > thrown exception instead. If the method is updated later that there is a > case that now exception get thrown, there will be a compiling issue. Are > you OK with it? Since the stacktrace is based on the exception's creation and not where it's thrown, I guess there's no reason to return the value. As you have it now should be fine. Tony > > Thanks, > Xuelei > >> Tony >> >> On 12/15/18 7:51 AM, Xue-Lei Fan wrote: >>> Hi, >>> >>> Could I have the update reviewed? >>> ??? http://cr.openjdk.java.net/~xuelei/8215443/webrev.00/ >>> >>> The TransportContext.fatal() methods always throw exception. While >>> the compiler does not aware of it, and may not happy without >>> following a return statement.? Currently, a lot never executable >>> return statements are inserted.? As make the code hard to read >>> (thanks for Jamil and Tony's points).? For example: >>> >>> ???? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >>> ???? return null;??? // fatal() always throws, make the compiler happy. >>> >>> In this update, I changed the fatal() method with a return value: >>> >>> -??? void fatal(Alert alert, ... >>> +??? SSLException fatal(Alert alert, ... >>> >>> Then we can change the use of method as: >>> >>> -??? shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >>> -??? return null;??? // fatal() always throws, make the compiler happy. >>> +??? throw shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, ...); >>> >>> The changeset is mostly about removing the never executed return >>> statements and add the 'throw' keyword to lines that use the fatal() >>> methods. >>> >>> Thanks, >>> Xuelei >> From sean.mullan at oracle.com Tue Dec 18 19:00:18 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 14:00:18 -0500 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: <1ae3919b-33a2-c142-950e-03751cbfcfd7@oracle.com> References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> <0ecece2d-4f29-4e3a-2306-eb07e91cc7c5@oracle.com> <1ae3919b-33a2-c142-950e-03751cbfcfd7@oracle.com> Message-ID: On 12/18/18 11:33 AM, dean.long at oracle.com wrote: >> Also, the bug says it is BlockedBy JDK-8215205 which should probably >> be removed. >> > > That's because JDK-8215205 hasn't been pushed yet. Ok, but isn't BlockedBy supposed to mean you can't fix this issue until the one that it is blocked by is fixed? That's not the case with this issue though, right? --Sean From sean.mullan at oracle.com Tue Dec 18 19:04:46 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Dec 2018 14:04:46 -0500 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> <0ecece2d-4f29-4e3a-2306-eb07e91cc7c5@oracle.com> <1ae3919b-33a2-c142-950e-03751cbfcfd7@oracle.com> Message-ID: On 12/18/18 2:00 PM, Sean Mullan wrote: > On 12/18/18 11:33 AM, dean.long at oracle.com wrote: >>> Also, the bug says it is BlockedBy JDK-8215205 which should probably >>> be removed. >>> >> >> That's because JDK-8215205 hasn't been pushed yet. > > Ok, but isn't BlockedBy supposed to mean you can't fix this issue until > the one that it is blocked by is fixed? That's not the case with this > issue though, right? Never mind the above, I see now you are using a new method added in JDK-8215205. --Sean From tobias.hartmann at oracle.com Tue Dec 18 12:08:46 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 18 Dec 2018 13:08:46 +0100 Subject: 12 RFR(XS) 8214329: SwingMark SubMenus 9% regression in 12-b19 on Linux client In-Reply-To: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> References: <55c235ee-1733-42e2-e0f7-e75016dacd05@oracle.com> Message-ID: Hi Dean, this looks good to me. Best regards, Tobias On 17.12.18 23:49, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8214329 > http://cr.openjdk.java.net/~dlong/8214329/webrev/ > > In "8212605: Pure-Java implementation of AccessController.doPrivileged", the stackwalk in > JVM_GetStackAccessControlContext was changed from using a vframeStream to using a javaVFrame, so > that it could access locals. However this caused a regression because javaVFrame has more > overhead.?? JDK-8215205 fixes the problem by allowing the use of javaVFrame only when needed. > > This change reverts JVM_GetStackAccessControlContext back to using vframeStream, and uses the new > API in JDK-8215205 to get a javaVFrame lazily.? It also removes two unnecessary calls to java_sender(). > > dl From dean.long at oracle.com Tue Dec 18 20:52:49 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Dec 2018 12:52:49 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> Message-ID: David, can I list you as a reviewer? dl On 12/16/18 8:47 PM, dean.long at oracle.com wrote: > On 12/16/18 7:39 PM, dean.long at oracle.com wrote: >> On 12/16/18 7:03 PM, David Holmes wrote: >>> On 17/12/2018 12:49 pm, dean.long at oracle.com wrote: >>>> On 12/16/18 4:06 PM, David Holmes wrote: >>>>> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>>>> >>>>>> This change includes two new regression test that demonstrate the >>>>>> problem, and a fix that allows the tests >>>>>> to pass. >>>>>> >>>>>> The problem happens when the JIT compiler's escape analysis >>>>>> eliminates the allocation of the AccessControlContext object >>>>>> passed to doPrivileged.? The compiler thinks this is safe because >>>>>> it does not see that the object "escapes". >>>>> >>>>> Then surely the compiler's notion of "escapes" needs to be updated! >>>>> >>>> >>>> The compiler can inline the callee method and see that the value >>>> doesn't escape.? This is a valid optimization in cases where the >>>> callee method is known. >>> >>> But it's not a valid optimization in this case, so my comment stands. >>> >>> Is this stack walking something this is guaranteed by the spec to be >>> always valid (and hence the JIT is violating the rules), or is the >>> stack walking code making assumptions about whether it will find the >>> context object in the stack? >>> >> >> The stack walking is in the VM and is an internal implementation >> detail, not part of the AccessController API spec.? A different >> thread running normal Java code would never be able to see a >> non-escaping value.? The stack walking code does need to find the >> context object in the stack.? Non-escaping objects won't show up in >> the stack. >> >>> If we have to hack around this with an annotation I'd rather see a >>> specific annotation that addresses the problematic usecase than a >>> generic "don't inline" one. E.g. @StackVisible or something like that. >>> >> >> That sounds like a good idea for 13, but would require changes to >> both C2 and Graal, and it seems a little risky compared to using >> existing mechanisms. >> > > I forgot to address this in my last reply, but I'm not suggesting a > @DontInline annotation.? That was Claes.? My fixes uses a native method. > > dl > >> dl >> >>> Cheers, >>> David >>> >>>> >>>> dl >>>> >>>>> David >>>>> ----- >>>>> >>>>> ? However, getContext needs to be able to find >>>>>> the object using a stack walk, so we need a way to tell the >>>>>> compiler that it does indeed escape. To do this we pass the value >>>>>> to a native method that does nothing. >>>>>> >>>>>> Microbenchmark results: >>>>>> >>>>>> jdk12-b18: >>>>>> >>>>>> Benchmark??????????????? Mode? Cnt??? Score?? Error Units >>>>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446 ns/op >>>>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975 ns/op >>>>>> >>>>>> >>>>>> jdk12-b19: >>>>>> >>>>>> Benchmark??????????????? Mode? Cnt? Score??? Error Units >>>>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001 ns/op >>>>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001 ns/op >>>>>> >>>>>> this fix: >>>>>> >>>>>> Benchmark??????????????? Mode? Cnt? Score??? Error Units >>>>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001 ns/op >>>>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025 ns/op >>>>>> >>>>>> >>>>>> dl >>>> >> > From dean.long at oracle.com Tue Dec 18 20:53:26 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Dec 2018 12:53:26 -0800 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <07b1b4f0-f051-dd92-d107-8e9ad575211b@oracle.com> <790736fc-836c-d116-28c2-ffdc02c1e2ca@oracle.com> Message-ID: <7eb43d6e-7c16-1565-4ae1-cb16957d9382@oracle.com> Claes, can I list you as a reviewer? dl On 12/16/18 9:52 PM, Claes Redestad wrote: > Fair enough, I wasn't aware EA was looking beyond the inlined code like > this (which means it can't be "dead" or the JIT might see through the > trick at some point). I've skimmed the existing usages in the JDK and > can't find anything that seems to be dependent on DontInline defeating > EA - maybe there was in the past, or I simply misremembered. > > Either way, it might be nice to have a more explicit facility for this > in a future release, as David suggested. Say an @Escaping local > variable/parameter annotation. > > /Claes > > On 2018-12-17 05:45, dean.long at oracle.com wrote: >> Unfortunately, I don't think @DontInline on an empty method is >> sufficient >> here.? If other code is relying on @DontInline for the same purpose then >> we might need to reexamine that code.? My understanding from discussing >> with other compiler engineers is that using a native method is the >> safest >> technique that the compilers can't see through.? The problem with >> @DontInline is that C2 looks at the bytecodes of the target method, even >> if it isn't inlined (see BCEscapeAnalyzer and the EstimateArgEscape >> flag). >> There may be a way to make it work, but that would require more >> investigation, and I'm not sure the benefit outweighs the risk. >> >> dl >> >> On 12/15/18 6:48 AM, Claes Redestad wrote: >>> Hi Dean, >>> >>> to avoid escape analysis-eliminated allocations in the past @DontInline >>> has been sufficient. This means a simpler patch (no changes to native >>> code needed - added assertions notwithstanding) and passes your tests >>> with C2 (it'd concern me if Graal's EA sees through this trick, as it >>> might break some existing places where DontInline is used to this >>> effect): >>> >>> ??? /** >>> ???? * The value needs to be physically located in the frame, so >>> that it >>> ???? * can be found by a stack walk. >>> ???? */ >>> ??? @Hidden >>> ??? @DontInline >>> ??? private static void ensureMaterializedForStackWalk(Object o) {} >>> >>> Thanks! >>> >>> /Claes >>> >>> On 2018-12-15 01:59, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>> >>>> This change includes two new regression test that demonstrate the >>>> problem, and a fix that allows the tests >>>> to pass. >>>> >>>> The problem happens when the JIT compiler's escape analysis >>>> eliminates the allocation of the AccessControlContext object passed >>>> to doPrivileged.? The compiler thinks this is safe because it does >>>> not see that the object "escapes".? However, getContext needs to be >>>> able to find the object using a stack walk, so we need a way to >>>> tell the compiler that it does indeed escape.? To do this we pass >>>> the value to a native method that does nothing. >>>> >>>> Microbenchmark results: >>>> >>>> jdk12-b18: >>>> >>>> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975? ns/op >>>> >>>> >>>> jdk12-b19: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001? ns/op >>>> >>>> this fix: >>>> >>>> Benchmark??????????????? Mode? Cnt? Score??? Error? Units >>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001? ns/op >>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025? ns/op >>>> >>>> >>>> dl >> From david.holmes at oracle.com Tue Dec 18 22:19:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2018 08:19:42 +1000 Subject: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605 In-Reply-To: References: <83fe9df6-14eb-1d3a-1f70-120e95f08024@oracle.com> <741dfaed-dc81-eb0e-1f9d-d266bc46866e@oracle.com> <61f4a254-be9d-b0b2-3525-8caa247d9556@oracle.com> <3de758a3-e990-384a-5267-265bda302cbc@oracle.com> Message-ID: <879b2fc6-1126-c615-3778-af1e1d6c634c@oracle.com> On 19/12/2018 6:52 am, dean.long at oracle.com wrote: > David, can I list you as a reviewer? No, sorry, I only commented on the general issue. David > dl > > On 12/16/18 8:47 PM, dean.long at oracle.com wrote: >> On 12/16/18 7:39 PM, dean.long at oracle.com wrote: >>> On 12/16/18 7:03 PM, David Holmes wrote: >>>> On 17/12/2018 12:49 pm, dean.long at oracle.com wrote: >>>>> On 12/16/18 4:06 PM, David Holmes wrote: >>>>>> On 15/12/2018 10:59 am, dean.long at oracle.com wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214583 >>>>>>> http://cr.openjdk.java.net/~dlong/8214583/webrev >>>>>>> >>>>>>> This change includes two new regression test that demonstrate the >>>>>>> problem, and a fix that allows the tests >>>>>>> to pass. >>>>>>> >>>>>>> The problem happens when the JIT compiler's escape analysis >>>>>>> eliminates the allocation of the AccessControlContext object >>>>>>> passed to doPrivileged.? The compiler thinks this is safe because >>>>>>> it does not see that the object "escapes". >>>>>> >>>>>> Then surely the compiler's notion of "escapes" needs to be updated! >>>>>> >>>>> >>>>> The compiler can inline the callee method and see that the value >>>>> doesn't escape.? This is a valid optimization in cases where the >>>>> callee method is known. >>>> >>>> But it's not a valid optimization in this case, so my comment stands. >>>> >>>> Is this stack walking something this is guaranteed by the spec to be >>>> always valid (and hence the JIT is violating the rules), or is the >>>> stack walking code making assumptions about whether it will find the >>>> context object in the stack? >>>> >>> >>> The stack walking is in the VM and is an internal implementation >>> detail, not part of the AccessController API spec.? A different >>> thread running normal Java code would never be able to see a >>> non-escaping value.? The stack walking code does need to find the >>> context object in the stack.? Non-escaping objects won't show up in >>> the stack. >>> >>>> If we have to hack around this with an annotation I'd rather see a >>>> specific annotation that addresses the problematic usecase than a >>>> generic "don't inline" one. E.g. @StackVisible or something like that. >>>> >>> >>> That sounds like a good idea for 13, but would require changes to >>> both C2 and Graal, and it seems a little risky compared to using >>> existing mechanisms. >>> >> >> I forgot to address this in my last reply, but I'm not suggesting a >> @DontInline annotation.? That was Claes.? My fixes uses a native method. >> >> dl >> >>> dl >>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> dl >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> ? However, getContext needs to be able to find >>>>>>> the object using a stack walk, so we need a way to tell the >>>>>>> compiler that it does indeed escape. To do this we pass the value >>>>>>> to a native method that does nothing. >>>>>>> >>>>>>> Microbenchmark results: >>>>>>> >>>>>>> jdk12-b18: >>>>>>> >>>>>>> Benchmark??????????????? Mode? Cnt??? Score?? Error Units >>>>>>> DoPrivileged.test??????? avgt?? 25? 255.626 ? 6.446 ns/op >>>>>>> DoPrivileged.testInline? avgt?? 25? 250.968 ? 4.975 ns/op >>>>>>> >>>>>>> >>>>>>> jdk12-b19: >>>>>>> >>>>>>> Benchmark??????????????? Mode? Cnt? Score??? Error Units >>>>>>> DoPrivileged.test??????? avgt?? 25? 5.689 ?? 0.001 ns/op >>>>>>> DoPrivileged.testInline? avgt?? 25? 2.765 ?? 0.001 ns/op >>>>>>> >>>>>>> this fix: >>>>>>> >>>>>>> Benchmark??????????????? Mode? Cnt? Score??? Error Units >>>>>>> DoPrivileged.test??????? avgt?? 25? 5.020 ?? 0.001 ns/op >>>>>>> DoPrivileged.testInline? avgt?? 25? 2.774 ?? 0.025 ns/op >>>>>>> >>>>>>> >>>>>>> dl >>>>> >>> >> > From valerie.peng at oracle.com Tue Dec 18 23:24:16 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Dec 2018 15:24:16 -0800 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: <52A908E8-07C9-468D-990E-E2C4CD5144E0@oracle.com> References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> <52A908E8-07C9-468D-990E-E2C4CD5144E0@oracle.com> Message-ID: Thanks Sean and Max for the review. I have updated the webrev with Max's comment regarding line 87 and 100. http://cr.openjdk.java.net/~valeriep/8214096/webrev.01/ Will proceed with integration once the mach5 job is done. As for calling setParameter(...) with null value, people may have different opinions on how it should behave and what it means. Personally, I am not too sure what is the expected behavior regarding to parameters when key and parameters are passed in separate methods. We should think it through before we update the javadoc. As Sean said, too late for this bug fix at this stage. We can track this in a separate bug? Valerie On 12/18/2018 5:22 AM, Weijun Wang wrote: > >> On Dec 18, 2018, at 9:14 PM, Sean Mullan wrote: >> >> On 12/17/18 10:14 PM, Weijun Wang wrote: >>> Hi Valerie, >>> Please put lines 87 and 100 into the if-not-null block. Otherwise fine. >>> Do you think we can enhance the Signature::setParameter method and claim a null parameter is not meaningful at all and should not have any effect on the internal state of the signature object? Otherwise an application really has no idea whether to call it. >> That would be a specification change, so it can't be as part of this fix, since it is past RDP. > I understand. > >> It is also has a somewhat high compatibility risk, since it would require existing 3rd-party providers (such as BouncyCastle) that throw NPE to change their implementation. > Even if we do not specify that a certain exception must be thrown when null is used, we need to make sure setParameter(null) is completely useless, which means an implementation shall not use it to do any meaningful thing to set (or reset, or reinitialize) anything. The following codes must be equivalent to no-op: > > try { > sig.setParameter(null); > } catch (Exception e) { > // > } > > Thanks, > Max > >> It is unfortunate that the behavior of a null parameter was never clearly defined. >> >> --Sean >> >>> Thanks, >>> Max >>>> On Dec 18, 2018, at 8:41 AM, Valerie Peng wrote: >>>> >>>> Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 >>>> >>>> Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ >>>> >>>> Regards, >>>> Valerie >>>> >>>> From weijun.wang at oracle.com Wed Dec 19 00:54:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 19 Dec 2018 08:54:56 +0800 Subject: RFR[12] JDK-8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails In-Reply-To: References: <2841874a-3eea-cf97-ea80-6f572e795df4@oracle.com> <3B8422BE-FC40-4B45-8BF5-CE925192EB76@oracle.com> <52A908E8-07C9-468D-990E-E2C4CD5144E0@oracle.com> Message-ID: > On Dec 19, 2018, at 7:24 AM, Valerie Peng wrote: > > Thanks Sean and Max for the review. > > I have updated the webrev with Max's comment regarding line 87 and 100. > > http://cr.openjdk.java.net/~valeriep/8214096/webrev.01/ Looks fine to me. > > Will proceed with integration once the mach5 job is done. > > As for calling setParameter(...) with null value, people may have different opinions on how it should behave and what it means. Personally, I am not too sure what is the expected behavior regarding to parameters when key and parameters are passed in separate methods. We should think it through before we update the javadoc. As Sean said, too late for this bug fix at this stage. We can track this in a separate bug? Sure. Thanks, Max > > Valerie > > On 12/18/2018 5:22 AM, Weijun Wang wrote: >> >>> On Dec 18, 2018, at 9:14 PM, Sean Mullan wrote: >>> >>> On 12/17/18 10:14 PM, Weijun Wang wrote: >>>> Hi Valerie, >>>> Please put lines 87 and 100 into the if-not-null block. Otherwise fine. >>>> Do you think we can enhance the Signature::setParameter method and claim a null parameter is not meaningful at all and should not have any effect on the internal state of the signature object? Otherwise an application really has no idea whether to call it. >>> That would be a specification change, so it can't be as part of this fix, since it is past RDP. >> I understand. >> >>> It is also has a somewhat high compatibility risk, since it would require existing 3rd-party providers (such as BouncyCastle) that throw NPE to change their implementation. >> Even if we do not specify that a certain exception must be thrown when null is used, we need to make sure setParameter(null) is completely useless, which means an implementation shall not use it to do any meaningful thing to set (or reset, or reinitialize) anything. The following codes must be equivalent to no-op: >> >> try { >> sig.setParameter(null); >> } catch (Exception e) { >> // >> } >> >> Thanks, >> Max >> >>> It is unfortunate that the behavior of a null parameter was never clearly defined. >>> >>> --Sean >>> >>>> Thanks, >>>> Max >>>>> On Dec 18, 2018, at 8:41 AM, Valerie Peng wrote: >>>>> >>>>> Any one has time to review this straightforward fix? Details on cause and fix is elaborated in the link below: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214096 >>>>> >>>>> Webrev can be found at http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/ >>>>> >>>>> Regards, >>>>> Valerie >>>>> >>>>> From david.holmes at oracle.com Wed Dec 19 06:20:49 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2018 16:20:49 +1000 Subject: RFR: [XS] 8215411: some GetByteArrayElements calls miss corresponding Release In-Reply-To: References: <164fa449-28f6-e61b-5a6d-d3182a4c7e32@oracle.com> <7c2f5dc2-9bbe-29f9-8be0-2613267f60dc@oracle.com> Message-ID: <0e0a64cf-0047-417e-f0f6-351e60e3704e@oracle.com> On 19/12/2018 3:19 am, Baesken, Matthias wrote: > Hello, here is an updated webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.1/ > > sawindbg.cpp has been adjusted . > The exception cases mentioned now also call env->ReleaseByteArrayElements . Looks good - thanks. One minor style nit: 725 if(env->ExceptionOccurred()) { Please add a space after "if" (yes I see the macros have this wrong too). No need for updated webrev. Thanks, David > Best regards, Matthias > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 18. Dezember 2018 10:04 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' ; serviceability- >> dev at openjdk.java.net; security-dev at openjdk.java.net; JC Beyler >> >> Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss >> corresponding Release >> >> Hi Matthias, >> >> On 18/12/2018 6:52 pm, Baesken, Matthias wrote: >>> Hi JC / David, thanks for the input . >>> >>> I'm not really sure what you want me to change David, am I right that I can >> keep the changes to >>> >>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m >>> src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c >> >> Yes. >> >>> but adjust >>> >>> src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp >>> >>> to also handle theis potential early return >>> >>> 723 IDebugDataSpaces* ptrIDebugDataSpaces = (IDebugDataSpaces*) >> env->GetLongField(obj, >>> 724 ptrIDebugDataSpaces_ID); >>> 725 CHECK_EXCEPTION_(0); >>> >>> ? >> >> And I think: >> >> 730 THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: ReadVirtual >> failed!", 0); >> >> as I assume that won't actually return normally. >> >>>>> Also you change seem wrong to me because it will commit the changes >> in >>>>> the buffer even if we "abort" here: >>>>> >>>>> 735 if (bytesRead != numBytes) { >>>>> 736 return 0; >>>>> 737 } >>>>> >>> >>> The spec says : >>> >>> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function >> s.html >>> >>>> ReleaseArrayElements Routines >>>> void ReleaseArrayElements(JNIEnv *env, ArrayType >> array, NativeType *elems, jint mode); >>>> >>>> A family of functions that informs the VM that the native code no longer >> needs access to elems. The elems argument is a pointer derived from array >> using the corresponding >>>> GetArrayElements() function. If necessary, this function >> copies back all changes made to elems to the original array. >>> >>> So shouldn't I tell the VM , that the native code no longer needs access to >> bytePtr before returning here >>> >>> 735 if (bytesRead != numBytes) { >>> 736 return 0; >>> 737 } >>> >>> ? >> >> There are two aspects to release: >> 1. the actual release (or "I don't need this any more") >> 2. committing any changes made back to the original array >> >> This code does: >> >> 728 if (ptrIDebugDataSpaces->ReadVirtual((ULONG64) address, (PVOID) >> bytePtr, >> 729 (ULONG)numBytes, &bytesRead) != >> S_OK) { >> >> which writes into the array. It then checks if we wrote what we expected: >> >> 735 if (bytesRead != numBytes) { >> 736 return 0; >> 737 } >> >> If we didn't read what was expected what should happen to the original >> array? Should it be left untouched or updated with the unexpected input? >> I would say left untouched and that is what the original code did. >> >> If everything succeeds you should do the release with mode 0; but if >> taking an error exit the release should use mode JNI_ABORT so no changes >> are written back. >> >> Cheers, >> David >> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 18. Dezember 2018 01:20 >>>> To: Baesken, Matthias ; 'hotspot- >>>> dev at openjdk.java.net' ; serviceability- >>>> dev at openjdk.java.net; security-dev at openjdk.java.net >>>> Subject: Re: RFR: [XS] 8215411: some GetByteArrayElements calls miss >>>> corresponding Release >>>> >>>> Correction ... >>>> >>>> On 18/12/2018 8:25 am, David Holmes wrote: >>>>> Hi Matthias, >>>>> >>>>> On 17/12/2018 6:59 pm, Baesken, Matthias wrote: >>>>>> Hello, please review the following change. >>>>>> I noticed that we miss at some places (for example in case of early >>>>>> returns) >>>>>> where GetByteArrayElements is used,? the corresponding >>>>>> ReleaseByteArrayElements? call. >>>>>> >>>>>> In VirtualMachineImpl.c? I also removed a check for isCopy (is the >>>>>> returned byte array a copy ?) >>>>>> because from what I read at >>>>>> >>>>>> >>>> >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/function >>>> s.html >>>>>> >>>>>> >>>>>> the ReleaseByteArrayElements? routine should always be called. >>>>> >>>>> That's not clear to me. My reading is that you only need to release if >>>>> you have changes you need to ensure are written back and that is only >>>>> needed if a copy was made. >>>> >>>> Jc pointed out to me that if a copy is made you may need to release to >>>> avoid a memory leak. But that is where the mode flags come in - and >>>> again only relevant if a copy was made. >>>> >>>> But as per: >>>> >>>> https://developer.android.com/training/articles/perf-jni >>>> >>>> if a copy is not made and pinning is used (as with the "critical" >>>> variants) then you also need to release to un-pin. >>>> >>>> So code should call release, with an appropriate mode, based on whether >>>> isCopy was true**, and whether changed data should be written back. >>>> >>>> ** mode is ignored if not working on a copy so you can just set it >>>> assuming a copy was made. >>>> >>>> Note that the hotspot implementation always makes a copy for >>>> GextXXXArrayElements, and the ReleaseXXXArrayElements knows this >> and >>>> so >>>> will always free the buffer that is passed in (other than for mode >>>> JNI_COMMIT of course). >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> That said, the change seem semantically correct and harmless in this >> case. >>>>> --- >>>>> >>>>> src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp >>>>> >>>>> AFAICS there are still multiple exit paths via CHECK_EXCEPTION_(0) and >>>>> THROW_NEW_DEBUGGER_EXCEPTION_ that won't release the buffer. >>>>> >>>>> Also you change seem wrong to me because it will commit the changes >> in >>>>> the buffer even if we "abort" here: >>>>> >>>>> 735?? if (bytesRead != numBytes) { >>>>> ?736????? return 0; >>>>> ?737?? } >>>>> >>>>> so it seems to me if you really want to release on all paths then the >>>>> error paths should use a mode of JNI_ABORT and only the success path >>>>> should use mode 0. >>>>> >>>>> --- >>>>> >>>>> ?src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m >>>>> >>>>> This change seems okay, though again potentially not necessary - as we >>>>> never commit any changes. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> bug/webrev : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8215411 >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215411.0/ >>>>>> >>>>>> >>>>>> Thanks, Matthias >>>>>> From goetz.lindenmaier at sap.com Wed Dec 19 10:28:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 19 Dec 2018 10:28:19 +0000 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java In-Reply-To: References: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com> Message-ID: Hi, the amount of tests failing is increasing: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java or did I miss a fix for ActalisCA? ByupassCA.java says "Certificate has been revoked, reason: UNSPECIFIED, revocation date: Mon Dec 17" We would appreciate a fix in jdk 11, 12 and jdk/jdk. Maybe similar to "8207059: Update test certificates in QuoVadisCA.java test"? And maybe you can check whether other tests need updates in the very near future, too? E.g., before the jdk12 release date? Best regards, Goetz. > -----Original Message----- > From: Sean Mullan > Sent: Dienstag, 27. November 2018 13:48 > To: Baesken, Matthias ; security- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Sibabrata Sahoo > > Subject: Re: jdk11u and jdk/jdk : jtreg test error in > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > > On 11/27/18 7:36 AM, Baesken, Matthias wrote: > > Hi Sean , maybe I was not clear enough - when I said " but we only see > the issue since last week" I meant we started to see the issue in our local > jtreg test runs > > for jdk11u and for jdk/jdk . > > Oh, I see. I have not looked at this issue myself. Maybe Siba (the RE) > can offer some suggestions. > > > > > Do you think > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va should be set on the exclude list for now (until JDK-8202651 is resolved) > ? > > Sure, if Siba does not have any plans to fix this soon. > > --Sean > > > > > > > Best regards, Matthias > > > >> -----Original Message----- > >> From: Sean Mullan > >> Sent: Montag, 26. November 2018 15:57 > >> To: Baesken, Matthias ; security- > >> dev at openjdk.java.net > >> Cc: Lindenmaier, Goetz > >> Subject: Re: jdk11u and jdk/jdk : jtreg test error in > >> > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > >> va > >> > >> On 11/26/18 8:44 AM, Baesken, Matthias wrote: > >>> Hi Sean thanks for the info . > >>> > >>> Strange that the bug https://bugs.openjdk.java.net/browse/JDK- > 8202651 > >> is from May , but we only see the issue since last week ?! > >> > >> It was marked Confidential for some reason, possibly by accident because > >> these tests used to be closed before we open sourced them in JDK 10. I > >> opened up the bug today. > >> > >> --Sean From sean.coffey at oracle.com Wed Dec 19 11:47:08 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 19 Dec 2018 11:47:08 +0000 Subject: RFR: 8214532,Update RFC 2459 references in javadoc to RFC 5280 Message-ID: <4d516e81-da38-d6ce-93ae-abbd62e6b325@oracle.com> Some doc edits to update RFC 2459 to 5280. I've updated the relevant section numbers where necessary. No edits to Java SE specification docs. I've taken the opportunity to put a space in some "RFCxxxx" references also as it seems to be preferred approach. I've removed a paragraph in src/java.base/share/classes/sun/security/x509/X509CertImpl.java also which seemed obsolete. I'd like to push this doc edit to JDK 12. http://cr.openjdk.java.net/~coffeys/webrev.8214532/webrev/ -- Regards, Sean. From sean.mullan at oracle.com Wed Dec 19 14:21:08 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Dec 2018 09:21:08 -0500 Subject: RFR: 8214532,Update RFC 2459 references in javadoc to RFC 5280 In-Reply-To: <4d516e81-da38-d6ce-93ae-abbd62e6b325@oracle.com> References: <4d516e81-da38-d6ce-93ae-abbd62e6b325@oracle.com> Message-ID: <9480860e-0a19-a2c1-cd3d-a315f37c43f4@oracle.com> Just a couple of minor comments: * DNSName 184 * draft-ietf-pkix-new-part1-00.txt: DNSName restrictions are expressed as foo.bar.com. Change "draft-ietf-pkix-new-part1-00.txt" to RFC 5280. * X509CertImpl 67 * * can be referenced in RFC 5280. remove extra '*'. --Sean On 12/19/18 6:47 AM, Se?n Coffey wrote: > Some doc edits to update RFC 2459 to 5280. I've updated the relevant > section numbers where necessary. > > No edits to Java SE specification docs. I've taken the opportunity to > put a space in some "RFCxxxx" references also as it seems to be > preferred approach. I've removed a paragraph in > src/java.base/share/classes/sun/security/x509/X509CertImpl.java also > which seemed obsolete. > > I'd like to push this doc edit to JDK 12. > > http://cr.openjdk.java.net/~coffeys/webrev.8214532/webrev/ > From sean.coffey at oracle.com Wed Dec 19 18:18:34 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 19 Dec 2018 18:18:34 +0000 Subject: RFR: 8214532,Update RFC 2459 references in javadoc to RFC 5280 In-Reply-To: <9480860e-0a19-a2c1-cd3d-a315f37c43f4@oracle.com> References: <4d516e81-da38-d6ce-93ae-abbd62e6b325@oracle.com> <9480860e-0a19-a2c1-cd3d-a315f37c43f4@oracle.com> Message-ID: <41903da0-913c-ce74-76f6-73354ed65d66@oracle.com> Thanks Sean. I've made those edits and pushed to JDK 12 repo. Regards, Sean. On 19/12/18 14:21, Sean Mullan wrote: > Just a couple of minor comments: > > * DNSName > > 184 * draft-ietf-pkix-new-part1-00.txt: DNSName restrictions are > expressed as foo.bar.com. > > Change "draft-ietf-pkix-new-part1-00.txt" to RFC 5280. > > * X509CertImpl > > 67 * * can be referenced in RFC 5280. > > remove extra '*'. > > --Sean > > On 12/19/18 6:47 AM, Se?n Coffey wrote: >> Some doc edits to update RFC 2459 to 5280. I've updated the relevant >> section numbers where necessary. >> >> No edits to Java SE specification docs. I've taken the opportunity to >> put a space in some "RFCxxxx" references also as it seems to be >> preferred approach. I've removed a paragraph in >> src/java.base/share/classes/sun/security/x509/X509CertImpl.java also >> which seemed obsolete. >> >> I'd like to push this doc edit to JDK 12. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8214532/webrev/ >> From adam.petcher at oracle.com Wed Dec 19 18:43:20 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 19 Dec 2018 13:43:20 -0500 Subject: RFR 8215643: Microbenchmarks for KeyAgreement and Cipher Message-ID: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> Webrev: http://cr.openjdk.java.net/~apetcher/8215643/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8215643 Please review this enhancement that adds two new crypto microbenchmarks. See the JBS ticket for the motivation behind these new benchmarks. The Cipher benchmark nearly duplicates some existing AES benchmarks, though the measurement is done differently in order to also address JDK-8214800[1]. I didn't want to upset anything by removing the existing AES benchmarks, but I'm interested in advice on how we should handle this duplication. [1] https://bugs.openjdk.java.net/browse/JDK-8214800 From valerie.peng at oracle.com Wed Dec 19 19:51:39 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Dec 2018 11:51:39 -0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <4cf4a509-d155-e64c-dbb1-60b054c1c079@oracle.com> Hi Max, Here are more comments/questions on : I am a bit unclear on the handling of the gss qop and MS qop. There are a few places where you seem to treat them as the same thing. But there are also cases where they seem unrelated as you didn't set one using the other and vice versa. For all new/malloc calls, check for null return value before proceeding further. For gss APIs whose arguments are marked const, can we also do that here? I think it's clearer and helps code readability. Below are function-specific comments. - SecondsUntil: naming seems inconsistent, should start with lower case? Based on the MS doc that I found https://msdn.microsoft.com/en-us/library/ms724284(v=VS.85).aspx, TimeStamp is same as FILETIME which you then copy the two fields into a ULARGE_INTEGER to do the 64-bit arithmetic, but through out the code, you seems to treat ULARGE_INTEGER and FILETIME as interchangeable and directly access the QuadPart field. MS doc has "Do not cast a pointer to a *FILETIME* structure to either a *ULARGE_INTEGER** or *__int64** value because it can cause alignment faults on 64-bit Windows." In addition, the comment about AcquireCredentialsHandle may be incomplete, as gss_context_time also uses this method. -1 is returned if the FileTimeToLocalFileTime() call failed. Also it seems that this method assumes that the passed-in "time" is always beyond the current time (line 291 - 296) which may not always be true? - gss_context_time: Shouldn't this method also check the tsExpiry value and return the |GSS_S_CONTEXT_EXPIRED error code if applicable? Also the time_rec should be 0 if context has already expired. | - gss_wrap_size_limit:? based on the MS doc example: https://docs.microsoft.com/en-us/windows/desktop/secauthn/encrypting-a-message, |it looks like the value is "cbMaximumMessage" of||SecPkgContext_StreamSizes. Where is the documentation for the||| context_handle and its cbMaxMessage field? || - gss_get_mic: Some places you use SEC _SUCCESS macro and some plain if-else block. What is the criteria? In the SEC_SUCCESS macro, it's clearer to use SEC_E_OK instead of 0? Are we sure that the context handle already has the cbMaxSignature value? I saw that you make this call inside gss_init_sec_context() when the context is established. But do we need to handle the case that a half-established context is passed in? Should not crash even if user does that, right? - gss_verify_mic: qop_state is optional and may be null. You should check the value before dereferencing it. Line 1262, should be SECBUFFER_VERSION instead of 0?|Should we also check qop_state? | - gss_wrap: Line 1347, since the order of data is 0-1-2, why the length addition is ordered 1-0-2? Seems more natural to use the same order. Move the assignment of conf_state (line 1329) after the if-block (line 1331). In addition, conf_state is optional and may be null. You should check the value before dereferencing it. |Will continue reviewing the rest.| |Thanks,| |Valerie| | | || On 12/12/2018 2:20 PM, Valerie Peng wrote: > > Hi Max, > > > > - the DER related code is very hard to read... Would be nice to use > constants/enum for commonly used tag or use some method to construct them. > > - line 449, I think you mean to use "c" instead of "cred_handle" > > - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable > naming convention starts with lower case? the argument qop_state may > be non-null but is not set?|| > > - gss_indicate_mechs: the SSPI docs that I found mentioned that you > need to call FreeContextBuffer on pkgInfo after calling > QuerySecurityPackageInfo(). Local variable "minor" not used and can be > removed? > > - gss_inquire_names_for_mech: why does the PP output has "IMPLEMENTED" > wording, other methods do not. Is this intentional? > > - gss_create_empty_oid_set: do we need to check the specified oid_set > for existing content and free if not-empty before wiping it out? This > is called by a few other gss api methods also, it may be better to > defend against user errors. > > - gss_add_oid_set_member: add "const" to the 2nd argument? > > - gss_release_buffer: maybe set buffer->length = 0 outside the > if-block. Do we need to check for GSS_C_NO_BUFFER in addition to null? > > - gss_display_status: add "const" to the 4th argument? As for the > impl, I have a question, this particular method is for displaying text > output for gssapi error codes, but the FormatMessage() call takes > window specific message id. Are they the same? > > I am still going through the rest of sspi.cpp, but thought that I will > send you what I have first. > > Good that you have this targeted to 13 as there is almost no time left > for RFEs to get into JDK12. > > Thanks, > Valerie > > > On 11/19/2018 5:56 PM, Weijun Wang wrote: >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ >> >> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. >> >> No regression tests included. A Windows Active Directory server is needed. >> >> Thanks >> Max >> >> [1]https://bugs.openjdk.java.net/browse/JDK-8200468 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Wed Dec 19 20:31:03 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 19 Dec 2018 20:31:03 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <20181219203103.GK22527@twosigma.com> On Wed, Dec 12, 2018 at 02:20:24PM -0800, Valerie Peng wrote: > - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable > naming convention starts with lower case? the argument qop_state may be > non-null but is not set?|| Nowadays we have gss_const_* types. You have to use those because otherwise const won't be doing what you think when you pass typedef'ed pointers. See RFC 5587. You need to add the following typedefs to src/java.security.jgss/share/native/libj2gss/gssapi.h: typedef const gss_buffer_desc *gss_const_buffer_t; typedef const struct gss_channel_bindings_struct *gss_const_channel_bindings_t; typedef const struct gss_ctx_id_struct *gss_const_ctx_id_t; typedef const struct gss_cred_id_struct *gss_const_cred_id_t; typedef const struct gss_name_struct *gss_const_name_t; typedef const gss_OID_desc *gss_const_OID; typedef const gss_OID_set_desc *gss_const_OID_set; > - gss_add_oid_set_member: add "const" to the 2nd argument? > - gss_display_status: add "const" to the 4th argument? As for the impl, I > have a question, this particular method is for displaying text output for > gssapi error codes, but the FormatMessage() call takes window specific > message id. Are they the same? See above. Nico -- From jamil.j.nimeh at oracle.com Wed Dec 19 21:49:48 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 19 Dec 2018 13:49:48 -0800 Subject: RFR 8215643: Microbenchmarks for KeyAgreement and Cipher In-Reply-To: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> References: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> Message-ID: <950010e0-17fc-0b5b-aafc-e902703ac499@oracle.com> Hi Adam.? On the whole the benchmarks look good to me.? Can I ask why those ciphers and key agreement schemes that support multiple key lengths aren't called out in the @Param annotations?? I'm thinking 192 and 256 bit for AES and maybe 1024 and 3072 and/or 4096 for DH.? Do we not need numbers across various key lengths with these microbenchmarks? --Jamil On 12/19/2018 10:43 AM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8215643/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8215643 > > Please review this enhancement that adds two new crypto > microbenchmarks. See the JBS ticket for the motivation behind these > new benchmarks. The Cipher benchmark nearly duplicates some existing > AES benchmarks, though the measurement is done differently in order to > also address JDK-8214800[1]. I didn't want to upset anything by > removing the existing AES benchmarks, but I'm interested in advice on > how we should handle this duplication. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214800 > From ivan.gerasimov at oracle.com Wed Dec 19 22:44:13 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Dec 2018 14:44:13 -0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <3976d319-8ad1-ffb3-8bdb-314a46607ded@oracle.com> Hi Max! In sspi.cpp native memory is allocated via `new` or `new []`, and sometimes the returned pointer is checked for NULL. If `new` fails, it will throw the `std:: bad_alloc` exception, so I believe you should use `new (std::nothrow)` and `new (std::nothrow) []` instead. With kind regards, Ivan On 11/19/18 5:56 PM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ > > We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. > > No regression tests included. A Windows Active Directory server is needed. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8200468 -- With kind regards, Ivan Gerasimov From valerie.peng at oracle.com Wed Dec 19 22:53:23 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Dec 2018 14:53:23 -0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181219203103.GK22527@twosigma.com> References: <20181219203103.GK22527@twosigma.com> Message-ID: Sure, those typedefs makes sense. Thanks, Valerie On 12/19/2018 12:31 PM, Nico Williams wrote: > On Wed, Dec 12, 2018 at 02:20:24PM -0800, Valerie Peng wrote: >> - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable >> naming convention starts with lower case? the argument qop_state may be >> non-null but is not set?|| > Nowadays we have gss_const_* types. You have to use those because > otherwise const won't be doing what you think when you pass typedef'ed > pointers. See RFC 5587. You need to add the following typedefs to > src/java.security.jgss/share/native/libj2gss/gssapi.h: > > typedef const gss_buffer_desc *gss_const_buffer_t; > typedef const struct gss_channel_bindings_struct *gss_const_channel_bindings_t; > typedef const struct gss_ctx_id_struct *gss_const_ctx_id_t; > typedef const struct gss_cred_id_struct *gss_const_cred_id_t; > typedef const struct gss_name_struct *gss_const_name_t; > typedef const gss_OID_desc *gss_const_OID; > typedef const gss_OID_set_desc *gss_const_OID_set; > >> - gss_add_oid_set_member: add "const" to the 2nd argument? >> - gss_display_status: add "const" to the 4th argument? As for the impl, I >> have a question, this particular method is for displaying text output for >> gssapi error codes, but the FormatMessage() call takes window specific >> message id. Are they the same? > See above. > > Nico From rajan.halade at oracle.com Thu Dec 20 04:50:00 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 19 Dec 2018 20:50:00 -0800 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java In-Reply-To: References: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com> Message-ID: <533f6f53-2533-d203-737a-23875ceb1b6d@oracle.com> I will address these after this winter break or during if I get time. Thanks, Rajan On 12/19/18 2:28 AM, Lindenmaier, Goetz wrote: > Hi, > > the amount of tests failing is increasing: > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java > security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java > or did I miss a fix for ActalisCA? > > ByupassCA.java says "Certificate has been revoked, reason: UNSPECIFIED, revocation date: Mon Dec 17" > > We would appreciate a fix in jdk 11, 12 and jdk/jdk. > > Maybe similar to "8207059: Update test certificates in QuoVadisCA.java test"? > > And maybe you can check whether other tests need updates in the very near future, too? > E.g., before the jdk12 release date? > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: Sean Mullan >> Sent: Dienstag, 27. November 2018 13:48 >> To: Baesken, Matthias ; security- >> dev at openjdk.java.net >> Cc: Lindenmaier, Goetz ; Sibabrata Sahoo >> >> Subject: Re: jdk11u and jdk/jdk : jtreg test error in >> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja >> va >> >> On 11/27/18 7:36 AM, Baesken, Matthias wrote: >>> Hi Sean , maybe I was not clear enough - when I said " but we only see >> the issue since last week" I meant we started to see the issue in our local >> jtreg test runs >>> for jdk11u and for jdk/jdk . >> Oh, I see. I have not looked at this issue myself. Maybe Siba (the RE) >> can offer some suggestions. >> >>> Do you think >> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja >> va should be set on the exclude list for now (until JDK-8202651 is resolved) >> ? >> >> Sure, if Siba does not have any plans to fix this soon. >> >> --Sean >> >>> >>> Best regards, Matthias >>> >>>> -----Original Message----- >>>> From: Sean Mullan >>>> Sent: Montag, 26. November 2018 15:57 >>>> To: Baesken, Matthias ; security- >>>> dev at openjdk.java.net >>>> Cc: Lindenmaier, Goetz >>>> Subject: Re: jdk11u and jdk/jdk : jtreg test error in >>>> >> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja >>>> va >>>> >>>> On 11/26/18 8:44 AM, Baesken, Matthias wrote: >>>>> Hi Sean thanks for the info . >>>>> >>>>> Strange that the bug https://bugs.openjdk.java.net/browse/JDK- >> 8202651 >>>> is from May , but we only see the issue since last week ?! >>>> >>>> It was marked Confidential for some reason, possibly by accident because >>>> these tests used to be closed before we open sourced them in JDK 10. I >>>> opened up the bug today. >>>> >>>> --Sean From adam.petcher at oracle.com Thu Dec 20 15:53:20 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 20 Dec 2018 10:53:20 -0500 Subject: RFR 8215643: Microbenchmarks for KeyAgreement and Cipher In-Reply-To: <950010e0-17fc-0b5b-aafc-e902703ac499@oracle.com> References: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> <950010e0-17fc-0b5b-aafc-e902703ac499@oracle.com> Message-ID: <5f37b172-9141-98d4-7600-91d522fc2b3c@oracle.com> updated webrev: http://cr.openjdk.java.net/~apetcher/8215643/webrev.01/ On 12/19/2018 4:49 PM, Jamil Nimeh wrote: > Hi Adam.? On the whole the benchmarks look good to me.? Can I ask why > those ciphers and key agreement schemes that support multiple key > lengths aren't called out in the @Param annotations?? I'm thinking 192 > and 256 bit for AES and maybe 1024 and 3072 and/or 4096 for DH.? Do we > not need numbers across various key lengths with these microbenchmarks? There probably needs to be some balance in the default parameters that are included in the test. If we include too many, then the test will take too long to run. My strategy here is to include default parameters for only the most important key sizes, and for things that we want to keep an eye on (ECDH 521 is only there because we have been tinkering with it). Including AES 256 in the defaults is probably a good idea, and I added it in the latest webrev. I think 192 is less important, because it isn't widely used. For DH, benchmarking it at all may not be really valuable, but I added it for completeness. I don't think it is worthwhile to test multiple key sizes for DH, and 1024 is too small these days. If you have any other suggestions for default key sizes, let me know. But keep in mind that we don't need to be complete, because someone running the benchmark can always do -pkeyLength=... to choose other sizes. Thanks for the review. This is my first time writing a microbenchmark, so I would like to also get a review from a JMH/microbenchmark expert before I push. From jamil.j.nimeh at oracle.com Thu Dec 20 19:03:45 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 20 Dec 2018 11:03:45 -0800 Subject: RFR 8215643: Microbenchmarks for KeyAgreement and Cipher In-Reply-To: <5f37b172-9141-98d4-7600-91d522fc2b3c@oracle.com> References: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> <950010e0-17fc-0b5b-aafc-e902703ac499@oracle.com> <5f37b172-9141-98d4-7600-91d522fc2b3c@oracle.com> Message-ID: Thanks for adding in AES/256.? I think your rationale for DH is fine, it was something that I was more curious about than concerned.? The -pkeyLength option gives the benchmarks the flexibility we need if we want to try larger or smaller keys.? I don't think we need to include other sizes by default. Getting some feedback from a JMH expert is definitely a good idea. I'll be interested to see what feedback and suggestions they have to offer, if any. Thanks, --Jamil On 12/20/2018 7:53 AM, Adam Petcher wrote: > updated webrev: http://cr.openjdk.java.net/~apetcher/8215643/webrev.01/ > > On 12/19/2018 4:49 PM, Jamil Nimeh wrote: > >> Hi Adam.? On the whole the benchmarks look good to me.? Can I ask why >> those ciphers and key agreement schemes that support multiple key >> lengths aren't called out in the @Param annotations?? I'm thinking >> 192 and 256 bit for AES and maybe 1024 and 3072 and/or 4096 for DH.? >> Do we not need numbers across various key lengths with these >> microbenchmarks? > > There probably needs to be some balance in the default parameters that > are included in the test. If we include too many, then the test will > take too long to run. My strategy here is to include default > parameters for only the most important key sizes, and for things that > we want to keep an eye on (ECDH 521 is only there because we have been > tinkering with it). Including AES 256 in the defaults is probably a > good idea, and I added it in the latest webrev. I think 192 is less > important, because it isn't widely used. For DH, benchmarking it at > all may not be really valuable, but I added it for completeness. I > don't think it is worthwhile to test multiple key sizes for DH, and > 1024 is too small these days. If you have any other suggestions for > default key sizes, let me know. But keep in mind that we don't need to > be complete, because someone running the benchmark can always do > -pkeyLength=... to choose other sizes. > > Thanks for the review. This is my first time writing a microbenchmark, > so I would like to also get a review from a JMH/microbenchmark expert > before I push. > From eric.caspole at oracle.com Thu Dec 20 22:28:32 2018 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 20 Dec 2018 17:28:32 -0500 Subject: RFR 8215643: Microbenchmarks for KeyAgreement and Cipher In-Reply-To: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> References: <1cf22fe3-3c8b-7a24-6551-5b48c728d509@oracle.com> Message-ID: Hi Adam, The iteration control annotations you are inheriting from the CryptoBase don't seem too good for the couple of your new micros I had time to try, it is too short for warmup so there is a lot of run to run variation and it will be a pain if we later run them in the weeklies. Otherwise they look fine. It's OK with me to add them now and we can fix the iteration control to stabilize them after the break. Eric On 12/19/18 13:43, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8215643/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8215643 > > Please review this enhancement that adds two new crypto microbenchmarks. > See the JBS ticket for the motivation behind these new benchmarks. The > Cipher benchmark nearly duplicates some existing AES benchmarks, though > the measurement is done differently in order to also address > JDK-8214800[1]. I didn't want to upset anything by removing the existing > AES benchmarks, but I'm interested in advice on how we should handle > this duplication. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214800 > From weijun.wang at oracle.com Fri Dec 21 01:57:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Dec 2018 09:57:05 +0800 Subject: RFR 8215769: Java cannot probe pkcs12 files exported by Firefox Message-ID: <4AB29418-89AA-4CD3-810D-A941E376BB33@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8215769/webrev.00/ It's currently P4 because I don't think many people import pkcs12 files from Firefox to Java, and even if so, one can always specify the storepass as a workaround. If you think this is more useful I can change it to P3 and push to JDK 12. This fix is safe. Thanks Max From weijun.wang at oracle.com Fri Dec 21 01:59:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Dec 2018 09:59:55 +0800 Subject: RFR 8215769: Java cannot probe pkcs12 files exported by Firefox In-Reply-To: <4AB29418-89AA-4CD3-810D-A941E376BB33@oracle.com> References: <4AB29418-89AA-4CD3-810D-A941E376BB33@oracle.com> Message-ID: An explanation of the newly added pattern: * 30 80 02 01 03 30 80 06 09 2A 86 48 86 F7 0D 01 07 01 A0 80 24 80 04 -- Every 80 starts an element of indefinite length which will be enclosed with a end-of-content tag somewhere later. The 80 24 80 04 at the end denotes an indefinite length OCTECT string which is encoded in constructed form. --Max > On Dec 21, 2018, at 9:57 AM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8215769/webrev.00/ > > It's currently P4 because I don't think many people import pkcs12 files from Firefox to Java, and even if so, one can always specify the storepass as a workaround. If you think this is more useful I can change it to P3 and push to JDK 12. This fix is safe. > > Thanks > Max > From weijun.wang at oracle.com Fri Dec 21 09:44:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Dec 2018 17:44:59 +0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates Message-ID: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ This bug reveals several issues: 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. 2. The missing of setParameter() call for PKCS10 and X509CertImpl. 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. Please confirm this is safe to be fixed in JDK 12. Thanks, Max From christoph.langer at sap.com Fri Dec 21 10:41:18 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 10:41:18 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) Message-ID: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> Hi folks, getting back to the topic of adding POSIX file permission support to jdk.zipfs... I think as we are now in the early stages of JDK13, it's a good point in time to get some (hopefully final) activity on that one. In the last review discussions you were asking me to provide some write-up of the proposal. Therefore I updated the CSR. It should now be a valid document for discussing the whole proposal, comprising the problem to solve, the proposed solution and its specification as well as addressing some concerns. And to get it clear: This item is only about jdk.zipfs. It is really independent of potential enhancements for java.util.zip or the jartool. So, I gently ask you to review the CSR. As for the implementation: I've worked on it together with Volker and will post an update soon. Thanks and Best regards Christoph > -----Original Message----- > From: Chris Hegarty > Sent: Montag, 5. November 2018 17:19 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; security-dev at openjdk.java.net; Xueming Shen > > Cc: nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > > On 05/11/18 15:59, Alan Bateman wrote: > > On 05/11/2018 13:05, Langer, Christoph wrote: > >> > >>... > >> > > I think you'll need to do a write-up of the overall proposal so that > > folks can jump in and point out the implications. It's not easy to do > > this in a code review of a small piece of the solution. > > Right, that's the main motivation for my previous questions. It is good > to get a *complete* view of what is intended before reviewing the code. > ( Sorry, if I've missed some of the previous context ). > > -Chris. From Alan.Bateman at oracle.com Fri Dec 21 11:16:44 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2018 11:16:44 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> Message-ID: <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> On 21/12/2018 10:41, Langer, Christoph wrote: > Hi folks, > > getting back to the topic of adding POSIX file permission support to jdk.zipfs... I think as we are now in the early stages of JDK13, it's a good point in time to get some (hopefully final) activity on that one. > > In the last review discussions you were asking me to provide some write-up of the proposal. > Therefore I updated the CSR. It should now be a valid document for discussing the whole proposal, comprising the problem to solve, the proposed solution and its specification as well as addressing some concerns. > > And to get it clear: This item is only about jdk.zipfs. It is really independent of potential enhancements for java.util.zip or the jartool. So, I gently ask you to review the CSR. > > As for the implementation: I've worked on it together with Volker and will post an update soon. > Adding support for POSIX file permissions to the zip APIs is problematic as we've been discussing here. There are security concerns and also concerns that how it interacts with JAR files and signed JAR in particular. I don't disagree that we can come to agreement on zipfs supporting a solution but I think we need to get the bigger picture on where this is going first. If the piece to change the java.util.zip APIs is dropped then it would make these discussions a lot simpler as it removes most of the security issues from the table. -Alan From christoph.langer at sap.com Fri Dec 21 13:43:13 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 13:43:13 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: Hi Alan, > Adding support for POSIX file permissions to the zip APIs is problematic > as we've been discussing here. There are security concerns and also > concerns that how it interacts with JAR files and signed JAR in > particular. I don't disagree that we can come to agreement on zipfs > supporting a solution but I think we need to get the bigger picture on > where this is going first. If the piece to change the java.util.zip APIs > is dropped then it would make these discussions a lot simpler as it > removes most of the security issues from the table. Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. Best regards Christoph From sean.mullan at oracle.com Fri Dec 21 13:58:27 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Dec 2018 08:58:27 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> Message-ID: <729c4213-6b2a-d847-66e3-be726cc04e1b@oracle.com> On 11/26/18 8:32 PM, Weijun Wang wrote: > Ping I made a few tweaks to the title and wording. > >> On Nov 15, 2018, at 9:24 AM, Weijun Wang wrote: >> >> >> >>> On Nov 15, 2018, at 3:53 AM, Adam Petcher wrote: >>> >>> This looks good to me, though I made a couple of trivial editorial changes. It's fine as is, but you may want to consider using secp384r1 instead of brainpool256r1 in your example. I worry that people will experiment with the new feature using your example, and then we'll get bug tickets because the resulting keystore doesn't work with TLS. >> >> This is exactly the advice I need from an expert. >> >> However, secp384r1 is already the default choice for `-keysize 384`. Do you have another recommendation that has to be set with `-groupname`? I think it is ok to use secp384r1 in the release note even though it is the default for -keysize 384. BTW, did you also file a docs issue to update the keytool docs with the new -groupname option? --Sean >> >> Thanks >> Max >> >>> >>> On 11/13/2018 7:56 PM, Weijun Wang wrote: >>>> Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821. >>>> >>>> --Max >>>> >>>>> On Nov 13, 2018, at 11:02 PM, Adam Petcher wrote: >>>>> >>>>> This change looks good to me. Thanks. >>>>> >> > From christoph.langer at sap.com Fri Dec 21 14:31:11 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Dec 2018 14:31:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi all, here comes the updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ I've rebased the change to the current state of the JDK depot. Thanks to Volker, the test has been enhanced and now also tests more copy operations (from zip file system to zip file system and from zip file system to default file system and back). The points below were also addressed: > ZipFileAttributeView.java > - can you please throw an AssertionError() for the default branch in > the switch expression in the "ZipFileAttributeView.name()". The default branch will return "basic". Looking at the code it should not be jumped to anyway. > ZipFileSystem.java > - please also put @Override annotations on the method implementations > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > a comment at the place where the implementation of the > "PosixFileAttributes" methods starts. Done, I also reordered the methods - first "basic" then "posix" then "zip". > ZipUtils.java > - just a question: isn't it possible to reuse > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > constants from sun.nio.fs.UnixConstants instead of redefining them > here? You could export them from java.base to jdk.zipfs but the > problem is probably that at least sun.nio.fs.UnixConstants is a > generated class which only gets generated on Unix systems, right ? You've already answered yourself ?? These classes only exist on Unix type JDKs. > ZipFileAttributes.java > - it seems a little odd that you've added "setPermissions()" to > ZipFileAttributes. All the attribute classes (i.e. > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > possible to implement "ZipFileAttributeView.setPermissions()" by > calling "path.setPermissions()" (as this is done in > "ZipFileAttributeView.setTimes()") and handle everything in > ZipFileSyste (as this is done with "setTimes()"). Good catch & thanks for providing the better implementation. I think this version is quite final now and thoroughly tested. I hope to get some valid reviews soon... Thanks Christoph From weijun.wang at oracle.com Fri Dec 21 14:50:04 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Dec 2018 22:50:04 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <729c4213-6b2a-d847-66e3-be726cc04e1b@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> <729c4213-6b2a-d847-66e3-be726cc04e1b@oracle.com> Message-ID: > On Dec 21, 2018, at 9:58 PM, Sean Mullan wrote: > > On 11/26/18 8:32 PM, Weijun Wang wrote: >> Ping > > I made a few tweaks to the title and wording. > >>> On Nov 15, 2018, at 9:24 AM, Weijun Wang wrote: >>> >>> >>> >>>> On Nov 15, 2018, at 3:53 AM, Adam Petcher wrote: >>>> >>>> This looks good to me, though I made a couple of trivial editorial changes. It's fine as is, but you may want to consider using secp384r1 instead of brainpool256r1 in your example. I worry that people will experiment with the new feature using your example, and then we'll get bug tickets because the resulting keystore doesn't work with TLS. >>> >>> This is exactly the advice I need from an expert. >>> >>> However, secp384r1 is already the default choice for `-keysize 384`. Do you have another recommendation that has to be set with `-groupname`? > > I think it is ok to use secp384r1 in the release note even though it is the default for -keysize 384. OK, I'll use it. And I've just added another sentence that we recommend using -groupname. > > BTW, did you also file a docs issue to update the keytool docs with the new -groupname option? > Just filed one. Thanks for reminding. --Max > --Sean > >>> >>> Thanks >>> Max >>> >>>> >>>> On 11/13/2018 7:56 PM, Weijun Wang wrote: >>>>> Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821. >>>>> >>>>> --Max >>>>> >>>>>> On Nov 13, 2018, at 11:02 PM, Adam Petcher wrote: >>>>>> >>>>>> This change looks good to me. Thanks. >>>>>> >>> From volker.simonis at gmail.com Fri Dec 21 16:34:22 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Dec 2018 17:34:22 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Christoph, thanks for updating the change. I think it is in a good state now and ready to go! Also the documentation in the CSR for this issue ( https://bugs.openjdk.java.net/browse/JDK-8213082) is greatly appreciated and answers all the questions which have been raised so far. So if there are still any open questions I'd recommend that any potential reviewer consults the CSR at https://bugs.openjdk.java.net/browse/JDK-8213082 first. Thank you and best regards, Volker On Fri, Dec 21, 2018 at 3:31 PM Langer, Christoph wrote: > Hi all, > > here comes the updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ > > I've rebased the change to the current state of the JDK depot. Thanks to > Volker, the test has been enhanced and now also tests more copy operations > (from zip file system to zip file system and from zip file system to > default file system and back). > > The points below were also addressed: > > > ZipFileAttributeView.java > > - can you please throw an AssertionError() for the default branch in > > the switch expression in the "ZipFileAttributeView.name()". > > The default branch will return "basic". Looking at the code it should not > be jumped to anyway. > > > ZipFileSystem.java > > - please also put @Override annotations on the method implementations > > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > > a comment at the place where the implementation of the > > "PosixFileAttributes" methods starts. > > Done, I also reordered the methods - first "basic" then "posix" then "zip". > > > ZipUtils.java > > - just a question: isn't it possible to reuse > > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > > constants from sun.nio.fs.UnixConstants instead of redefining them > > here? You could export them from java.base to jdk.zipfs but the > > problem is probably that at least sun.nio.fs.UnixConstants is a > > generated class which only gets generated on Unix systems, right ? > > You've already answered yourself ?? These classes only exist on Unix type > JDKs. > > > ZipFileAttributes.java > > - it seems a little odd that you've added "setPermissions()" to > > ZipFileAttributes. All the attribute classes (i.e. > > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > > possible to implement "ZipFileAttributeView.setPermissions()" by > > calling "path.setPermissions()" (as this is done in > > "ZipFileAttributeView.setTimes()") and handle everything in > > ZipFileSyste (as this is done with "setTimes()"). > > Good catch & thanks for providing the better implementation. > > > I think this version is quite final now and thoroughly tested. I hope to > get some valid reviews soon... > > Thanks > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Dec 21 16:43:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Dec 2018 17:43:14 +0100 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: Hi Alan, thanks for looking at this issue. I've dived into the ZipFS implementation during the last weeks and together with Christoph we've extended and improved both the implementation the test coverage. As Christoph already emphasized, this change is only for improving jdk.nio.zipfs without any side effects on java.util.zip and java.util.jar. Please find my comments for the CSR below (for some reason I couldn't add them to the CSR directly). I'd really appreciate if you could reconsider reviewing Christoph's change ("RFR 8213031: (zipfs) Add support for POSIX file permissions") and CSR. Thank you, Volker ============================================= I've thoroughly looked at this proposal and honestly speaking, I don't think that we even need a CSR for the proposed enhancement. Only the implementation of some classes in the `jdk.nio.zipfs` package are changed but no publicly exported API's. As Christoph emphasized, the proposed changes **only** affect the Zip File System as implemented in the `jdk.nio.zipfs` package. It doesn't touch neither the implementation nor the behavior of any of the classes in the `java.util.zip` or `java.util.jar` packages. Previous reviewers of this CSR and of the corresponding change JDK-8213031 raised some concerns regarding the security implication of this change - especially in the context of signed jars. I've looked at these concerns but I couldn't find any evidence for problems because: - no exposed JAR functionality is affected by these changes (because that is handled by the implementation in `java.util.zip` and `java.util.jar`) - Jar signing doesn't take file attributes into account (even not the basic attributes like the modification time). It only hashes the file contents. You can already now use external zip tools to update the attributes of files in a signed archive without affecting the validity of the signature. For all these reasons I've reviewed this CSR and I kindly ask you to approve it. On Fri, Dec 21, 2018 at 2:43 PM Langer, Christoph wrote: > > Hi Alan, > > > Adding support for POSIX file permissions to the zip APIs is problematic > > as we've been discussing here. There are security concerns and also > > concerns that how it interacts with JAR files and signed JAR in > > particular. I don't disagree that we can come to agreement on zipfs > > supporting a solution but I think we need to get the bigger picture on > > where this is going first. If the piece to change the java.util.zip APIs > > is dropped then it would make these discussions a lot simpler as it > > removes most of the security issues from the table. > > Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. > > Best regards > Christoph > From joe.darcy at oracle.com Fri Dec 21 17:45:48 2018 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 21 Dec 2018 09:45:48 -0800 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: <04f9501d-4a4d-be0e-74ff-0c9dd4978dc6@oracle.com> Hello, On 12/21/2018 8:43 AM, Volker Simonis wrote: > Hi Alan, > > thanks for looking at this issue. I've dived into the ZipFS > implementation during the last weeks and together with Christoph we've > extended and improved both the implementation the test coverage. As > Christoph already emphasized, this change is only for improving > jdk.nio.zipfs without any side effects on java.util.zip and > java.util.jar. > > Please find my comments for the CSR below (for some reason I couldn't > add them to the CSR directly). > To leave a comment on a CSR, using the "Comment" button at the top of the page or hit "Edit", rather than the "Comment" button at the bottom of the page (known bug). HTH, -Joe From sean.mullan at oracle.com Fri Dec 21 19:25:20 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Dec 2018 14:25:20 -0500 Subject: RFR 8215769: Java cannot probe pkcs12 files exported by Firefox In-Reply-To: <4AB29418-89AA-4CD3-810D-A941E376BB33@oracle.com> References: <4AB29418-89AA-4CD3-810D-A941E376BB33@oracle.com> Message-ID: Looks fine. I think pushing to JDK 13 is fine for now. --Sean On 12/20/18 8:57 PM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8215769/webrev.00/ > > It's currently P4 because I don't think many people import pkcs12 files from Firefox to Java, and even if so, one can always specify the storepass as a workaround. If you think this is more useful I can change it to P3 and push to JDK 12. This fix is safe. > > Thanks > Max > From sean.mullan at oracle.com Fri Dec 21 19:51:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Dec 2018 14:51:26 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> <729c4213-6b2a-d847-66e3-be726cc04e1b@oracle.com> Message-ID: <323c1437-fd54-47d3-785c-ed2f029c9071@oracle.com> On 12/21/18 9:50 AM, Weijun Wang wrote: >> I think it is ok to use secp384r1 in the release note even though it is the default for -keysize 384. > OK, I'll use it. And I've just added another sentence that we recommend using -groupname. Looks good now. --Sean From weijun.wang at oracle.com Sat Dec 22 01:02:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 22 Dec 2018 09:02:17 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <323c1437-fd54-47d3-785c-ed2f029c9071@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> <729c4213-6b2a-d847-66e3-be726cc04e1b@oracle.com> <323c1437-fd54-47d3-785c-ed2f029c9071@oracle.com> Message-ID: Thanks for the extra editing. I've updated it to delivered. --Max > On Dec 22, 2018, at 3:51 AM, Sean Mullan wrote: > > On 12/21/18 9:50 AM, Weijun Wang wrote: >>> I think it is ok to use secp384r1 in the release note even though it is the default for -keysize 384. >> OK, I'll use it. And I've just added another sentence that we recommend using -groupname. > > Looks good now. > > --Sean From xuelei.fan at oracle.com Sat Dec 22 17:20:25 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Sat, 22 Dec 2018 09:20:25 -0800 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel Message-ID: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Hi, Could I get the update reviewed? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ The reproducing testing case passed with the update. The issue is caused by the handshake status "NEED_WRAP" while the connection is half-closed. An application may just call wrap() when the handshake status is "NEED_WRAP". For compatibility, I changed the handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound half-closed connection. An application can use SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() should be called. Thanks, Xuelei From wenxiang.qiu at foxmail.com Tue Dec 25 07:26:03 2018 From: wenxiang.qiu at foxmail.com (=?ISO-8859-1?B?VmluY2VudA==?=) Date: Tue, 25 Dec 2018 15:26:03 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> References: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> Message-ID: Hi Max, Thanks for your reply. Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: [LoginContext]: login OPTIONAL failure And that's all. So the crucial problem is completely hidden. I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. ------------------ Original ------------------ From: "Weijun Wang"; Date: Tue, Dec 11, 2018 05:55 PM To: "Vincent"; Cc: "security-dev at openjdk.java.net"; Subject: Re: java.lang.Error is swallowed by LoginContext#invoke Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. --Max > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > Hi everyone, > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > Wenxiang Qiu -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Dec 25 07:44:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Dec 2018 15:44:57 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: References: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> Message-ID: <91EDD1F5-3F2C-46F6-B2C4-55FC4D902A46@oracle.com> I see. I am not sure we can fail here because historically we don't differentiate between a "system" failure and an "application" failure. Although the methods in LoginModule specify a LoginException, if another exception is thrown, we now treat it as a normal login error. Maybe we can add more debug info. Do you have a suggested fix? I assume you see the "OPTIONAL failure" word but you'd like something like a stack trace? Thanks, Max > On Dec 25, 2018, at 3:26 PM, Vincent wrote: > > Hi Max, > > Thanks for your reply. > Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: > [LoginContext]: login OPTIONAL failure > And that's all. So the crucial problem is completely hidden. > I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. > > > ------------------ Original ------------------ > From: "Weijun Wang"; > Date: Tue, Dec 11, 2018 05:55 PM > To: "Vincent"; > Cc: "security-dev at openjdk.java.net"; > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. > > Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. > > --Max > > > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > > > Hi everyone, > > > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > > > Wenxiang Qiu > From wenxiang.qiu at foxmail.com Tue Dec 25 08:16:03 2018 From: wenxiang.qiu at foxmail.com (=?ISO-8859-1?B?VmluY2VudA==?=) Date: Tue, 25 Dec 2018 16:16:03 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: <91EDD1F5-3F2C-46F6-B2C4-55FC4D902A46@oracle.com> References: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> <91EDD1F5-3F2C-46F6-B2C4-55FC4D902A46@oracle.com> Message-ID: If an Error is thrown, I would like that LoginContext's invoke() take it from InvocationTargetException and log the stack trace when debug is on. In fact I even wonder why Method's invoke() method turns unchecked Errors into checked InvocationTargetExceptions but it's out of the scope of this mail group. ------------------ Original ------------------ From: "Weijun Wang"; Date: Tue, Dec 25, 2018 03:44 PM To: "Vincent"; Cc: "security-dev at openjdk.java.net"; Subject: Re: java.lang.Error is swallowed by LoginContext#invoke I see. I am not sure we can fail here because historically we don't differentiate between a "system" failure and an "application" failure. Although the methods in LoginModule specify a LoginException, if another exception is thrown, we now treat it as a normal login error. Maybe we can add more debug info. Do you have a suggested fix? I assume you see the "OPTIONAL failure" word but you'd like something like a stack trace? Thanks, Max > On Dec 25, 2018, at 3:26 PM, Vincent wrote: > > Hi Max, > > Thanks for your reply. > Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: > [LoginContext]: login OPTIONAL failure > And that's all. So the crucial problem is completely hidden. > I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. > > > ------------------ Original ------------------ > From: "Weijun Wang"; > Date: Tue, Dec 11, 2018 05:55 PM > To: "Vincent"; > Cc: "security-dev at openjdk.java.net"; > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. > > Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. > > --Max > > > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > > > Hi everyone, > > > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > > > Wenxiang Qiu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Dec 25 08:47:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Dec 2018 16:47:01 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: References: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> <91EDD1F5-3F2C-46F6-B2C4-55FC4D902A46@oracle.com> Message-ID: <1FAC541F-D2C0-40A6-B3F5-53E6C920A6BA@oracle.com> I just filed https://bugs.openjdk.java.net/browse/JDK-8215916. Thanks, Max > On Dec 25, 2018, at 4:16 PM, Vincent wrote: > > If an Error is thrown, I would like that LoginContext's invoke() take it from InvocationTargetException and log the stack trace when debug is on. > > In fact I even wonder why Method's invoke() method turns unchecked Errors into checked InvocationTargetExceptions but it's out of the scope of this mail group. > > ------------------ Original ------------------ > From: "Weijun Wang"; > Date: Tue, Dec 25, 2018 03:44 PM > To: "Vincent"; > Cc: "security-dev at openjdk.java.net"; > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > I see. > > I am not sure we can fail here because historically we don't differentiate between a "system" failure and an "application" failure. Although the methods in LoginModule specify a LoginException, if another exception is thrown, we now treat it as a normal login error. > > Maybe we can add more debug info. Do you have a suggested fix? I assume you see the "OPTIONAL failure" word but you'd like something like a stack trace? > > Thanks, > Max > > > On Dec 25, 2018, at 3:26 PM, Vincent wrote: > > > > Hi Max, > > > > Thanks for your reply. > > Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: > > [LoginContext]: login OPTIONAL failure > > And that's all. So the crucial problem is completely hidden. > > I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. > > > > > > ------------------ Original ------------------ > > From: "Weijun Wang"; > > Date: Tue, Dec 11, 2018 05:55 PM > > To: "Vincent"; > > Cc: "security-dev at openjdk.java.net"; > > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > > > Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. > > > > Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. > > > > --Max > > > > > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > > > > > Hi everyone, > > > > > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > > > > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > > > > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > > > > > Wenxiang Qiu > > > From wenxiang.qiu at foxmail.com Tue Dec 25 12:09:20 2018 From: wenxiang.qiu at foxmail.com (=?ISO-8859-1?B?VmluY2VudA==?=) Date: Tue, 25 Dec 2018 20:09:20 +0800 Subject: java.lang.Error is swallowed by LoginContext#invoke In-Reply-To: <1FAC541F-D2C0-40A6-B3F5-53E6C920A6BA@oracle.com> References: <25B73386-B645-4BBA-B2E8-184EE5557FF5@oracle.com> <91EDD1F5-3F2C-46F6-B2C4-55FC4D902A46@oracle.com> <1FAC541F-D2C0-40A6-B3F5-53E6C920A6BA@oracle.com> Message-ID: Thanks Max. I'll try to submit a patch. ------------------ Original ------------------ From: "Weijun Wang"; Date: Tue, Dec 25, 2018 04:47 PM To: "Vincent"; Cc: "security-dev at openjdk.java.net"; Subject: Re: java.lang.Error is swallowed by LoginContext#invoke I just filed https://bugs.openjdk.java.net/browse/JDK-8215916. Thanks, Max > On Dec 25, 2018, at 4:16 PM, Vincent wrote: > > If an Error is thrown, I would like that LoginContext's invoke() take it from InvocationTargetException and log the stack trace when debug is on. > > In fact I even wonder why Method's invoke() method turns unchecked Errors into checked InvocationTargetExceptions but it's out of the scope of this mail group. > > ------------------ Original ------------------ > From: "Weijun Wang"; > Date: Tue, Dec 25, 2018 03:44 PM > To: "Vincent"; > Cc: "security-dev at openjdk.java.net"; > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > I see. > > I am not sure we can fail here because historically we don't differentiate between a "system" failure and an "application" failure. Although the methods in LoginModule specify a LoginException, if another exception is thrown, we now treat it as a normal login error. > > Maybe we can add more debug info. Do you have a suggested fix? I assume you see the "OPTIONAL failure" word but you'd like something like a stack trace? > > Thanks, > Max > > > On Dec 25, 2018, at 3:26 PM, Vincent wrote: > > > > Hi Max, > > > > Thanks for your reply. > > Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: > > [LoginContext]: login OPTIONAL failure > > And that's all. So the crucial problem is completely hidden. > > I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. > > > > > > ------------------ Original ------------------ > > From: "Weijun Wang"; > > Date: Tue, Dec 11, 2018 05:55 PM > > To: "Vincent"; > > Cc: "security-dev at openjdk.java.net"; > > Subject: Re: java.lang.Error is swallowed by LoginContext#invoke > > > > Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS. > > > > Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. > > > > --Max > > > > > On Dec 11, 2018, at 4:57 PM, Wenxiang wrote: > > > > > > Hi everyone, > > > > > > I was using Hadoop command line interface to access HDFS with a non-root user. After successfully running kinit, Hadoop FsShell fails with GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt). After using a subclassed Krb5LoginModule to print out necessary debug info, I found that the login module's login method failed because permissions of some jars in classpath are not properly set and process doesn't have read permissions to them. A java.lang.ExceptionInInitializerError is thrown. Because the login method is invoked via reflection in LoginContext, the ExceptionInInitializerError is wrapped in an InvocationTargetException and is caught in LoginContext#invoke. Since this Kerberos login module is optional and the following login module logins successfully, the exception is logged nowhere and the ExceptionInInitializerError thrown from deep in the call stack is completely swallowed silently, making debugging this problem extremely hard. > > > > > > My point here is that codes in LoginModule are not supposed to catch and process java.lang.Error, and I am confused by the way that reflection method invocation in LoginContext#invoke just swallows silently errors thrown by the method invoked. When an Error occurs, it means something really bad happened. I think LoginContext#invoke should either propagate errors to upper codes, or at least log such events. > > > > > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would like to have some expert comments on this to help me understand this design. Thanks. > > > > > > Wenxiang Qiu > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Dec 27 08:11:27 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Dec 2018 16:11:27 +0800 Subject: [13] RFR 8215937: Check usages of security-related Resources files Message-ID: <204CAB4B-B666-4B26-84E0-3F47875B3122@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8215937/webrev.00/ A new Usages.java test is added to make sure the strings in various Resources.java files are exactly what are used in security-related source files, no more no less. Two old tests are removed. NewNamesFormat.java checks for format and Usages.java covers it. NewResourcesNames.java is a manual test and is too stale and not easy to run. Several calls in keytool and jarsigner are modified to follow a more consistent calling convention (always rb.getString(string_literal)) so that they can be detected by Usages.java more easily. There are still several places in PolicyFile.java calling 'LocalizedMessage.getNonlocalized(POLICY + "...", source)' but I left them unchanged and dealt with it specially in Usages.java. Many useless strings in Resources.java files are removed. I've double checked each and made sure the related calls were removed some time ago. Thanks Max From weijun.wang at oracle.com Fri Dec 28 13:07:04 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Dec 2018 21:07:04 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181219203103.GK22527@twosigma.com> Message-ID: If we are not going to use or implement new functions defined in RFC 5587, I doubt if this is useful. And I don't think we can rewrite existing declarations in gssapi.h to use these const types. Or can we? Thanks, Max > On Dec 20, 2018, at 6:53 AM, Valerie Peng wrote: > > Sure, those typedefs makes sense. > > Thanks, > Valerie > On 12/19/2018 12:31 PM, Nico Williams wrote: >> On Wed, Dec 12, 2018 at 02:20:24PM -0800, Valerie Peng wrote: >>> - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable >>> naming convention starts with lower case? the argument qop_state may be >>> non-null but is not set?|| >> Nowadays we have gss_const_* types. You have to use those because >> otherwise const won't be doing what you think when you pass typedef'ed >> pointers. See RFC 5587. You need to add the following typedefs to >> src/java.security.jgss/share/native/libj2gss/gssapi.h: >> >> typedef const gss_buffer_desc *gss_const_buffer_t; >> typedef const struct gss_channel_bindings_struct *gss_const_channel_bindings_t; >> typedef const struct gss_ctx_id_struct *gss_const_ctx_id_t; >> typedef const struct gss_cred_id_struct *gss_const_cred_id_t; >> typedef const struct gss_name_struct *gss_const_name_t; >> typedef const gss_OID_desc *gss_const_OID; >> typedef const gss_OID_set_desc *gss_const_OID_set; >> >>> - gss_add_oid_set_member: add "const" to the 2nd argument? >>> - gss_display_status: add "const" to the 4th argument? As for the impl, I >>> have a question, this particular method is for displaying text output for >>> gssapi error codes, but the FormatMessage() call takes window specific >>> message id. Are they the same? >> See above. >> >> Nico From weijun.wang at oracle.com Sat Dec 29 02:20:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 29 Dec 2018 10:20:56 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <3976d319-8ad1-ffb3-8bdb-314a46607ded@oracle.com> References: <3976d319-8ad1-ffb3-8bdb-314a46607ded@oracle.com> Message-ID: I redefine "new" to be "new (std::nothrow)" in the program. Thanks, Max > On Dec 20, 2018, at 6:44 AM, Ivan Gerasimov wrote: > > Hi Max! > > In sspi.cpp native memory is allocated via `new` or `new []`, and sometimes the returned pointer is checked for NULL. > > If `new` fails, it will throw the `std:: bad_alloc` exception, so I believe you should use `new (std::nothrow)` and `new (std::nothrow) []` instead. > > With kind regards, > Ivan > > On 11/19/18 5:56 PM, Weijun Wang wrote: >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ >> >> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. >> >> No regression tests included. A Windows Active Directory server is needed. >> >> Thanks >> Max >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8200468 > > -- > With kind regards, > Ivan Gerasimov > From Nico.Williams at twosigma.com Mon Dec 31 06:36:40 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 31 Dec 2018 06:36:40 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181219203103.GK22527@twosigma.com> Message-ID: <20181231063640.GL22527@twosigma.com> On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote: > If we are not going to use or implement new functions defined in RFC 5587, I > doubt if this is useful. Using pointers to incomplete structs is much better than pointers to void: you get static type safety. When we made that change in Solaris' libgss we found at least one serious bug. > And I don't think we can rewrite existing declarations in gssapi.h to use > these const types. Or can we? Actually, you can. Heimdal and MIT made those changes. Nico --