From valerie.peng at oracle.com Mon Jun 1 20:36:47 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 01 Jun 2015 13:36:47 -0700 Subject: RFR 8031111: fix krb5 caddr (and 8079821: MSOID2.java test is not perfect) In-Reply-To: <554CCFA1.4070800@oracle.com> References: <554CCFA1.4070800@oracle.com> Message-ID: <556CC25F.5010408@oracle.com> Some nit/questions for 8031111 webrev: In the test, why not use "noaddresses" since it's the one documented in the krb5 conf page? If "noaddresses" is true, then the extra_addresses has no effect, right? I didn't see checking for the "noaddresses" in HostAddresses.java file. Is that done somewhere else? As for 8079821 webrev, do u need to check nt[pos-1] for overflow as well when adding 1 to it? Valerie On 5/8/2015 8:00 AM, Weijun Wang wrote: > Hi Valerie > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8031111/webrev.00/ > > The codes to read local addresses are updated. We are also supporting > the extra_addresses krb5.conf setting. > > This code change triggers a bug (MSOID2.java) in a test I've recently > added, please also review the change at > > http://cr.openjdk.java.net/~weijun/8079821/webrev.00/ > > Thanks > Max From magnus.ihse.bursie at oracle.com Mon Jun 1 23:39:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 01:39:05 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <5567924B.5030604@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> Message-ID: <556CED19.5050700@oracle.com> On 2015-05-29 00:10, Valerie Peng wrote: > > Please find comments in line... > > On 5/27/2015 3:42 PM, Mandy Chung wrote: >> Valerie, >> >> Did you see my comment yesterday? >> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html > Yes, we exchanged emails after this above one. I will follow up your > latest one later today. > >> >> Since you have reverted the java.security to keep the classname, to >> avoid causing merge conflict to jimage refresh, let?s remove the >> META-INF files in the first push and the build change. >> >> The security providers will be loaded via the fallback mechanism >> (i.e. ProviderLoader.legacyLoad method). You should keep the >> ProviderLoader.load method to take the provider name instead of >> classname. > Sure, I can remove the META-INF files so the providers are loaded > through the legacyLoad(). > Hmm, the ProviderLoader.load() method is used by java.security file > provider loading. Since the current list still uses class name, it > should take class name when checking for matches while iterating > through the list returned by ServiceLoader. > This way, when changes are sync'ed into Jake, no extra change required > and the providers will be loaded through ProviderLoader.load() > automatically with the current list. > >> I?ll file a bug to follow up to change java.security to list the >> provider name. This will wait after the jimage refresh goes into >> jdk9/dev > Ok. > Thanks, > Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus >> . >> >> Mandy >> >>> On May 27, 2015, at 3:29 PM, Valerie Peng >>> wrote: >>> >>> Hi, build experts, >>> >>> Can you please review the make file related change, i.e. the new >>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>> >>> This is for merging the java.security.Provider file from various >>> providers and use the (merged) result for the final image build. >>> >>> The rest of source code changes are reviewed by my team already. >>> Thanks, >>> Valerie >>> (Java Security Team) From weijun.wang at oracle.com Tue Jun 2 01:24:22 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 02 Jun 2015 09:24:22 +0800 Subject: RFR 8031111: fix krb5 caddr (and 8079821: MSOID2.java test is not perfect) In-Reply-To: <556CC25F.5010408@oracle.com> References: <554CCFA1.4070800@oracle.com> <556CC25F.5010408@oracle.com> Message-ID: <556D05C6.7020500@oracle.com> On 06/02/2015 04:36 AM, Valerie Peng wrote: > > Some nit/questions for 8031111 webrev: > In the test, why not use "noaddresses" since it's the one documented in > the krb5 conf page? I'll use noaddresses. > If "noaddresses" is true, then the extra_addresses has no effect, right? > I didn't see checking for the "noaddresses" in HostAddresses.java file. > Is that done somewhere else? The getLocalAddresses() method is only called in KrbAsReq as if (addresses == null && cfg.useAddresses()) { addresses = HostAddresses.getLocalAddresses(); } cfg.useAddress() checks the noaddresses setting. > > As for 8079821 webrev, do u need to check nt[pos-1] for overflow as well > when adding 1 to it? I don't think it's worth doing. Overflow at nt[pos-1] means the size is bigger than 65535 (or 32767, unsigned? Not sure at the momemnt) which is impossible for a SPNEGO token. Furthermore, if we really want to worry about it, we will need to expand the length octets from 2 bytes to 3 bytes and it will be much more complicated. Thanks Max > Valerie > > On 5/8/2015 8:00 AM, Weijun Wang wrote: >> Hi Valerie >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8031111/webrev.00/ >> >> The codes to read local addresses are updated. We are also supporting >> the extra_addresses krb5.conf setting. >> >> This code change triggers a bug (MSOID2.java) in a test I've recently >> added, please also review the change at >> >> http://cr.openjdk.java.net/~weijun/8079821/webrev.00/ >> >> Thanks >> Max From konstantin.shefov at oracle.com Tue Jun 2 12:15:48 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 2 Jun 2015 05:15:48 -0700 (PDT) Subject: [9] Review request for 8072515: Test Task: Develop new tests for JEP 219: Datagram Transport Layer Security (DTLS) Message-ID: Hello, Please review new tests fro DTLS feature for JDK 9: bug: https://bugs.openjdk.java.net/browse/JDK-8072515 webrev: http://cr.openjdk.java.net/~kshefov/8072515/webrev.00/ Thanks -Konstantin From bradford.wetmore at oracle.com Wed Jun 3 00:56:19 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 02 Jun 2015 17:56:19 -0700 Subject: TLS ALPN Proposal v2 In-Reply-To: <555E7E98.9050208@oracle.com> References: <555E7E98.9050208@oracle.com> Message-ID: <556E50B3.3080709@oracle.com> Hi, I have just posted the second iteration of the ALPN proposal which hopefully addresses all of the comments raised here. It is in javadoc format, but things can certainly be adjusted: http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/ Please see the archive [1] for previous design discussion. I will be writing up usage examples in the next few days. The significant changes: ExtendedSSLSession public List getReceivedApplicationProtocols() { This will allow applications to examine which protocol names were sent. SSLParameters mentions both ALPN/NPN as possible protocols. I removed the discussion about "server" and "client" since ALPN/NPN essentially reverse the roles. mentions "appropriate character sets" for String-byte[] conversions such as UTF-8 for ALPN. The application protocol selector is now a @FunctionalInterface (i.e. lambda-ready) called SSLFunction. It is to throw an SSLException if no values are supported, or null if you want to treat as an unknown extension. Defined constants for HTTP/1.1 and HTTP/2. SSLSession Called out that getHandshakeSession's ciphersuite may vary until selected. SSLBase A new marker interface that SSLEngine/SSLSocket will implement. This will allow for a single SSLFunction instead of having SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require that the lambda do a instanceof, unless we were to move the common Socket/Engine APIs into this class. Thanks, Brad [1] http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012183.html From xuelei.fan at oracle.com Wed Jun 3 01:56:28 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Jun 2015 09:56:28 +0800 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <554AFFB2.6070500@redhat.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> <554AA643.4050101@oracle.com> <554AFFB2.6070500@redhat.com> Message-ID: <556E5ECC.4080404@oracle.com> Hi Florian, I can sponsor you for the specification update approval and changeset integration if needed. I still have a few comments about this fix: 1. TLS_FALLBACK_SCSV may still be miss-used as it is defined as a default enabled cipher suites. Some applications may just get all supported cipher suites and enable them all for a certain circumstance. For example: String[] suites = sslSocket.getSupportedCipherSuites(); sslSocket.setEnabledCipherSuites(suites); As would result in unexpected behavior as you concerned about this protocol. What do you think if TLS_FALLBACK_SCSV is not defined as a supported (enabled) cipher suite? I mean SSLSocket.getSupportedCipherSuites() would not return TLS_FALLBACK_SCSV in any cases. 2. SSLEngineImpl Better to update SSLEngineImpl.java in this fix as what you did for SSLSocketImpl.java 3. src/java.base/share/classes/javax/net/ssl/SSLParameters.java ------------ 472 * Note: Performing protocol downgrades outside the TLS 473 * protocol can introduce security vulnerabilities. The 474 * built-in version negotiation mechanism of the TLS protocol 475 * should be used instead of explicit protocol downgrades. 476 * See section 4 of RFC 7507 for additional advice. Sounds like it is a part of "implNote". ------------ 478 * @implNote 479 * The default JSSE provider uses the TLS_FALLBACK_SCSV signaling 480 * ciphersuite value to indicate protocol fallback, as specified 481 * in RFC 7507. As this is a public spec, any JSSE provider should follow this spec. I'd like to say: "A JSSE provider should use the TLS_FALLBACK_SCSV ..." ------------ 491 public final void setIndicateProtocolFallback( boolean indicateFallback) { 506 public final boolean getIndicateProtocolFallback() "setIndicate" does not sound like instinctive enough to me. What do you think: void indicateProtocolFallback(boolean useProtocolFallback) boolean isProtocolFallback() or void setUseProtocolFallback(boolean useProtocolFallback) boolean getUseProtocolFallback() Thanks, Xuelei On 5/7/2015 2:01 PM, Florian Weimer wrote: > On 05/07/2015 01:39 AM, Xuelei Fan wrote: >> On 5/6/2015 9:42 PM, Florian Weimer wrote: >>> On 05/06/2015 01:42 AM, Xuelei Fan wrote: >>>> As additional APIs are strongly desired, what do you think to make the >>>> API more general and easy to use? For example, using the name: >>>> >>>> SSLParameters.setUseFallbackMode(boolean isFallback) >>>> boolean SSLParameters.getuseFallbackMode() >>>> >>>> We can implement more for this parameters if need to take care of >>>> additional more problems during fallback negotiation. Instinctively, >>>> developers and code reviewers would not call this APIs unless this is a >>>> real fallback negotiation, I think. >>> >>> Sounds reasonable. I have add an @implNote mentioning that the default >>> provider sends TLS_FALLBACK_SCSV. >>> >>> >>> >> I guess the new webrev may be: >> http://cr.openjdk.java.net/~fweimer/8061798/webrev.02/ > > Right, sorry. > From xuelei.fan at oracle.com Wed Jun 3 06:23:24 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Jun 2015 14:23:24 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: <556E50B3.3080709@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> Message-ID: <556E9D5C.5040106@oracle.com> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java ================================================================= List getReceivedApplicationProtocols() ---------------------------------------------- C1. It might be useful to know the client requested application protocols in some circumstance. Better to set the application protocols in client side either. I'd like to use: - * Gets the application protocol value(s) received from the peer - * for this connection. + * Gets a {@link List} of requested application protocol value(s) + * for this connection. - public List getReceivedApplicationProtocols() { + public List getRequesedApplicationProtocols() { C2. The return value would better to be immutable, and better to describe the preference per RFC 7301. Maybe looks like: - * @return the non-null list of application protocol names + * @return the non-null immutable list of application protocol + * names, in descending order of preference. The returned + * list may be empty if no application protocols were + * requested. src/java.base/share/classes/javax/net/ssl/SSLParameters.java ============================================================ List getApplicationProtocols() -------------------------------------- C3. Better to indicate explicitly that this method only apply to client mode. C4. The method description is not instinctive enough for an application developer. Can we use words to indicate the purpose of the setting? For example: - * Gets the list of application-level protocol names that could - * be sent to the SSL/TLS peer. + * Gets the {@link List} of application layer protocol names that + * can be negotiated over SSL/TLS/DTLS protocols. C5. Prefer to use immutable return value: - * @return a non-null list of application protocol names. + * @return a non-null immutable list of application protocol names. C6. Nice to have a link for the standard protocol names. void setApplicationProtocols(List protocols) ---------------------------------------------------- C7. see C3. C8. see C4. s/getApplicationProtocolSelector() ---------------------------------- C9. The use of SSLFunction make the implementation of protocol selector and JSSE provider implementation complicated. >From the spec, looks like the selector may want to know address/ports, SSL protocol versions or the negotiated cipher suit. As would require that before use this selector, the handshaking must negotiate the protocol version and the cipher suite. That's a specific JSSE implementation requirement. It does not sound like a reasonable behavior. The implement of the selector is not straightforward, I think. Per section 4, RFC 7301: "... The "application_layer_protocol_negotiation" ServerHello extension is intended to be definitive for the connection (until the connection is renegotiated) and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol to be used in the connection. By placing ownership of protocol selection on the server, ALPN facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol." Per my understanding, application protocol should be negotiated before cipher suite and protocol version negotiated. And the connection may be rerouted (even to different machines) for further operation. The requested application protocols list should be the only information for the selection of a suitable application protocol. Based on that, I think it is more simple to use Simone's proposal: @FunctionalInterface interface ApplicationProtocolSelector { String select(List protocols) throws SSLException; } Hence, no need for a SSLBase any more. public static final String AP_HTTP_1_1 = "http/1.1"; public static final String AP_H2 = "h2"; ---------------------------------------- C10. I understand why the constants are defined here. However, usually, we don't define standard names in JSSE APIs. Instead, we normally use Oracle standard names documentation. src/java.base/share/classes/javax/net/ssl/SSLSession.java ========================================================= String getCipherSuite() ----------------------- Pretty hard to use this method with the new specification. It's not a necessary update, see #C9. Hope it helps! Xuelei On 6/3/2015 8:56 AM, Bradford Wetmore wrote: > Hi, > > I have just posted the second iteration of the ALPN proposal which > hopefully addresses all of the comments raised here. It is in javadoc > format, but things can certainly be adjusted: > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/ > > Please see the archive [1] for previous design discussion. I will be > writing up usage examples in the next few days. > > The significant changes: > > ExtendedSSLSession > public List getReceivedApplicationProtocols() { > > This will allow applications to examine which protocol names were > sent. > > SSLParameters > mentions both ALPN/NPN as possible protocols. I removed the > discussion about "server" and "client" since ALPN/NPN essentially > reverse the roles. > > mentions "appropriate character sets" for String-byte[] conversions > such as UTF-8 for ALPN. > > The application protocol selector is now a @FunctionalInterface > (i.e. lambda-ready) called SSLFunction. It is to throw an > SSLException if no values are supported, or null if you want to > treat as an unknown extension. > > Defined constants for HTTP/1.1 and HTTP/2. > > SSLSession > > Called out that getHandshakeSession's ciphersuite may vary until > selected. > > SSLBase > > A new marker interface that SSLEngine/SSLSocket will implement. > This will allow for a single SSLFunction instead of having > SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require > that the lambda do a instanceof, unless we were to move the common > Socket/Engine APIs into this class. > > Thanks, > > Brad > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012183.html From xuelei.fan at oracle.com Wed Jun 3 08:55:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Jun 2015 16:55:02 +0800 Subject: Code Review Request, JDK-8081792, buffer size calculation issue in NativeGCMCipher Message-ID: <556EC0E6.7000907@oracle.com> Hi Weijun or Valerie, Can I get a quick code review for this simple fix? DTLS implementation exposes the bug. There are a few new nightly testing failure. No new regression test. The existing test cases (the nightly testing failure) can be used as regression test instead. Webrev: http://cr.openjdk.java.net/~xuelei/8081792/webrev.00/ Thanks, Xuelei From valerie.peng at oracle.com Wed Jun 3 17:12:22 2015 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 03 Jun 2015 10:12:22 -0700 Subject: Code Review Request, JDK-8081792, buffer size calculation issue in NativeGCMCipher In-Reply-To: <556EC0E6.7000907@oracle.com> References: <556EC0E6.7000907@oracle.com> Message-ID: <556F3576.2050106@oracle.com> Change looks fine. Thanks, Valerie On 06/03/15 01:55, Xuelei Fan wrote: > Hi Weijun or Valerie, > > Can I get a quick code review for this simple fix? DTLS implementation > exposes the bug. There are a few new nightly testing failure. No new > regression test. The existing test cases (the nightly testing failure) > can be used as regression test instead. > > Webrev: http://cr.openjdk.java.net/~xuelei/8081792/webrev.00/ > > Thanks, > Xuelei From valerie.peng at oracle.com Wed Jun 3 17:27:16 2015 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 03 Jun 2015 10:27:16 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <556CED19.5050700@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> Message-ID: <556F38F4.4070109@oracle.com> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: > On 2015-05-29 00:10, Valerie Peng wrote: >> >> Please find comments in line... >> >> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>> Valerie, >>> >>> Did you see my comment yesterday? >>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>> >> Yes, we exchanged emails after this above one. I will follow up your >> latest one later today. >> >>> >>> Since you have reverted the java.security to keep the classname, to >>> avoid causing merge conflict to jimage refresh, let?s remove the >>> META-INF files in the first push and the build change. >>> >>> The security providers will be loaded via the fallback mechanism >>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>> ProviderLoader.load method to take the provider name instead of >>> classname. >> Sure, I can remove the META-INF files so the providers are loaded >> through the legacyLoad(). >> Hmm, the ProviderLoader.load() method is used by java.security file >> provider loading. Since the current list still uses class name, it >> should take class name when checking for matches while iterating >> through the list returned by ServiceLoader. >> This way, when changes are sync'ed into Jake, no extra change >> required and the providers will be loaded through >> ProviderLoader.load() automatically with the current list. >> >>> I?ll file a bug to follow up to change java.security to list the >>> provider name. This will wait after the jimage refresh goes into >>> jdk9/dev >> Ok. >> Thanks, >> Valerie > > I'm not sure I followed completely here were this landed. Does this > mean that there's currently no need for a build system code review on > http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a > new webrev will be posted instead? > > /Magnus > > > >>> . >>> >>> Mandy >>> >>>> On May 27, 2015, at 3:29 PM, Valerie Peng >>>> wrote: >>>> >>>> Hi, build experts, >>>> >>>> Can you please review the make file related change, i.e. the new >>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>> >>>> This is for merging the java.security.Provider file from various >>>> providers and use the (merged) result for the final image build. >>>> >>>> The rest of source code changes are reviewed by my team already. >>>> Thanks, >>>> Valerie >>>> (Java Security Team) > From valerie.peng at oracle.com Wed Jun 3 18:31:40 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 03 Jun 2015 11:31:40 -0700 Subject: RFR 8031111: fix krb5 caddr (and 8079821: MSOID2.java test is not perfect) In-Reply-To: <556D05C6.7020500@oracle.com> References: <554CCFA1.4070800@oracle.com> <556CC25F.5010408@oracle.com> <556D05C6.7020500@oracle.com> Message-ID: <556F480C.1030005@oracle.com> > I don't think it's worth doing. Overflow at nt[pos-1] means the size > is bigger than 65535 (or 32767, unsigned? Not sure at the momemnt) > which is impossible for a SPNEGO token. Furthermore, if we really want > to worry about it, we will need to expand the length octets from 2 > bytes to 3 bytes and it will be much more complicated. Ok, just add some comment to state this then. No further comments. Thanks, Valerie On 6/1/2015 6:24 PM, Weijun Wang wrote: > > > On 06/02/2015 04:36 AM, Valerie Peng wrote: >> >> Some nit/questions for 8031111 webrev: >> In the test, why not use "noaddresses" since it's the one documented in >> the krb5 conf page? > > I'll use noaddresses. > >> If "noaddresses" is true, then the extra_addresses has no effect, right? >> I didn't see checking for the "noaddresses" in HostAddresses.java file. >> Is that done somewhere else? > > The getLocalAddresses() method is only called in KrbAsReq as > > if (addresses == null && cfg.useAddresses()) { > addresses = HostAddresses.getLocalAddresses(); > } > > cfg.useAddress() checks the noaddresses setting. > >> >> As for 8079821 webrev, do u need to check nt[pos-1] for overflow as well >> when adding 1 to it? > > I don't think it's worth doing. Overflow at nt[pos-1] means the size > is bigger than 65535 (or 32767, unsigned? Not sure at the momemnt) > which is impossible for a SPNEGO token. Furthermore, if we really want > to worry about it, we will need to expand the length octets from 2 > bytes to 3 bytes and it will be much more complicated. > > Thanks > Max > >> Valerie >> >> On 5/8/2015 8:00 AM, Weijun Wang wrote: >>> Hi Valerie >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8031111/webrev.00/ >>> >>> The codes to read local addresses are updated. We are also supporting >>> the extra_addresses krb5.conf setting. >>> >>> This code change triggers a bug (MSOID2.java) in a test I've recently >>> added, please also review the change at >>> >>> http://cr.openjdk.java.net/~weijun/8079821/webrev.00/ >>> >>> Thanks >>> Max From sean.mullan at oracle.com Wed Jun 3 20:38:01 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 03 Jun 2015 16:38:01 -0400 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 Message-ID: <556F65A9.8090507@oracle.com> This is the third and fourth in a series of fixes for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/ bugs: https://bugs.openjdk.java.net/browse/JDK-8065942 and https://bugs.openjdk.java.net/browse/JDK-8056179 This fix changes the Permissions and PermissionCollection subclasses to use concurrent collections, which significantly reduces contention when multiple threads are performing security checks. The bugs needed to be fixed together, because removing the synchronized blocks in Permissions revealed that several of the underlying PermissionCollection implementations were not thread-safe. Several new unit tests were also added to test basic functionality of these classes. With these fixes, the throughput of the Permissions.implies method improves from approximately 6x to 10x when more than one thread is running. Each of the bugs contains a performance chart with more details. Thanks, Sean [1] http://openjdk.java.net/jeps/232 From joe.darcy at oracle.com Wed Jun 3 23:06:03 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 03 Jun 2015 16:06:03 -0700 Subject: JDK 9 RFR of JDK-8083436: Doclint regression introduced by JDK-8043758 Message-ID: <556F885B.40303@oracle.com> Hello, Please review the patch below to address a recently introduced doclint regression. Thanks, -Joe diff -r 5f952ade41ff src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java --- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed Jun 03 14:35:17 2015 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed Jun 03 16:04:22 2015 -0700 @@ -280,7 +280,7 @@ * @apiNote Note that sequence number is an unsigned long and cannot * exceed {@code -1L}. It is desired to use the unsigned * long comparing mode for comparison of unsigned long values - * (see also {@link java.lang.Long#compareUnsigned() + * (see also {@link java.lang.Long#compareUnsigned(long, long) * Long.compareUnsigned()}). *

* For DTLS protocols, the first 16 bits of the sequence @@ -300,7 +300,7 @@ * record; or ${@code -1L} if no record is produced or consumed, * or this operation is not supported by the underlying provider * - * @see java.lang.Long#compareUnsigned(boolean, boolean) + * @see java.lang.Long#compareUnsigned(long, long) * * @since 1.9 */ From bradford.wetmore at oracle.com Thu Jun 4 00:45:03 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 03 Jun 2015 17:45:03 -0700 Subject: JDK 9 RFR of JDK-8083436: Doclint regression introduced by JDK-8043758 In-Reply-To: <556F885B.40303@oracle.com> References: <556F885B.40303@oracle.com> Message-ID: <556F9F8F.3040207@oracle.com> Or I think you could also just remove the args, since there is only one compareUnsigned currently. Probably safer to use long, long. Brad On 6/3/2015 4:06 PM, Joseph D. Darcy wrote: > Hello, > > Please review the patch below to address a recently introduced doclint > regression. > > Thanks, > > -Joe > > diff -r 5f952ade41ff > src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > --- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed > Jun 03 14:35:17 2015 -0700 > +++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed > Jun 03 16:04:22 2015 -0700 > @@ -280,7 +280,7 @@ > * @apiNote Note that sequence number is an unsigned long and cannot > * exceed {@code -1L}. It is desired to use the unsigned > * long comparing mode for comparison of unsigned long > values > - * (see also {@link java.lang.Long#compareUnsigned() > + * (see also {@link java.lang.Long#compareUnsigned(long, > long) > * Long.compareUnsigned()}). > *

> * For DTLS protocols, the first 16 bits of the sequence > @@ -300,7 +300,7 @@ > * record; or ${@code -1L} if no record is produced or > consumed, > * or this operation is not supported by the underlying > provider > * > - * @see java.lang.Long#compareUnsigned(boolean, boolean) > + * @see java.lang.Long#compareUnsigned(long, long) > * > * @since 1.9 > */ > From xuelei.fan at oracle.com Thu Jun 4 01:01:10 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Jun 2015 09:01:10 +0800 Subject: JDK 9 RFR of JDK-8083436: Doclint regression introduced by JDK-8043758 In-Reply-To: <556F885B.40303@oracle.com> References: <556F885B.40303@oracle.com> Message-ID: <556FA356.9040609@oracle.com> Looks fine to me. Thanks for the update! Xuelei On 6/4/2015 7:06 AM, Joseph D. Darcy wrote: > Hello, > > Please review the patch below to address a recently introduced doclint > regression. > > Thanks, > > -Joe > > diff -r 5f952ade41ff > src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > --- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed > Jun 03 14:35:17 2015 -0700 > +++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed > Jun 03 16:04:22 2015 -0700 > @@ -280,7 +280,7 @@ > * @apiNote Note that sequence number is an unsigned long and cannot > * exceed {@code -1L}. It is desired to use the unsigned > * long comparing mode for comparison of unsigned long > values > - * (see also {@link java.lang.Long#compareUnsigned() > + * (see also {@link java.lang.Long#compareUnsigned(long, > long) > * Long.compareUnsigned()}). > *

> * For DTLS protocols, the first 16 bits of the sequence > @@ -300,7 +300,7 @@ > * record; or ${@code -1L} if no record is produced or > consumed, > * or this operation is not supported by the underlying > provider > * > - * @see java.lang.Long#compareUnsigned(boolean, boolean) > + * @see java.lang.Long#compareUnsigned(long, long) > * > * @since 1.9 > */ > From xuelei.fan at oracle.com Thu Jun 4 01:57:53 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Jun 2015 09:57:53 +0800 Subject: [9] Review request for 8072515: Test Task: Develop new tests for JEP 219: Datagram Transport Layer Security (DTLS) In-Reply-To: References: Message-ID: <556FB0A1.6020900@oracle.com> Looks fine to me. It's nice to keep each line not exceed 80 characters. For example - * @run main/othervm -Dtest.security.protocol=DTLS -Dtest.mode=norm DTLSBufferOverflowUnderflowTest + * @run main/othervm -Dtest.security.protocol=DTLS + * -Dtest.mode=norm DTLSBufferOverflowUnderflowTest Thanks, Xuelei On 6/2/2015 8:15 PM, Konstantin Shefov wrote: > Hello, > > Please review new tests fro DTLS feature for JDK 9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8072515 > webrev: http://cr.openjdk.java.net/~kshefov/8072515/webrev.00/ > > > Thanks > -Konstantin > From konstantin.shefov at oracle.com Thu Jun 4 11:51:30 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 04 Jun 2015 14:51:30 +0300 Subject: [9] Review request for 8072515: Test Task: Develop new tests for JEP 219: Datagram Transport Layer Security (DTLS) In-Reply-To: <556FB0A1.6020900@oracle.com> References: <556FB0A1.6020900@oracle.com> Message-ID: <55703BC2.5010203@oracle.com> Hi Xue-Lei Thanks for reviewing! I will reduce the line size, make JPRT testing and push then. -Konstantin On 06/04/2015 04:57 AM, Xuelei Fan wrote: > Looks fine to me. > > It's nice to keep each line not exceed 80 characters. For example > > - * @run main/othervm -Dtest.security.protocol=DTLS -Dtest.mode=norm > DTLSBufferOverflowUnderflowTest > + * @run main/othervm -Dtest.security.protocol=DTLS > + * -Dtest.mode=norm DTLSBufferOverflowUnderflowTest > > Thanks, > Xuelei > > On 6/2/2015 8:15 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review new tests fro DTLS feature for JDK 9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8072515 >> webrev: http://cr.openjdk.java.net/~kshefov/8072515/webrev.00/ >> >> >> Thanks >> -Konstantin >> From simone.bordet at gmail.com Thu Jun 4 12:11:05 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Jun 2015 14:11:05 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <556E50B3.3080709@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> Message-ID: Hi, On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore wrote: > Hi, > > I have just posted the second iteration of the ALPN proposal which hopefully > addresses all of the comments raised here. It is in javadoc format, but > things can certainly be adjusted: > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/ > > Please see the archive [1] for previous design discussion. I will be > writing up usage examples in the next few days. > > The significant changes: > > ExtendedSSLSession > public List getReceivedApplicationProtocols() { > > This will allow applications to examine which protocol names were > sent. This is a constant once the application protocols are received, so it can be surely retrieved from SSLParameters. I don't understand why it is replicated here ? > SSLParameters > mentions both ALPN/NPN as possible protocols. I removed the > discussion about "server" and "client" since ALPN/NPN essentially > reverse the roles. > > mentions "appropriate character sets" for String-byte[] conversions > such as UTF-8 for ALPN. > > The application protocol selector is now a @FunctionalInterface > (i.e. lambda-ready) called SSLFunction. It is to throw an > SSLException if no values are supported, or null if you want to > treat as an unknown extension. > > Defined constants for HTTP/1.1 and HTTP/2. > > SSLSession > > Called out that getHandshakeSession's ciphersuite may vary until > selected. > > SSLBase > > A new marker interface that SSLEngine/SSLSocket will implement. > This will allow for a single SSLFunction instead of having > SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require > that the lambda do a instanceof, unless we were to move the common > Socket/Engine APIs into this class. I'm not sure about this one being a marker interface. I could understand if it extracted the common functionality of SSLEngine and SSLSocket, but a marker interface does not really add much, and perhaps I would prefer it entirely gone. On the same note, why is SSLFunction generic at all ? Also, it is critical to detail how the mechanism work. Will SSLFunction be invoked multiple times, or only once ? When, exactly, with respect to cipher selection and alias selection ? Example implementations for SSLFunction would be great to have: the typical HTTP/2 case is to select the application protocol based on the TLS protocol and the already negotiated cipher. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Thu Jun 4 12:19:09 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Jun 2015 14:19:09 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <556E9D5C.5040106@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> Message-ID: Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: > Per section 4, RFC 7301: > "... The > "application_layer_protocol_negotiation" ServerHello extension is > intended to be definitive for the connection (until the connection is > renegotiated) and is sent in plaintext to permit network elements to > provide differentiated service for the connection when the TCP or UDP > port number is not definitive for the application-layer protocol to > be used in the connection. By placing ownership of protocol > selection on the server, ALPN facilitates scenarios in which > certificate selection or connection rerouting may be based on the > negotiated protocol." > > Per my understanding, application protocol should be negotiated before > cipher suite and protocol version negotiated. This is not possible for HTTP/2. Application protocol negotiation MUST happen *after* the TLS protocol and the TLS cipher are negotiated. > And the connection may be > rerouted (even to different machines) for further operation. The > requested application protocols list should be the only information for > the selection of a suitable application protocol. Not sure what you exactly mean here, but you can't pick the HTTP/2 protocol unless you have the TLS protocol and TLS cipher available. So *only* the list of protocol sent by the client is not enough for HTTP/2, we would need additional contextual information. What a HTTP/2 aware load balancer written in Java that offloads TLS would need to do is to negotiate the TLS protocol, negotiate the TLS cipher, *then* negotiate the application protocol (whether "h2" or "http/1.1"), and with the last information pick a backend server, typically forwarding clear text bytes to the backend. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From michael.x.mcmahon at oracle.com Thu Jun 4 13:08:10 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 04 Jun 2015 14:08:10 +0100 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> Message-ID: <55704DBA.70009@oracle.com> On 04/06/15 13:19, Simone Bordet wrote: > Hi, > > On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >> Per section 4, RFC 7301: >> "... The >> "application_layer_protocol_negotiation" ServerHello extension is >> intended to be definitive for the connection (until the connection is >> renegotiated) and is sent in plaintext to permit network elements to >> provide differentiated service for the connection when the TCP or UDP >> port number is not definitive for the application-layer protocol to >> be used in the connection. By placing ownership of protocol >> selection on the server, ALPN facilitates scenarios in which >> certificate selection or connection rerouting may be based on the >> negotiated protocol." >> >> Per my understanding, application protocol should be negotiated before >> cipher suite and protocol version negotiated. > This is not possible for HTTP/2. > Application protocol negotiation MUST happen *after* the TLS protocol > and the TLS cipher are negotiated. What do you mean by "after"? As far as TLS is concerned, all of this negotiation happens in one negotiation. The client proposes a list of ciphers and application protocols. The server chooses a cipher and application protocol and sends back its choices. The HTTP/2 RFC specifically warns against splitting this negotiation with the example that a client could propose a mandatory TLS 1.2 cipher, but which is black-listed by HTTP/2. If (internally) the server chooses that cipher first, without knowing the application protocol is going to be HTTP/2 then you end up with a non-compliant connection that will probably have to be closed for reason of insufficient security. - Michael >> And the connection may be >> rerouted (even to different machines) for further operation. The >> requested application protocols list should be the only information for >> the selection of a suitable application protocol. > Not sure what you exactly mean here, but you can't pick the HTTP/2 > protocol unless you have the TLS protocol and TLS cipher available. > So *only* the list of protocol sent by the client is not enough for > HTTP/2, we would need additional contextual information. > > What a HTTP/2 aware load balancer written in Java that offloads TLS > would need to do is to negotiate the TLS protocol, negotiate the TLS > cipher, *then* negotiate the application protocol (whether "h2" or > "http/1.1"), and with the last information pick a backend server, > typically forwarding clear text bytes to the backend. > > Thanks ! > From simone.bordet at gmail.com Thu Jun 4 14:18:24 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Jun 2015 16:18:24 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <55704DBA.70009@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55704DBA.70009@oracle.com> Message-ID: Hi, On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon wrote: > On 04/06/15 13:19, Simone Bordet wrote: >> >> Hi, >> >> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >>> >>> Per section 4, RFC 7301: >>> "... The >>> "application_layer_protocol_negotiation" ServerHello extension is >>> intended to be definitive for the connection (until the connection is >>> renegotiated) and is sent in plaintext to permit network elements to >>> provide differentiated service for the connection when the TCP or UDP >>> port number is not definitive for the application-layer protocol to >>> be used in the connection. By placing ownership of protocol >>> selection on the server, ALPN facilitates scenarios in which >>> certificate selection or connection rerouting may be based on the >>> negotiated protocol." >>> >>> Per my understanding, application protocol should be negotiated before >>> cipher suite and protocol version negotiated. >> >> This is not possible for HTTP/2. >> Application protocol negotiation MUST happen *after* the TLS protocol >> and the TLS cipher are negotiated. > > > What do you mean by "after"? As far as TLS is concerned, all of this > negotiation happens in one negotiation. The client proposes a list of > ciphers and application protocols. The server chooses a cipher > and application protocol and sends back its choices. Currently, IIUC, the cipher selection is an iterative process where a cipher is attempted until one is negotiated. In this process, there is no looking at the application protocol. Here we're trying to find a solution for ALPN, and either we 1) look the application protocol in this iterative process (and therefore the SSLFunction is invoked multiple times), so that TLS protocol, cipher (possibly the alias too) and application protocol are chosen together, at once (for each iteration); or 2) we separate the TLS protocol and cipher negotiation (and alias) in one step, and we perform application protocol selection afterwards. The latter is how Jetty's ALPN works, and that's what I mean with *after*. For HTTP/2 it won't work to pick the application protocol before the cipher. Either at the same time, or after. That is why I asked to specify how the mechanism worked. > The HTTP/2 RFC specifically warns against splitting this negotiation > with the example that a client could propose a mandatory TLS 1.2 cipher, > but which is black-listed by HTTP/2. If (internally) the server chooses that > cipher first, > without knowing the application protocol is going to be HTTP/2 > then you end up with a non-compliant connection that will probably have > to be closed for reason of insufficient security. If the server chooses a blacklisted cipher, and then "h2" as protocol, it's a non compliant server. Communication of clients with compliant (and properly configured) servers is guaranteed if the application protocol is chosen after (or at the same time of) the cipher. If I understand you correctly, you are proposing to rework the internal JDK code to perform TLS protocol, cipher, alias and application protocol in one point, which is then possibly iterated multiple times until a satisfactory tuple is selected ? I am fine with this approach too, but I guess the API will be very different from Jetty's ALPN and this current proposal (which is fine as well - does not have to be similar to Jetty's). I don't know enough about the TLS implementation to say how much work it is. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Jun 4 15:53:25 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Jun 2015 23:53:25 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> Message-ID: <55707475.8060401@oracle.com> On 6/4/2015 8:19 PM, Simone Bordet wrote: > Hi, > > On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >> Per section 4, RFC 7301: >> "... The >> "application_layer_protocol_negotiation" ServerHello extension is >> intended to be definitive for the connection (until the connection is >> renegotiated) and is sent in plaintext to permit network elements to >> provide differentiated service for the connection when the TCP or UDP >> port number is not definitive for the application-layer protocol to >> be used in the connection. By placing ownership of protocol >> selection on the server, ALPN facilitates scenarios in which >> certificate selection or connection rerouting may be based on the >> negotiated protocol." >> >> Per my understanding, application protocol should be negotiated before >> cipher suite and protocol version negotiated. > > This is not possible for HTTP/2. > Application protocol negotiation MUST happen *after* the TLS protocol > and the TLS cipher are negotiated. > Why? Is it a spec of HTTP/2? It is a point I don't understand now. Please help with more details. >> And the connection may be >> rerouted (even to different machines) for further operation. The >> requested application protocols list should be the only information for >> the selection of a suitable application protocol. > > Not sure what you exactly mean here, Here is an example to explain the "rerouting". For example, there a four entities, an TLS client, a router, an http/2 over TLS server, and an http/1.1 over TLS server. 1. the client request a connection to the http/2 server, the TCP connection is established between the client the router at first. 2. the router analysis the ClientHello message, and reroute the connection to the http/2 server. 3. the client and http/2 server negotiate the TLS connection, including the SSL protocol and cipher suite. The router should not be able to play man-in-the-middle negotiation if it does not know the server credentials. > but you can't pick the HTTP/2 > protocol unless you have the TLS protocol and TLS cipher available. > So *only* the list of protocol sent by the client is not enough for > HTTP/2, we would need additional contextual information. > See my question above. > What a HTTP/2 aware load balancer written in Java that offloads TLS > would need to do is to negotiate the TLS protocol, negotiate the TLS > cipher, *then* negotiate the application protocol (whether "h2" or > "http/1.1"), and with the last information pick a backend server, > typically forwarding clear text bytes to the backend. > See my question above. Thanks, Xuelei From michael.x.mcmahon at oracle.com Thu Jun 4 15:56:25 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 04 Jun 2015 16:56:25 +0100 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55704DBA.70009@oracle.com> Message-ID: <55707529.4080900@oracle.com> On 04/06/15 15:18, Simone Bordet wrote: > Hi, > > On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon > wrote: >> On 04/06/15 13:19, Simone Bordet wrote: >>> Hi, >>> >>> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >>>> Per section 4, RFC 7301: >>>> "... The >>>> "application_layer_protocol_negotiation" ServerHello extension is >>>> intended to be definitive for the connection (until the connection is >>>> renegotiated) and is sent in plaintext to permit network elements to >>>> provide differentiated service for the connection when the TCP or UDP >>>> port number is not definitive for the application-layer protocol to >>>> be used in the connection. By placing ownership of protocol >>>> selection on the server, ALPN facilitates scenarios in which >>>> certificate selection or connection rerouting may be based on the >>>> negotiated protocol." >>>> >>>> Per my understanding, application protocol should be negotiated before >>>> cipher suite and protocol version negotiated. >>> This is not possible for HTTP/2. >>> Application protocol negotiation MUST happen *after* the TLS protocol >>> and the TLS cipher are negotiated. >> >> What do you mean by "after"? As far as TLS is concerned, all of this >> negotiation happens in one negotiation. The client proposes a list of >> ciphers and application protocols. The server chooses a cipher >> and application protocol and sends back its choices. > Currently, IIUC, the cipher selection is an iterative process where a > cipher is attempted until one is negotiated. > In this process, there is no looking at the application protocol. > > Here we're trying to find a solution for ALPN, and either we 1) look > the application protocol in this iterative process (and therefore the > SSLFunction is invoked multiple times), so that TLS protocol, cipher > (possibly the alias too) and application protocol are chosen together, > at once (for each iteration); or 2) we separate the TLS protocol and > cipher negotiation (and alias) in one step, and we perform application > protocol selection afterwards. > The latter is how Jetty's ALPN works, and that's what I mean with *after*. > For HTTP/2 it won't work to pick the application protocol before the > cipher. Either at the same time, or after. > > That is why I asked to specify how the mechanism worked. Okay. I've been looking at it from the client point of view, and as far as I understand it, all of the information is available to the client at the right time. >> The HTTP/2 RFC specifically warns against splitting this negotiation >> with the example that a client could propose a mandatory TLS 1.2 cipher, >> but which is black-listed by HTTP/2. If (internally) the server chooses that >> cipher first, >> without knowing the application protocol is going to be HTTP/2 >> then you end up with a non-compliant connection that will probably have >> to be closed for reason of insufficient security. > If the server chooses a blacklisted cipher, and then "h2" as protocol, > it's a non compliant server. > Communication of clients with compliant (and properly configured) > servers is guaranteed if the application protocol is chosen after (or > at the same time of) the cipher. > > If I understand you correctly, you are proposing to rework the > internal JDK code to perform TLS protocol, cipher, alias and > application protocol in one point, which is then possibly iterated > multiple times until a satisfactory tuple is selected ? > > I am fine with this approach too, but I guess the API will be very > different from Jetty's ALPN and this current proposal (which is fine > as well - does not have to be similar to Jetty's). > I don't know enough about the TLS implementation to say how much work it is. > > Thanks ! > Actually, I'm not proposing anything at this stage. But, I wonder if it might be simpler to just make all relevant information available to the existing negotiation API, rather than splitting it into separate calls - Michael. From simone.bordet at gmail.com Thu Jun 4 16:12:27 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Jun 2015 18:12:27 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <55707475.8060401@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> Message-ID: Hi, On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote: > On 6/4/2015 8:19 PM, Simone Bordet wrote: >> This is not possible for HTTP/2. >> Application protocol negotiation MUST happen *after* the TLS protocol >> and the TLS cipher are negotiated. >> > Why? Is it a spec of HTTP/2? It is a point I don't understand now. > Please help with more details. http://tools.ietf.org/html/rfc7540#section-9.2 You can only speak h2 if the cipher is strong enough as defined by RFC 7540. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Jun 4 16:50:03 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 00:50:03 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> Message-ID: <557081BB.5080508@oracle.com> On 6/5/2015 12:12 AM, Simone Bordet wrote: > Hi, > > On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote: >> On 6/4/2015 8:19 PM, Simone Bordet wrote: >>> This is not possible for HTTP/2. >>> Application protocol negotiation MUST happen *after* the TLS protocol >>> and the TLS cipher are negotiated. >>> >> Why? Is it a spec of HTTP/2? It is a point I don't understand now. >> Please help with more details. > > http://tools.ietf.org/html/rfc7540#section-9.2 > > You can only speak h2 if the cipher is strong enough as defined by RFC 7540. > Hm, I see your point now. But I may not agree with your ALPN "MUST happen after" protocol/cipher suite negotiation conclusion. I parse this section as, a H2 server must be strong enough(comply to RFC7540), and a H2 client must also be strong enough (comply to RFC7540). Otherwise, both side may terminated the connection, and cannot declare as complying to H2. It is not necessary for an application protocol selector to detect whether a H2 server/client comply to H2 or not. If "H2" is requested, it means that the client supports H2. Otherwise, it's a client application bug. If "H2" is selected by a selected, it means that the selected server supports H2. Otherwise, it is a selector implementation bug. If something wrong in either client or server, it is expected to terminate the connection immediately, rather than downgrade to a not-strong enough level. >From the points above, I think an application protocol selector may not need to know the negotiated protocol version and cipher suite. Thanks, Xuelei From aph at redhat.com Thu Jun 4 17:08:01 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Jun 2015 18:08:01 +0100 Subject: RSA intrinsics [Was: RFR(L): 8069539: RSA acceleration] In-Reply-To: <555708BE.8090100@redhat.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63321E33@FMSMSX112.amr.corp.intel.com> <5502E67C.8080208@oracle.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63322AB0@FMSMSX112.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63323E86@FMSMSX112.amr.corp.intel.com> <550C004D.1060501@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B633245C8@FMSMSX112.amr.corp.intel.com> <55101C52.1090506@redhat.com> <5548193E.7060803@oracle.com> <55488803.4020802@redhat.com> <554CDD48.8080500@redhat.com> <1CCF381D-1C55-4392-A905-AD8CD457980B@oracle.com> <555708BE.8090100@redhat.com> Message-ID: <557085F1.9070703@redhat.com> I'm sorry this is a rather long email, and I pray for your patience. I'm getting close to something I can put forward for review. The performance is encouraging. [ Some background: The kernel of RSA and Diffie-Hellman key exchange is Montgomery multiplication. Optimizing RSA basically comes down to optimizing Montgomery multiplication. The core of OpenJDK's RSA is BigInteger.oddModPow(). ] My Montgomery multiply routine (mostly portable C, with a small assembly-language insert) executes a 1024-bit multiply/reduce in about 2000ns; the hand-coded assembly language equivalent in OpenSSL is faster (as you'd expect) but not very much faster: about 1700ns. In other words, compiled C is only about 20% slower. Firstly, this is pretty remarkable performance by GCC (Yay! Go GCC!) and it shows I'm on the right track. It also shows that there isn't a huge amount to be gained by hand-coding Montgomery multiplication, but anybody who fancies their hand can try to improve on GCC. This is also very nice because porting it to non-x86 hardware is fairly straightforward -- certainly far easier than writing a large assembly- language routine. Here are some numbers for comparison. Today's hs-comp: sign verify sign/s verify/s rsa 512 bits 0.000133s 0.000009s 7508.5 112819.1 rsa 1024 bits 0.000667s 0.000028s 1498.6 35497.2 rsa 2048 bits 0.003867s 0.000097s 258.6 10342.7 rsa 4096 bits 0.026383s 0.000357s 37.9 2799.8 After my patch: sign verify sign/s verify/s rsa 512 bits 0.000071s 0.000005s 14127.3 204112.4 rsa 1024 bits 0.000292s 0.000013s 3424.5 74204.1 rsa 2048 bits 0.001628s 0.000045s 614.4 22399.7 rsa 4096 bits 0.010966s 0.000163s 91.2 6117.8 So, it's about twice as fast we have at present. [ Note that this comparison includes the latest "8081778: Use Intel x64 CPU instructions for RSA acceleration" patch. ] However, even after my patch OpenJDK is still somewhat slower than OpenSSL, which is: sign verify sign/s verify/s rsa 512 bits 0.000048s 0.000004s 20687.1 257399.4 rsa 1024 bits 0.000189s 0.000011s 5288.3 91711.5 rsa 2048 bits 0.001174s 0.000037s 851.7 27367.2 rsa 4096 bits 0.008475s 0.000137s 118.0 7305.4 [ I am assuming that OpenSSL represents something like the "speed of light" for RSA on x86: this is carefully hand-coded assembly language and C, hand tuned. Getting anywhere near OpenSSL is a major win. ] Here's my problem: Some of this slowdown is due to the overhead of using the JCE, but not very much. Quite a lot of it, however, is due to the fact that the scratch memory used in oddModPow() is a big-endian array of jints. I have to convert the big-endian jints into native jlongs to do the multiply on little-endian x86-64. If I do the word reversal during the multiply (i.e. keep all data in memory in little-endian form, swap words when reading and writing to memory) the performance is horrible: a 1024-bit multiply takes 3000ns, 50% longer. This perhaps isn't very surprising: if you do the word-reversal before the multiplication you have O(N) swaps, if you do it during the multiplication you have O(N^2). I have found that the best thing to do is to word reverse all the data in memory into temporary little-endian arrays and do the work on them. It's much faster, but still really is very annoying: for 1024-bit RSA the word reversal is 14% of the total runtime. It would be nice to keep all of the data in an array of jlongs for the duration of oddModPow(). Here's one idea: I could write a version of oddModPow() which is guaranteed never to use the Java version of the Montgomery multiply. This would use a JNI method which calls the native Montgomery multiply routine, guaranteeing that that we always use that native routine, even from the interpreter and C1. Then I could keep all the internal state in native word order, and all this word-swapping would just go away. This would have the additional benefit that it would be faster when using the interpreter and C1. So, we'd have two versions of oddModPow() in BigInteger, and switch between them depending on whether the platform had support for a native Montgomery multiplication. The downside of having two versions of oddModPow() would, of course, be some code duplication. Or am I just making too much fuss about this? Maybe I should be happy with what I've got. Thank you for reading this far, Andrew. From simone.bordet at gmail.com Thu Jun 4 21:30:22 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Jun 2015 23:30:22 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <557081BB.5080508@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> Message-ID: Hi, On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote: > Hm, I see your point now. But I may not agree with your ALPN "MUST > happen after" protocol/cipher suite negotiation conclusion. > > I parse this section as, a H2 server must be strong enough(comply to > RFC7540), and a H2 client must also be strong enough (comply to > RFC7540). Otherwise, both side may terminated the connection, and > cannot declare as complying to H2. It is not necessary for an > application protocol selector to detect whether a H2 server/client > comply to H2 or not. > > If "H2" is requested, it means that the client supports H2. Otherwise, > it's a client application bug. Not that simple, see below. > If "H2" is selected by a selected, it > means that the selected server supports H2. Otherwise, it is a selector > implementation bug. If something wrong in either client or server, it > is expected to terminate the connection immediately, rather than > downgrade to a not-strong enough level. > > From the points above, I think an application protocol selector may not > need to know the negotiated protocol version and cipher suite. No. The client may send ciphers that are valid for http/1.1 (but invalid for h2), along with ciphers that are good for h2 (as well as http/1.1 of course), plus the list of protocols it supports. The client has no idea what the server supports. When the server sees that the client supports h2, it MUST pick a cipher that is valid for h2. Alternatively, the ciphers on the server are sorted so that those valid for h2 have higher priority (they are attempted before all the others), so that there is a high chance that a h2 valid cipher is chosen (but no guarantee) before choosing the application protocol. When the application protocol selector callback is invoked, it can only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback to http/1.1. With your reasoning, the client can send [h2_invalid_cipher, h2_valid_cipher], the server may pick h2_invalid_cipher, then the application protocol selector is invoked, which will only look at the protocols, pick h2 since it's supported by client and server, and now you have an invalid connection: the h2 protocol with h2_invalid_cipher. We have been through these issues for months in the RFC 7540 expert group, and the outcome is that protocol selection, for h2, depends on the cipher. We have also been through a number of scenarios where both the client and the server send h2 valid ciphers, but their intersection is empty (this may happen when a very old client talks to a very new server, think TLS 1.2 vs TLS 1.4, or viceversa). Same outcome: to pick h2 you MUST have a h2 valid cipher in common between client and server, so application protocol selection, for h2, depends on the cipher. A bit of warning here: we are designing an API for ALPN, not for HTTP/2. The ALPN API should be flexible enough to implement *at least* HTTP/2, possibly even more complex scenarios (for example alias selection), but IMHO it should not be tied to HTTP/2. Again, I see 2 cases: either the JDK implementation picks the TLS protocol, the cipher and the alias like it does now, and then invokes the "callback" to pick the application protocol (current Jetty ALPN behavior), or the implementation must be reviewed to perform TLS protocol, cipher, alias and application protocol selection at once, with a "callback" that will be invoked possibly multiple times until it can find the right tuple to return. The latter would be the optimal solution, the former has certainly working implementations. Hope this clarified. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From valerie.peng at oracle.com Thu Jun 4 21:58:57 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 04 Jun 2015 14:58:57 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <556F38F4.4070109@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> Message-ID: <5570CA21.7070309@oracle.com> Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: > > Correct, if the makefile related changes are removed then no need for > build team to review 7191662 webrev anymore. > There are other discussions ongoing and we should be able to reach a > decision in a day or two. > Will update the list again. > Thanks, > Valerie > > On 06/01/15 16:39, Magnus Ihse Bursie wrote: >> On 2015-05-29 00:10, Valerie Peng wrote: >>> >>> Please find comments in line... >>> >>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>> Valerie, >>>> >>>> Did you see my comment yesterday? >>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>> >>> Yes, we exchanged emails after this above one. I will follow up your >>> latest one later today. >>> >>>> >>>> Since you have reverted the java.security to keep the classname, to >>>> avoid causing merge conflict to jimage refresh, let?s remove the >>>> META-INF files in the first push and the build change. >>>> >>>> The security providers will be loaded via the fallback mechanism >>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>> ProviderLoader.load method to take the provider name instead of >>>> classname. >>> Sure, I can remove the META-INF files so the providers are loaded >>> through the legacyLoad(). >>> Hmm, the ProviderLoader.load() method is used by java.security file >>> provider loading. Since the current list still uses class name, it >>> should take class name when checking for matches while iterating >>> through the list returned by ServiceLoader. >>> This way, when changes are sync'ed into Jake, no extra change >>> required and the providers will be loaded through >>> ProviderLoader.load() automatically with the current list. >>> >>>> I?ll file a bug to follow up to change java.security to list the >>>> provider name. This will wait after the jimage refresh goes into >>>> jdk9/dev >>> Ok. >>> Thanks, >>> Valerie >> >> I'm not sure I followed completely here were this landed. Does this >> mean that there's currently no need for a build system code review on >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a >> new webrev will be posted instead? >> >> /Magnus >> >> >> >>>> . >>>> >>>> Mandy >>>> >>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>> Peng wrote: >>>>> >>>>> Hi, build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> The rest of source code changes are reviewed by my team already. >>>>> Thanks, >>>>> Valerie >>>>> (Java Security Team) >> > From bradford.wetmore at oracle.com Fri Jun 5 00:37:19 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 04 Jun 2015 17:37:19 -0700 Subject: TLS ALPN Proposal v2 In-Reply-To: <556E9D5C.5040106@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> Message-ID: <5570EF3F.7070202@oracle.com> On 6/2/2015 11:23 PM, Xuelei Fan wrote: > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java > ================================================================= > > List getReceivedApplicationProtocols() > ---------------------------------------------- > C1. It might be useful to know the client requested application > protocols in some circumstance. Better to set the application protocols > in client side either. For ALPN, the client supplies the list, the server chooses. For NPN, the server supplies the list, the client chooses. So it's a list of received (requested) protocols. I've changed it for now, not a big deal to me. > I'd like to use: > > - * Gets the application protocol value(s) received from the peer > - * for this connection. > + * Gets a {@link List} of requested application protocol value(s) > + * for this connection. I've never seen a link inside an opening sentence. I have seen @code, but there's only 6 in the entire java namespace. The > - public List getReceivedApplicationProtocols() { > + public List getRequesedApplicationProtocols() { I'll assume that was supposed to be requested. :) > C2. The return value would better to be immutable, and better to > describe the preference per RFC 7301. Maybe looks like: > - * @return the non-null list of application protocol names > + * @return the non-null immutable list of application protocol > + * names, in descending order of preference. The returned > + * list may be empty if no application protocols were > + * requested. Done. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java > ============================================================ > > List getApplicationProtocols() > -------------------------------------- > C3. Better to indicate explicitly that this method only apply to client > mode. See above. > C4. The method description is not instinctive enough for an application > developer. Can we use words to indicate the purpose of the setting? > For example: > - * Gets the list of application-level protocol names that could > - * be sent to the SSL/TLS peer. > + * Gets the {@link List} of application layer protocol names that > + * can be negotiated over SSL/TLS/DTLS protocols. Changed, except for the @link. > C5. Prefer to use immutable return value: > - * @return a non-null list of application protocol names. > + * @return a non-null immutable list of application protocol names. Changed. > C6. Nice to have a link for the standard protocol names. I wasn't planning on having a list of standard protocol names. See below. > void setApplicationProtocols(List protocols) > ---------------------------------------------------- > C7. see C3. > C8. see C4. Changed. > s/getApplicationProtocolSelector() > ---------------------------------- > C9. The use of SSLFunction make the implementation of > protocol selector and JSSE provider implementation complicated. > > From the spec, looks like the selector may want to know address/ports, > SSL protocol versions or the negotiated cipher suit. As would require > that before use this selector, the handshaking must negotiate the > protocol version and the cipher suite. That's a specific JSSE > implementation requirement. It does not sound like a reasonable behavior. > > The implement of the selector is not straightforward, I think. > > Per section 4, RFC 7301: > "... The > "application_layer_protocol_negotiation" ServerHello extension is > intended to be definitive for the connection (until the connection is > renegotiated) and is sent in plaintext to permit network elements to > provide differentiated service for the connection when the TCP or UDP > port number is not definitive for the application-layer protocol to > be used in the connection. By placing ownership of protocol > selection on the server, ALPN facilitates scenarios in which > certificate selection or connection rerouting may be based on the > negotiated protocol." > > Per my understanding, application protocol should be negotiated before > cipher suite and protocol version negotiated. And the connection may be > rerouted (even to different machines) for further operation. The > requested application protocols list should be the only information for > the selection of a suitable application protocol. > > Based on that, I think it is more simple to use Simone's proposal: > > @FunctionalInterface > interface ApplicationProtocolSelector > { > String select(List protocols) throws SSLException; > } > > Hence, no need for a SSLBase any more. There's been a lot of discussion this morning, I'll return to this later when I've had a chance to parse it. > public static final String AP_HTTP_1_1 = "http/1.1"; > public static final String AP_H2 = "h2"; > ---------------------------------------- > C10. I understand why the constants are defined here. However, usually, > we don't define standard names in JSSE APIs. Instead, we normally use > Oracle standard names documentation. This is not really a Standard Name in our normal sense/usage. Usually it's a mapping from a name string to some type of value (e.g. TLSv1 -> 0x0301, "SSL_RSA_WITH_3DES_EDE_CBC_SHA" -> 0x000a, "SHA1withRSA" -> 1.2.840.113549.1.1.5. In this case, it's the actual value, and will depends on the decoding. > src/java.base/share/classes/javax/net/ssl/SSLSession.java > ========================================================= > String getCipherSuite() > ----------------------- > Pretty hard to use this method with the new specification. It's not a > necessary update, see #C9. I'll come back to this as per above. Brad > Hope it helps! > > Xuelei > > On 6/3/2015 8:56 AM, Bradford Wetmore wrote: >> Hi, >> >> I have just posted the second iteration of the ALPN proposal which >> hopefully addresses all of the comments raised here. It is in javadoc >> format, but things can certainly be adjusted: >> >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/ >> >> Please see the archive [1] for previous design discussion. I will be >> writing up usage examples in the next few days. >> >> The significant changes: >> >> ExtendedSSLSession >> public List getReceivedApplicationProtocols() { >> >> This will allow applications to examine which protocol names were >> sent. >> >> SSLParameters >> mentions both ALPN/NPN as possible protocols. I removed the >> discussion about "server" and "client" since ALPN/NPN essentially >> reverse the roles. >> >> mentions "appropriate character sets" for String-byte[] conversions >> such as UTF-8 for ALPN. >> >> The application protocol selector is now a @FunctionalInterface >> (i.e. lambda-ready) called SSLFunction. It is to throw an >> SSLException if no values are supported, or null if you want to >> treat as an unknown extension. >> >> Defined constants for HTTP/1.1 and HTTP/2. >> >> SSLSession >> >> Called out that getHandshakeSession's ciphersuite may vary until >> selected. >> >> SSLBase >> >> A new marker interface that SSLEngine/SSLSocket will implement. >> This will allow for a single SSLFunction instead of having >> SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require >> that the lambda do a instanceof, unless we were to move the common >> Socket/Engine APIs into this class. >> >> Thanks, >> >> Brad >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012183.html > From xuelei.fan at oracle.com Fri Jun 5 04:11:38 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 12:11:38 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> Message-ID: <5571217A.1070501@oracle.com> Hi, See inlines, please. On 6/5/2015 5:30 AM, Simone Bordet wrote: > Hi, > > On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote: >> Hm, I see your point now. But I may not agree with your ALPN "MUST >> happen after" protocol/cipher suite negotiation conclusion. >> >> I parse this section as, a H2 server must be strong enough(comply to >> RFC7540), and a H2 client must also be strong enough (comply to >> RFC7540). Otherwise, both side may terminated the connection, and >> cannot declare as complying to H2. It is not necessary for an >> application protocol selector to detect whether a H2 server/client >> comply to H2 or not. >> >> If "H2" is requested, it means that the client supports H2. Otherwise, >> it's a client application bug. > > Not that simple, see below. > >> If "H2" is selected by a selected, it >> means that the selected server supports H2. Otherwise, it is a selector >> implementation bug. If something wrong in either client or server, it >> is expected to terminate the connection immediately, rather than >> downgrade to a not-strong enough level. >> >> From the points above, I think an application protocol selector may not >> need to know the negotiated protocol version and cipher suite. > > No. > > The client may send ciphers that are valid for http/1.1 (but invalid > for h2), along with ciphers that are good for h2 (as well as http/1.1 > of course), plus the list of protocols it supports. > The client has no idea what the server supports. > I think it should be true that if a client requests h2, the client MUST support H2 and the requested cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in client side. > When the server sees that the client supports h2, it MUST pick a > cipher that is valid for h2. > Alternatively, the ciphers on the server are sorted so that those > valid for h2 have higher priority (they are attempted before all the > others), so that there is a high chance that a h2 valid cipher is > chosen (but no guarantee) before choosing the application protocol. > When the application protocol selector callback is invoked, it can > only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback > to http/1.1. > I think it should be true that if a server can negotiate h2, the server MUST support H2 and the enabled cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in server side. It's instinctive that if a server support h2, and then the application protocol selector would select h2. If the server declare to support h2, but no suitable cipher suites, it may be a server bug. The connection should be terminated rather than downgrade to HTTP/1.1, I think. Is it possible that client only request h2_valid_cipher_a, but server only support h2_valid_cipher_b, and as would result in that there is no common cipher suites between client and server for H2? It is possible, surely. Should the connection be terminated, or fall-back to HTTP/1.1? I think connection should be terminated immediately, rather than fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST be supported in both client and server. If there is no common cipher suites between client and server for H2, it is actually a bad deployments, and the connection should be terminated rather than fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. > With your reasoning, the client can send [h2_invalid_cipher, > h2_valid_cipher], the server may pick h2_invalid_cipher, then the > application protocol selector is invoked, which will only look at the > protocols, pick h2 since it's supported by client and server, and now > you have an invalid connection: the h2 protocol with > h2_invalid_cipher. > That's an interesting case. The question actually is: between requested application protocols and cipher suites, which preference should be respected at first. Because it is a application requirement that a certain cipher suite is not suitable to H2, I think requested application protocols should be respected at first. My scenarios look like: 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 application protocol. 2. server selects h2 (we need an API for the selection). 3. server selects h2_valid_cipher because of h2 is selected previously (may need an API for the selection). In #1, if there is no h2_valid_cipher requested, it is a bug in client side. In #3, if there is no h2_valid_cipher that can be negotiated, it is a bug in server side, or the client does not enabled the mandatory cipher suite (a bug in client). > We have been through these issues for months in the RFC 7540 expert > group, and the outcome is that protocol selection, for h2, depends on > the cipher. > We have also been through a number of scenarios where both the client > and the server send h2 valid ciphers, but their intersection is empty > (this may happen when a very old client talks to a very new server, > think TLS 1.2 vs TLS 1.4, or viceversa). > Same outcome: to pick h2 you MUST have a h2 valid cipher in common > between client and server, so application protocol selection, for h2, > depends on the cipher. > I still cannot understand the outcome. I think, if there is no h2 valid cipher in common, the connection should be terminated as there is a bug in client or server side (see above). I'm not familiar with HTTP/2 protocol, can you share more scenarios that application protocol selection depends on the cipher? > A bit of warning here: we are designing an API for ALPN, not for HTTP/2. > The ALPN API should be flexible enough to implement *at least* HTTP/2, > possibly even more complex scenarios (for example alias selection), > but IMHO it should not be tied to HTTP/2. > Yes. That's what I intended to do now. It's very bad if application protocol selection depends on the negotiation of TLS protocols, cipher suites, or other handshake attributes, or other Chicken/Eggs dependence. As would make the JSSE provider hard to be implemented, and the API hard to be used. That's what I want to avoid in JSSE layer. > Again, I see 2 cases: either the JDK implementation picks the TLS > protocol, the cipher and the alias like it does now, and then invokes > the "callback" to pick the application protocol (current Jetty ALPN > behavior), or the implementation must be reviewed to perform TLS > protocol, cipher, alias and application protocol selection at once, > with a "callback" that will be invoked possibly multiple times until > it can find the right tuple to return. > The former has a drawback that the cipher may not suitable for the application protocol. It's application protocol define with cipher suite is suitable (RFC7540), not cipher suite define which application protocol is suitable. So application protocol should be selected at first, and let the specific application protocol determines the negotiable cipher suite. The latter made the TLS implementation pretty complicated. It is even not doable actually in general. Too much attributes need to be considered if more handshake properties are involved, such as certificate, key parameters, etc. See also my previous mail about the rerouting requirement. I think application-layer protocol negotiation should happen before the actually general-handshaking (TLS protocol, cipher suite, general extension negotiation). For any incoming ClientHello message, the scenarios in server side is as simple as: 1. select the right application-layer protocols. 2. do the actual general handshaking. If something failed, terminate the connection. I'm not familiar with HTTP/2, I'm open to hear more case why above scenarios does not work. > The latter would be the optimal solution, the former has certainly > working implementations. > > Hope this clarified. > > Thanks ! > Thank you very much for the discussion of the potential issue. It's an effective way for us to understand what's the best option and what's the actual requirement in the industry. Thanks, Xuelei From xuelei.fan at oracle.com Fri Jun 5 04:16:51 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 12:16:51 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: <5570EF3F.7070202@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <5570EF3F.7070202@oracle.com> Message-ID: <557122B3.5050303@oracle.com> On 6/5/2015 8:37 AM, Bradford Wetmore wrote: >> I'd like to use: >> >> - * Gets the application protocol value(s) received from the peer >> - * for this connection. >> + * Gets a {@link List} of requested application protocol value(s) >> + * for this connection. > > I've never seen a link inside an opening sentence. I have seen @code, > but there's only 6 in the entire java namespace. Better to use @code. Xuelei From erik.joelsson at oracle.com Fri Jun 5 07:21:22 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Jun 2015 09:21:22 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <5570CA21.7070309@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> Message-ID: <55714DF2.7090100@oracle.com> Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. /Erik On 2015-06-04 23:58, Valerie Peng wrote: > Build experts, > > Can you please review the make file related change, i.e. the new file > make/gensrc/Gensrc-java.naming.gmk, in the following webrev: > http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 > > This is for merging the java.security.Provider file from various > providers and use the (merged) result for the final image build. > > Thanks, > Valerie > > On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >> >> Correct, if the makefile related changes are removed then no need for >> build team to review 7191662 webrev anymore. >> There are other discussions ongoing and we should be able to reach a >> decision in a day or two. >> Will update the list again. >> Thanks, >> Valerie >> >> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>> On 2015-05-29 00:10, Valerie Peng wrote: >>>> >>>> Please find comments in line... >>>> >>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>> Valerie, >>>>> >>>>> Did you see my comment yesterday? >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>> >>>> Yes, we exchanged emails after this above one. I will follow up >>>> your latest one later today. >>>> >>>>> >>>>> Since you have reverted the java.security to keep the classname, >>>>> to avoid causing merge conflict to jimage refresh, let?s remove >>>>> the META-INF files in the first push and the build change. >>>>> >>>>> The security providers will be loaded via the fallback mechanism >>>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>>> ProviderLoader.load method to take the provider name instead of >>>>> classname. >>>> Sure, I can remove the META-INF files so the providers are loaded >>>> through the legacyLoad(). >>>> Hmm, the ProviderLoader.load() method is used by java.security file >>>> provider loading. Since the current list still uses class name, it >>>> should take class name when checking for matches while iterating >>>> through the list returned by ServiceLoader. >>>> This way, when changes are sync'ed into Jake, no extra change >>>> required and the providers will be loaded through >>>> ProviderLoader.load() automatically with the current list. >>>> >>>>> I?ll file a bug to follow up to change java.security to list the >>>>> provider name. This will wait after the jimage refresh goes into >>>>> jdk9/dev >>>> Ok. >>>> Thanks, >>>> Valerie >>> >>> I'm not sure I followed completely here were this landed. Does this >>> mean that there's currently no need for a build system code review >>> on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that >>> a new webrev will be posted instead? >>> >>> /Magnus >>> >>> >>> >>>>> . >>>>> >>>>> Mandy >>>>> >>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>> Peng wrote: >>>>>> >>>>>> Hi, build experts, >>>>>> >>>>>> Can you please review the make file related change, i.e. the new >>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>> >>>>>> This is for merging the java.security.Provider file from various >>>>>> providers and use the (merged) result for the final image build. >>>>>> >>>>>> The rest of source code changes are reviewed by my team already. >>>>>> Thanks, >>>>>> Valerie >>>>>> (Java Security Team) >>> >> From simone.bordet at gmail.com Fri Jun 5 08:05:07 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 5 Jun 2015 10:05:07 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <5571217A.1070501@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> Message-ID: Hi, On Fri, Jun 5, 2015 at 6:11 AM, Xuelei Fan wrote: > I think it should be true that if a server can negotiate h2, the server > MUST support H2 and the enabled cipher suites MUST contains at least one > H2 required cipher suite. Otherwise, it's bug in server side. > > It's instinctive that if a server support h2, and then the application > protocol selector would select h2. If the server declare to support h2, > but no suitable cipher suites, it may be a server bug. The connection > should be terminated rather than downgrade to HTTP/1.1, I think. The server may support h2, but there is no valid h2 cipher in common with the client, so it's not a server bug. In that case, client and server cannot speak h2, but nothing forbids them to speak http/1.1. It would be really bad for the user experience if both client and server could speak http/1.1, but they don't just because they can't speak h2. They would appear like spoiled children :) The point of ALPN is to *negotiate* a protocol, not to give up on the first failure. > Is it possible that client only request h2_valid_cipher_a, but server > only support h2_valid_cipher_b, and as would result in that there is no > common cipher suites between client and server for H2? It is possible, > surely. Should the connection be terminated, or fall-back to HTTP/1.1? > I think connection should be terminated immediately, rather than > fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is > an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST > be supported in both client and server. If there is no common cipher > suites between client and server for H2, it is actually a bad > deployments, and the connection should be terminated rather than > fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. That is not what the 7540 expert group thinks, certainly not what browsers do, and certainly not what servers do. The behavior is to speak http/1.1 (or the next protocol that fits). > That's an interesting case. The question actually is: between requested > application protocols and cipher suites, which preference should be > respected at first. Because it is a application requirement that a > certain cipher suite is not suitable to H2, I think requested > application protocols should be respected at first. > > My scenarios look like: > 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 > application protocol. > 2. server selects h2 (we need an API for the selection). > 3. server selects h2_valid_cipher because of h2 is selected previously > (may need an API for the selection). Does not work. How do you know that server has h2_valid_cipher available ? If it does not, you have picked h2, and an invalid cipher (breaks 7540), or you terminate the connection while instead you could speak http/1.1. > In #1, if there is no h2_valid_cipher requested, it is a bug in client side. > In #3, if there is no h2_valid_cipher that can be negotiated, it is a > bug in server side, or the client does not enabled the mandatory cipher > suite (a bug in client). Does not work. The client may be using TLS 1.4, where that mandatory cipher suite (it's mandatory only for TLS 1.2 deployments) has been removed because insecure. There is no bug on either side, just no cipher in common. > I still cannot understand the outcome. I think, if there is no h2 valid > cipher in common, the connection should be terminated as there is a bug > in client or server side (see above). No, see above. > I'm not familiar with HTTP/2 protocol, can you share more scenarios that > application protocol selection depends on the cipher? It is evident. In all examples, yours and mines, every time we pick "h2" we have to look at the ciphers to see if it is a valid one for h2 or not. You cannot pick "h2" without looking at the cipher so there is an evident dependency. If it's not the right cipher, you say "close the connection", while the implemented behavior of browsers and servers is to fallback to http/1.1. Either case, you have looked at the cipher and taken a decision based on the tuple (app_proto, cipher). In contrast, you can pick "http/1.1" and *any* cipher you want, you don't need to look at the cipher. >> A bit of warning here: we are designing an API for ALPN, not for HTTP/2. >> The ALPN API should be flexible enough to implement *at least* HTTP/2, >> possibly even more complex scenarios (for example alias selection), >> but IMHO it should not be tied to HTTP/2. >> > Yes. That's what I intended to do now. It's very bad if application > protocol selection depends on the negotiation of TLS protocols, cipher > suites, or other handshake attributes, or other Chicken/Eggs dependence. > As would make the JSSE provider hard to be implemented, and the API hard > to be used. That's what I want to avoid in JSSE layer. > >> Again, I see 2 cases: either the JDK implementation picks the TLS >> protocol, the cipher and the alias like it does now, and then invokes >> the "callback" to pick the application protocol (current Jetty ALPN >> behavior), or the implementation must be reviewed to perform TLS >> protocol, cipher, alias and application protocol selection at once, >> with a "callback" that will be invoked possibly multiple times until >> it can find the right tuple to return. >> > The former has a drawback that the cipher may not suitable for the > application protocol. It's application protocol define with cipher > suite is suitable (RFC7540), not cipher suite define which application > protocol is suitable. So application protocol should be selected at > first, and let the specific application protocol determines the > negotiable cipher suite. That forbids any form of fallback to http/1.1, and it's not what it's intended by 7540, nor what has been implemented by browsers and servers. IMHO would be very bad to kill the whole communication between a client and a server just because they can't speak h2. The whole world speaks http/1.1 no problem, so why now they could not anymore ? I understand h2 is preferred, but that should not stop a browser and a server to use http/1.1 if they can't use h2. > The latter made the TLS implementation pretty complicated. It is even > not doable actually in general. Too much attributes need to be > considered if more handshake properties are involved, such as > certificate, key parameters, etc. I am not sure about the impossibility. IIUC, there are 4 parameters that needs to be negotiated: TLS protocol, cipher, alias and application protocol. The data in the ClientHello and the server configuration certainly allow for such a tuple to be generated, so it's not impossible. Sure, it may be really hard on the implementation. The current Jetty ALPN support has taken the shortcut that application protocol is negotiated after cipher selection. Sure, Jetty ALPN can't pick the protocol based on the alias for example. And it has to sort the ciphers in a HTTP/2 specific way to influence cipher selection to prefer those that would be good for HTTP/2. It's not perfect but works. > See also my previous mail about the rerouting requirement. Which I am not sure I understand. If the router decides the application protocol, it must have the correct logic, and the server can't choose anything. If the router routes to a server thinking that it would speak h2, but then the server does not negotiate h2, that means the router has no power in deciding anything. I am sure I am missing something from your example ? We have deployed a rerouting using HAProxy and Jetty in our own website a while back, using spdy (that has no cipher requirements). If spdy was negotiated we routed the traffic to one connector, otherwise to another connector. However, HAProxy was offloading TLS and was speaking clear text to the backend servers. Is that your scenario ? > I think application-layer protocol negotiation should happen before the > actually general-handshaking (TLS protocol, cipher suite, general > extension negotiation). For any incoming ClientHello message, the > scenarios in server side is as simple as: > 1. select the right application-layer protocols. > 2. do the actual general handshaking. If something failed, terminate > the connection. Nope. Imagine a server that overnight added h2 support. Yesterday a browser could open a page and browse the site over http/1.1. Today, the browser cannot even connect to the website (because you don't allow fallback). But if you use Netscape 4, you can actually connect and browse the site as before :) Imagine how much the adoption of h2 would be popular if that was the case. Certainly the 7540 expert group did not want this. > I'm not familiar with HTTP/2, I'm open to hear more case why above > scenarios does not work. See above. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From michael.x.mcmahon at oracle.com Fri Jun 5 09:31:42 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 05 Jun 2015 10:31:42 +0100 Subject: TLS ALPN Proposal v2 In-Reply-To: <5571217A.1070501@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> Message-ID: <55716C7E.9080908@oracle.com> I've just noticed the SSLParameters.setUseCipherSuitesOrder() method. I guess this can be used to enforce a higher priority for the h2 compatible ciphers on the server side. On the new API, I'm not sure about the SSLBase, SSLFunction construct either. I don't think it is very clear, and if its purpose is just to allow use of lambdas, then I think the original approach was better. Michael. On 05/06/15 05:11, Xuelei Fan wrote: > Hi, > > See inlines, please. > > On 6/5/2015 5:30 AM, Simone Bordet wrote: >> Hi, >> >> On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote: >>> Hm, I see your point now. But I may not agree with your ALPN "MUST >>> happen after" protocol/cipher suite negotiation conclusion. >>> >>> I parse this section as, a H2 server must be strong enough(comply to >>> RFC7540), and a H2 client must also be strong enough (comply to >>> RFC7540). Otherwise, both side may terminated the connection, and >>> cannot declare as complying to H2. It is not necessary for an >>> application protocol selector to detect whether a H2 server/client >>> comply to H2 or not. >>> >>> If "H2" is requested, it means that the client supports H2. Otherwise, >>> it's a client application bug. >> Not that simple, see below. >> >>> If "H2" is selected by a selected, it >>> means that the selected server supports H2. Otherwise, it is a selector >>> implementation bug. If something wrong in either client or server, it >>> is expected to terminate the connection immediately, rather than >>> downgrade to a not-strong enough level. >>> >>> From the points above, I think an application protocol selector may not >>> need to know the negotiated protocol version and cipher suite. >> No. >> >> The client may send ciphers that are valid for http/1.1 (but invalid >> for h2), along with ciphers that are good for h2 (as well as http/1.1 >> of course), plus the list of protocols it supports. >> The client has no idea what the server supports. >> > I think it should be true that if a client requests h2, the client MUST > support H2 and the requested cipher suites MUST contains at least one H2 > required cipher suite. Otherwise, it's bug in client side. > >> When the server sees that the client supports h2, it MUST pick a >> cipher that is valid for h2. >> Alternatively, the ciphers on the server are sorted so that those >> valid for h2 have higher priority (they are attempted before all the >> others), so that there is a high chance that a h2 valid cipher is >> chosen (but no guarantee) before choosing the application protocol. >> When the application protocol selector callback is invoked, it can >> only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback >> to http/1.1. >> > I think it should be true that if a server can negotiate h2, the server > MUST support H2 and the enabled cipher suites MUST contains at least one > H2 required cipher suite. Otherwise, it's bug in server side. > > It's instinctive that if a server support h2, and then the application > protocol selector would select h2. If the server declare to support h2, > but no suitable cipher suites, it may be a server bug. The connection > should be terminated rather than downgrade to HTTP/1.1, I think. > > Is it possible that client only request h2_valid_cipher_a, but server > only support h2_valid_cipher_b, and as would result in that there is no > common cipher suites between client and server for H2? It is possible, > surely. Should the connection be terminated, or fall-back to HTTP/1.1? > I think connection should be terminated immediately, rather than > fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is > an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST > be supported in both client and server. If there is no common cipher > suites between client and server for H2, it is actually a bad > deployments, and the connection should be terminated rather than > fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. > >> With your reasoning, the client can send [h2_invalid_cipher, >> h2_valid_cipher], the server may pick h2_invalid_cipher, then the >> application protocol selector is invoked, which will only look at the >> protocols, pick h2 since it's supported by client and server, and now >> you have an invalid connection: the h2 protocol with >> h2_invalid_cipher. >> > That's an interesting case. The question actually is: between requested > application protocols and cipher suites, which preference should be > respected at first. Because it is a application requirement that a > certain cipher suite is not suitable to H2, I think requested > application protocols should be respected at first. > > My scenarios look like: > 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 > application protocol. > 2. server selects h2 (we need an API for the selection). > 3. server selects h2_valid_cipher because of h2 is selected previously > (may need an API for the selection). > > In #1, if there is no h2_valid_cipher requested, it is a bug in client side. > In #3, if there is no h2_valid_cipher that can be negotiated, it is a > bug in server side, or the client does not enabled the mandatory cipher > suite (a bug in client). > >> We have been through these issues for months in the RFC 7540 expert >> group, and the outcome is that protocol selection, for h2, depends on >> the cipher. >> We have also been through a number of scenarios where both the client >> and the server send h2 valid ciphers, but their intersection is empty >> (this may happen when a very old client talks to a very new server, >> think TLS 1.2 vs TLS 1.4, or viceversa). >> Same outcome: to pick h2 you MUST have a h2 valid cipher in common >> between client and server, so application protocol selection, for h2, >> depends on the cipher. >> > I still cannot understand the outcome. I think, if there is no h2 valid > cipher in common, the connection should be terminated as there is a bug > in client or server side (see above). > > I'm not familiar with HTTP/2 protocol, can you share more scenarios that > application protocol selection depends on the cipher? > >> A bit of warning here: we are designing an API for ALPN, not for HTTP/2. >> The ALPN API should be flexible enough to implement *at least* HTTP/2, >> possibly even more complex scenarios (for example alias selection), >> but IMHO it should not be tied to HTTP/2. >> > Yes. That's what I intended to do now. It's very bad if application > protocol selection depends on the negotiation of TLS protocols, cipher > suites, or other handshake attributes, or other Chicken/Eggs dependence. > As would make the JSSE provider hard to be implemented, and the API hard > to be used. That's what I want to avoid in JSSE layer. > >> Again, I see 2 cases: either the JDK implementation picks the TLS >> protocol, the cipher and the alias like it does now, and then invokes >> the "callback" to pick the application protocol (current Jetty ALPN >> behavior), or the implementation must be reviewed to perform TLS >> protocol, cipher, alias and application protocol selection at once, >> with a "callback" that will be invoked possibly multiple times until >> it can find the right tuple to return. >> > The former has a drawback that the cipher may not suitable for the > application protocol. It's application protocol define with cipher > suite is suitable (RFC7540), not cipher suite define which application > protocol is suitable. So application protocol should be selected at > first, and let the specific application protocol determines the > negotiable cipher suite. > > The latter made the TLS implementation pretty complicated. It is even > not doable actually in general. Too much attributes need to be > considered if more handshake properties are involved, such as > certificate, key parameters, etc. > > See also my previous mail about the rerouting requirement. > > I think application-layer protocol negotiation should happen before the > actually general-handshaking (TLS protocol, cipher suite, general > extension negotiation). For any incoming ClientHello message, the > scenarios in server side is as simple as: > 1. select the right application-layer protocols. > 2. do the actual general handshaking. If something failed, terminate > the connection. > > I'm not familiar with HTTP/2, I'm open to hear more case why above > scenarios does not work. > >> The latter would be the optimal solution, the former has certainly >> working implementations. >> >> Hope this clarified. >> >> Thanks ! >> > Thank you very much for the discussion of the potential issue. It's an > effective way for us to understand what's the best option and what's the > actual requirement in the industry. > > Thanks, > Xuelei > From sean.coffey at oracle.com Fri Jun 5 10:21:22 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Jun 2015 11:21:22 +0100 Subject: RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC Message-ID: <55717822.5090806@oracle.com> Looking to resolve a recently reported issue where the P11ECKeyFactory class has too much dependence on the SunEC provider. With some reshuffling and creation of a new P11ECUtil class, I was able to remove the call for lookup of SunEC Provider. The test picks up the regression when running with the SunPKCS11-NSS provider. bug report : https://bugs.openjdk.java.net/browse/JDK-8080102 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ -- Regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jun 5 12:36:25 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 20:36:25 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> Message-ID: <557197C9.5010407@oracle.com> See more inlines, please. Please help on one question I'm not sure of. Per HTTP/2 specification, Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 connection? I did not find the answer from RFC 7540. In TLS, if client requests to negotiate TLS v1.2, and server supports TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not suitable cipher suite to negotiate TLS 1.2, the connection would be terminated immediately. I'm not sure what's the spec for HTTP/2, HTTP/1.1 and HTTP/1.0. On 6/5/2015 4:05 PM, Simone Bordet wrote: > Hi, > > On Fri, Jun 5, 2015 at 6:11 AM, Xuelei Fan wrote: >> I think it should be true that if a server can negotiate h2, the server >> MUST support H2 and the enabled cipher suites MUST contains at least one >> H2 required cipher suite. Otherwise, it's bug in server side. >> >> It's instinctive that if a server support h2, and then the application >> protocol selector would select h2. If the server declare to support h2, >> but no suitable cipher suites, it may be a server bug. The connection >> should be terminated rather than downgrade to HTTP/1.1, I think. > > The server may support h2, but there is no valid h2 cipher in common > with the client, so it's not a server bug. Per RFC 7540, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory cipher suite for H2. The case is not expected that there is no cipher in common. It's a fatal error if there is no cipher in common. > In that case, client and server cannot speak h2, but nothing forbids > them to speak http/1.1. > It would be really bad for the user experience if both client and > server could speak http/1.1, but they don't just because they can't > speak h2. > They would appear like spoiled children :) > > The point of ALPN is to *negotiate* a protocol, not to give up on the > first failure. > I cannot agree, ALPN is not a mechanism to tolerant incorrect protocol implementation. If H2 is bad implemented or bad deployed, terminate the connection, rather than fallback to HTTP/1.1 is a better and safer user experience. >> Is it possible that client only request h2_valid_cipher_a, but server >> only support h2_valid_cipher_b, and as would result in that there is no >> common cipher suites between client and server for H2? It is possible, >> surely. Should the connection be terminated, or fall-back to HTTP/1.1? >> I think connection should be terminated immediately, rather than >> fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is >> an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST >> be supported in both client and server. If there is no common cipher >> suites between client and server for H2, it is actually a bad >> deployments, and the connection should be terminated rather than >> fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. > > That is not what the 7540 expert group thinks, certainly not what > browsers do, and certainly not what servers do. > The behavior is to speak http/1.1 (or the next protocol that fits). > Hm, that what I want to know. Do you mean that RFC 7540 expect a H2 server fall-back to HTTP/1.1 from HTTP/2 request? See also my question in the beginning. Per my understanding, if server does not support H2, downgrade to use HTTP/1.1 is allowed. But if the server supports H2, is it still allowed to use HTTP/1.1? That may be the key for our discussion. >> That's an interesting case. The question actually is: between requested >> application protocols and cipher suites, which preference should be >> respected at first. Because it is a application requirement that a >> certain cipher suite is not suitable to H2, I think requested >> application protocols should be respected at first. >> >> My scenarios look like: >> 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 >> application protocol. >> 2. server selects h2 (we need an API for the selection). >> 3. server selects h2_valid_cipher because of h2 is selected previously >> (may need an API for the selection). > > Does not work. How do you know that server has h2_valid_cipher available ? > If it does not, you have picked h2, and an invalid cipher (breaks > 7540), or you terminate the connection while instead you could speak > http/1.1. > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory cipher suite for H2. Per RFC 7540, "... To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256 elliptic curve" >> In #1, if there is no h2_valid_cipher requested, it is a bug in client side. >> In #3, if there is no h2_valid_cipher that can be negotiated, it is a >> bug in server side, or the client does not enabled the mandatory cipher >> suite (a bug in client). > > Does not work. > The client may be using TLS 1.4, where that mandatory cipher suite > (it's mandatory only for TLS 1.2 deployments) has been removed because > insecure. > There is no bug on either side, just no cipher in common. > I see you point here. But new mandatory cipher suite would be defined, that's the general SSL/TLS spec in order to avoid "no cipher suite in common problem". >> I still cannot understand the outcome. I think, if there is no h2 valid >> cipher in common, the connection should be terminated as there is a bug >> in client or server side (see above). > > No, see above. > >> I'm not familiar with HTTP/2 protocol, can you share more scenarios that >> application protocol selection depends on the cipher? > > It is evident. > > In all examples, yours and mines, every time we pick "h2" we have to > look at the ciphers to see if it is a valid one for h2 or not. > You cannot pick "h2" without looking at the cipher so there is an > evident dependency. In my preference, if a serve support h2, SSL/TLS should select h2 if requested, without considering the cipher suite and other handshaking attributes impact. > If it's not the right cipher, you say "close the connection", while > the implemented behavior of browsers and servers is to fallback to > http/1.1. > Either case, you have looked at the cipher and taken a decision based > on the tuple (app_proto, cipher). > > In contrast, you can pick "http/1.1" and *any* cipher you want, you > don't need to look at the cipher. > I need more information to understand the necessity. See my question in the beginning. >>> A bit of warning here: we are designing an API for ALPN, not for HTTP/2. >>> The ALPN API should be flexible enough to implement *at least* HTTP/2, >>> possibly even more complex scenarios (for example alias selection), >>> but IMHO it should not be tied to HTTP/2. >>> >> Yes. That's what I intended to do now. It's very bad if application >> protocol selection depends on the negotiation of TLS protocols, cipher >> suites, or other handshake attributes, or other Chicken/Eggs dependence. >> As would make the JSSE provider hard to be implemented, and the API hard >> to be used. That's what I want to avoid in JSSE layer. >> >>> Again, I see 2 cases: either the JDK implementation picks the TLS >>> protocol, the cipher and the alias like it does now, and then invokes >>> the "callback" to pick the application protocol (current Jetty ALPN >>> behavior), or the implementation must be reviewed to perform TLS >>> protocol, cipher, alias and application protocol selection at once, >>> with a "callback" that will be invoked possibly multiple times until >>> it can find the right tuple to return. >>> >> The former has a drawback that the cipher may not suitable for the >> application protocol. It's application protocol define with cipher >> suite is suitable (RFC7540), not cipher suite define which application >> protocol is suitable. So application protocol should be selected at >> first, and let the specific application protocol determines the >> negotiable cipher suite. > > That forbids any form of fallback to http/1.1, and it's not what it's > intended by 7540, nor what has been implemented by browsers and > servers. > I need more information to understand the necessity. See my question in the beginning. > IMHO would be very bad to kill the whole communication between a > client and a server just because they can't speak h2. > The whole world speaks http/1.1 no problem, so why now they could not anymore ? Why now they could not anymore? They should be able to do it as before. Nothing would impact this behavior, right? > I understand h2 is preferred, but that should not stop a browser and a > server to use http/1.1 if they can't use h2. > See above, I don't understand the behavior. Here is four cases: 1. Client HTTP version is 2, server HTTP version is 2. 2. Clinet HTTP version is 1.1, server HTTP version is 2. 3. Client HTTP version is 2, server HTTP version is 1.1. 4. Client HTTP version is 1.1, server HTTP version is 1.1. #2, #3, $4 should use HTTP/1.1, and #1 should use HTTP/2. Can #1 downgrade to use HTTP/1.1? See my question in the beginning. >> The latter made the TLS implementation pretty complicated. It is even >> not doable actually in general. Too much attributes need to be >> considered if more handshake properties are involved, such as >> certificate, key parameters, etc. > > I am not sure about the impossibility. > IIUC, there are 4 parameters that needs to be negotiated: TLS > protocol, cipher, alias and application protocol. > The data in the ClientHello and the server configuration certainly > allow for such a tuple to be generated, so it's not impossible. > Sure, it may be really hard on the implementation. > ;-) Nothing is impossible. It's not only hard to implement a SSL/TLS vendor, but also hard to implement the application-layer protocol selector in practice. If it is really necessary, surely we have to pay for it. > The current Jetty ALPN support has taken the shortcut that application > protocol is negotiated after cipher selection. > Sure, Jetty ALPN can't pick the protocol based on the alias for example. > And it has to sort the ciphers in a HTTP/2 specific way to influence > cipher selection to prefer those that would be good for HTTP/2. > It's not perfect but works. > >> See also my previous mail about the rerouting requirement. > > Which I am not sure I understand. > If the router decides the application protocol, it must have the > correct logic, > and the server can't choose anything. > If the router routes to a server thinking that it would speak h2, but > then the server does not negotiate h2, that means the router has no > power in deciding anything. > I am sure I am missing something from your example ? > > We have deployed a rerouting using HAProxy and Jetty in our own > website a while back, using spdy (that has no cipher requirements). > If spdy was negotiated we routed the traffic to one connector, > otherwise to another connector. > However, HAProxy was offloading TLS and was speaking clear text to the > backend servers. > > Is that your scenario ? > No. Thinking about the case that the router is a public router, and know nothing about the server details except that it knows that the server support HTTP/2. >> I think application-layer protocol negotiation should happen before the >> actually general-handshaking (TLS protocol, cipher suite, general >> extension negotiation). For any incoming ClientHello message, the >> scenarios in server side is as simple as: >> 1. select the right application-layer protocols. >> 2. do the actual general handshaking. If something failed, terminate >> the connection. > > Nope. > > Imagine a server that overnight added h2 support. > > Yesterday a browser could open a page and browse the site over http/1.1. I think you mean, yesterday, the client supports HTTP/2. Otherwise, it should not request HTTP/2. > Today, the browser cannot even connect to the website (because you > don't allow fallback). I don't understand why the browser cannot connect to the website. The client supports HTTP/2, and the server also supports HTTP/2. Should work. > But if you use Netscape 4, you can actually connect and browse the > site as before :) > Netscape 4 does not request HTTP/2, right? Need no fall-back. > Imagine how much the adoption of h2 would be popular if that was the case. > Certainly the 7540 expert group did not want this. > >> I'm not familiar with HTTP/2, I'm open to hear more case why above >> scenarios does not work. > > See above. > Thanks! Xuelei From alexander.v.stepanov at oracle.com Fri Jun 5 12:51:54 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 05 Jun 2015 15:51:54 +0300 Subject: RFR [9] 8081517: minor cleanup for docs Message-ID: <55719B6A.4000904@oracle.com> Hello, Could you please review the fix http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8081517 Just some cleanup for docs. Thanks, Alexander From lance.andersen at oracle.com Fri Jun 5 13:29:52 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 5 Jun 2015 09:29:52 -0400 Subject: RFR [9] 8081517: minor cleanup for docs In-Reply-To: <55719B6A.4000904@oracle.com> References: <55719B6A.4000904@oracle.com> Message-ID: Hi Alxander Overall. looks OK. A couple of things I thought could be changed; In FTPURLConnection, I probably would surround the code in an {@code} tag In VmIdentifier, I do not see think we still need

in the

  • tags Best Lance On Jun 5, 2015, at 8:51 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix > http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8081517 > > Just some cleanup for docs. > > Thanks, > Alexander Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From simone.bordet at gmail.com Fri Jun 5 14:11:05 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 5 Jun 2015 16:11:05 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <557197C9.5010407@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> Message-ID: Hi, On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote: > See more inlines, please. > > Please help on one question I'm not sure of. Per HTTP/2 specification, > Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 > connection? I did not find the answer from RFC 7540. Yes. The intended behavior is exactly to fall back to http/1.1 if h2 cannot be negotiated. This is implicitly explained in the ALPN spec, RFC 7301, see http://tools.ietf.org/html/rfc7301#section-3.2. > In TLS, if client requests to negotiate TLS v1.2, and server supports > TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not > suitable cipher suite to negotiate TLS 1.2, the connection would be > terminated immediately. I'm not sure what's the spec for HTTP/2, > HTTP/1.1 and HTTP/1.0. HTTP/2 does not behave like TLS in this sense. ALPN is for *application* protocol selection. A client can send: ["h2", "spdy/3.1", "http/1.1"] Failing h2, spdy/3.1 is attempted, which is a completely different protocol, with different restrictions, etc. > Per RFC 7540, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory > cipher suite for H2. No. It's a mandatory cipher for *TLS 1.2 deployments only*. If the client uses TLS 1.4 does not have to have that cipher, and hence there can be an empty intersection of ciphers with the server. That cipher is only mentioned because all the mandatory TLS 1.2 ciphers have been blacklisted by HTTP/2. If TLS 1.3 was specified before HTTP/2, that cipher would not even be mentioned, and the HTTP/2 spec would have referenced only TLS 1.3 as mandatory: no black lists, no special cipher. The TLS and HTTP specifications will evolve independently, and there cannot be a requirement that whenever TLS changes, an update to HTTP/2 must be published. Hope this clarifies. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Fri Jun 5 14:46:29 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 22:46:29 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> Message-ID: <5571B645.7050305@oracle.com> On 6/5/2015 10:11 PM, Simone Bordet wrote: > On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote: >> > See more inlines, please. >> > >> > Please help on one question I'm not sure of. Per HTTP/2 specification, >> > Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 >> > connection? I did not find the answer from RFC 7540. > Yes. > The intended behavior is exactly to fall back to http/1.1 if h2 cannot > be negotiated. > > This is implicitly explained in the ALPN spec, RFC 7301, see > http://tools.ietf.org/html/rfc7301#section-3.2. > This section says: "It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it." I may have different understanding. If server support H2, H2 should be used. No fallback is expected. Support does not means the protocol must work in any cases. Fallback to use HTTP/1.1 should be a spec of HTTP/2, rather than TLS protocols. I would like to see an evidence in HTTP/2 spec that H2 server allow fallback to HTTP/1.1. >> > In TLS, if client requests to negotiate TLS v1.2, and server supports >> > TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not >> > suitable cipher suite to negotiate TLS 1.2, the connection would be >> > terminated immediately. I'm not sure what's the spec for HTTP/2, >> > HTTP/1.1 and HTTP/1.0. > HTTP/2 does not behave like TLS in this sense. > > ALPN is for *application* protocol selection. > A client can send: > > ["h2", "spdy/3.1", "http/1.1"] > > Failing h2, spdy/3.1 is attempted, which is a completely different > protocol, with different restrictions, etc. > "Failing" is confusing. Support does not means the protocol must work in any cases. But failing means that. I would use "support" for the description as what RFC 7301 does. If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not supported HTTP/1.1 would be attempted. If H2 is supported in both side, but H2 does not work, it is a H2 problem that need to be addressed in H2 layer. No application protocol fallback in TLS layer if the application protocol is supported. I understand your concerns now. I think we have different understanding of the ALPN protocols. It's a good thing to understand the actually requirements of the industry, I think. Thank you! Xuelei From simone.bordet at gmail.com Fri Jun 5 15:16:40 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 5 Jun 2015 17:16:40 +0200 Subject: TLS ALPN Proposal v2 In-Reply-To: <5571B645.7050305@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> Message-ID: Hi, On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote: > If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not > supported HTTP/1.1 would be attempted. Correct. > If H2 is supported in both side, > but H2 does not work, it is a H2 problem that need to be addressed in H2 > layer. If both client and server have "h2" as a potentially supported protocol, but the cipher to use h2 is not valid, then h2 is not supported for that particular connection. At that point, like you said above, spdy/3.1 is attempted, and so on. > No application protocol fallback in TLS layer if the application > protocol is supported. Your interpretation of "supported" is not what browser and server implementors mean :) > I understand your concerns now. I think we have different understanding > of the ALPN protocols. It's a good thing to understand the actually > requirements of the industry, I think. Thank you! So where does this leave us know ? By the way, while I have participated in the RFC 7540 discussions, and implemented HTTP/2 in Jetty to be interoperable with a variety of other clients and servers, feel free to ask clarifications to the RFC 7540 and RFC 7301 mailing lists, or even directly to the editors of those RFCs; they are typically open to answer questions, I guess especially so if they come from the OpenJDK team that is implementing those specification. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Fri Jun 5 15:28:22 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Jun 2015 23:28:22 +0800 Subject: TLS ALPN Proposal v2 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> Message-ID: <5571C016.7080909@oracle.com> On 6/5/2015 11:16 PM, Simone Bordet wrote: > Hi, > > On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote: >> If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not >> supported HTTP/1.1 would be attempted. > > Correct. > >> If H2 is supported in both side, >> but H2 does not work, it is a H2 problem that need to be addressed in H2 >> layer. > > If both client and server have "h2" as a potentially supported > protocol, but the cipher to use h2 is not valid, then h2 is not > supported for that particular connection. > At that point, like you said above, spdy/3.1 is attempted, and so on. > ;-) That's the point we cannot agree with each other at present. >> No application protocol fallback in TLS layer if the application >> protocol is supported. > > Your interpretation of "supported" is not what browser and server > implementors mean :) > ;-) maybe. It's not my expertise. >> I understand your concerns now. I think we have different understanding >> of the ALPN protocols. It's a good thing to understand the actually >> requirements of the industry, I think. Thank you! > > So where does this leave us know ? > ;-) I think Brad would consider our information for his design. > By the way, while I have participated in the RFC 7540 discussions, and > implemented HTTP/2 in Jetty to be interoperable with a variety of > other clients and servers, feel free to ask clarifications to the RFC > 7540 and RFC 7301 mailing lists, or even directly to the editors of > those RFCs; they are typically open to answer questions, I guess > especially so if they come from the OpenJDK team that is implementing > those specification. > Yes. It would be help to know the implementation of other SSL/TLS vendors, too. Thanks, Xuelei From weijun.wang at oracle.com Fri Jun 5 15:44:37 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 05 Jun 2015 23:44:37 +0800 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 In-Reply-To: <556F65A9.8090507@oracle.com> References: <556F65A9.8090507@oracle.com> Message-ID: <5571C3E5.3030104@oracle.com> Hi Sean Everything is fine, some comments: FilePermission (also in SocketPermission, PropertyPermission, ServicePermission): int oldMask = ((FilePermission)existingVal).getMask(); int newMask = ((FilePermission)newVal).getMask(); if (oldMask != newMask) { int effective = oldMask | newMask; if (effective != oldMask) { return new FilePermission(fp.getName(), effective); } } return existingVal; Is it worth checking "if (effective == newMask)"? Then you can return newVal without creating a new FilePermission object. SocketPermission: JDK-431064? There should be 7 digits. UnresolvedPermissionCollection: The use of CopyOnWriteArrayList is cool, but add(up) right after an empty one is created seems like an unnecessary copy-on-write. Maybe we can file an RFE on CopyOnWriteArrayList itself? The newly added tests are great, but are they already covered by JCK or shall we contribute them to JCK? Thanks Max On 06/04/2015 04:38 AM, Sean Mullan wrote: > This is the third and fourth in a series of fixes for JEP 232 (Improve > Secure Application Performance) [1]. > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/ > bugs: https://bugs.openjdk.java.net/browse/JDK-8065942 and > https://bugs.openjdk.java.net/browse/JDK-8056179 > > This fix changes the Permissions and PermissionCollection subclasses to > use concurrent collections, which significantly reduces contention when > multiple threads are performing security checks. The bugs needed to be > fixed together, because removing the synchronized blocks in Permissions > revealed that several of the underlying PermissionCollection > implementations were not thread-safe. > > Several new unit tests were also added to test basic functionality of > these classes. > > With these fixes, the throughput of the Permissions.implies method > improves from approximately 6x to 10x when more than one thread is > running. Each of the bugs contains a performance chart with more details. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 From sean.coffey at oracle.com Fri Jun 5 17:37:33 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Jun 2015 18:37:33 +0100 Subject: RFR: 8077418: StackOverflowError during PolicyFile lookup Message-ID: <5571DE5D.5080202@oracle.com> A regression has been discovered after JDK-8058547 was fixed in 8u60. For now, I'm proposing we back the fix out from the jdk8u-dev forest and plan a new fix. This is a straight-forward anti delta of 8058547 JDK 9 is not impacted since JDK-8055753 already removed this code. bug : https://bugs.openjdk.java.net/browse/JDK-8077418 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077418.8u/webrev/ -- Regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jun 5 20:53:37 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 05 Jun 2015 16:53:37 -0400 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 In-Reply-To: <5571C3E5.3030104@oracle.com> References: <556F65A9.8090507@oracle.com> <5571C3E5.3030104@oracle.com> Message-ID: <55720C51.7000906@oracle.com> Thanks for the comments, Max. Replies below ... On 06/05/2015 11:44 AM, Weijun Wang wrote: > Hi Sean > > Everything is fine, some comments: > > FilePermission (also in SocketPermission, PropertyPermission, > ServicePermission): > > int oldMask = ((FilePermission)existingVal).getMask(); > int newMask = ((FilePermission)newVal).getMask(); > if (oldMask != newMask) { > int effective = oldMask | newMask; > if (effective != oldMask) { > return new FilePermission(fp.getName(), effective); > } > } > return existingVal; > > Is it worth checking "if (effective == newMask)"? Then you can return > newVal without creating a new FilePermission object. Yes - very good point, will change that. > SocketPermission: > > JDK-431064? There should be 7 digits. Oops, should be 4301064, will fix. > > UnresolvedPermissionCollection: > > The use of CopyOnWriteArrayList is cool, but add(up) right after an > empty one is created seems like an unnecessary copy-on-write. Maybe we > can file an RFE on CopyOnWriteArrayList itself? Yeah maybe. An alternative is: new CopyOnWriteArrayList<>(Collections.singletonList(up)); but it seems a bit like overkill. > The newly added tests are great, but are they already covered by JCK or > shall we contribute them to JCK? I'll take a look, but this area is lacking in regression tests, so some duplication I think is ok. --Sean > > Thanks > Max > > > On 06/04/2015 04:38 AM, Sean Mullan wrote: >> This is the third and fourth in a series of fixes for JEP 232 (Improve >> Secure Application Performance) [1]. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/ >> bugs: https://bugs.openjdk.java.net/browse/JDK-8065942 and >> https://bugs.openjdk.java.net/browse/JDK-8056179 >> >> This fix changes the Permissions and PermissionCollection subclasses to >> use concurrent collections, which significantly reduces contention when >> multiple threads are performing security checks. The bugs needed to be >> fixed together, because removing the synchronized blocks in Permissions >> revealed that several of the underlying PermissionCollection >> implementations were not thread-safe. >> >> Several new unit tests were also added to test basic functionality of >> these classes. >> >> With these fixes, the throughput of the Permissions.implies method >> improves from approximately 6x to 10x when more than one thread is >> running. Each of the bugs contains a performance chart with more details. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 From valerie.peng at oracle.com Fri Jun 5 21:04:10 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 05 Jun 2015 14:04:10 -0700 Subject: RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC In-Reply-To: <55717822.5090806@oracle.com> References: <55717822.5090806@oracle.com> Message-ID: <55720ECA.3090304@oracle.com> This looks pretty good. However, I suspect this will stop working once the Jake changes are integrated as module boundaries are enforced? Valerie On 6/5/2015 3:21 AM, Se?n Coffey wrote: > Looking to resolve a recently reported issue where the P11ECKeyFactory > class has too much dependence on the SunEC provider. With some > reshuffling and creation of a new P11ECUtil class, I was able to > remove the call for lookup of SunEC Provider. The test picks up the > regression when running with the SunPKCS11-NSS provider. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8080102 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ > > -- > Regards, > Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jun 5 21:14:13 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 05 Jun 2015 17:14:13 -0400 Subject: RFR: 8077418: StackOverflowError during PolicyFile lookup In-Reply-To: <5571DE5D.5080202@oracle.com> References: <5571DE5D.5080202@oracle.com> Message-ID: <55721125.9020504@oracle.com> Looks good. Please add noreg-other label to bug. --Sean On 06/05/2015 01:37 PM, Se?n Coffey wrote: > > A regression has been discovered after JDK-8058547 was fixed in 8u60. > For now, I'm proposing we back the fix out from the jdk8u-dev forest and > plan a new fix. This is a straight-forward anti delta of 8058547 > > JDK 9 is not impacted since JDK-8055753 already removed this code. > > bug : https://bugs.openjdk.java.net/browse/JDK-8077418 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077418.8u/webrev/ > > -- > Regards, > Sean. > From valerie.peng at oracle.com Fri Jun 5 23:32:51 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 05 Jun 2015 16:32:51 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55714DF2.7090100@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> Message-ID: <557231A3.4040403@oracle.com> I don't know image builder well enough to answer your question. Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. Thanks, Valerie On 6/5/2015 12:21 AM, Erik Joelsson wrote: > Hello Valerie, > > The merging seems ok, but I thought there was non determinism in the > image builder regarding which provider would get picked up. Is that > resolved or do you really need to override all of those providers with > your generated file in gensrc? I can assist in writing that makefile > logic if needed. > > /Erik > > On 2015-06-04 23:58, Valerie Peng wrote: >> Build experts, >> >> Can you please review the make file related change, i.e. the new file >> make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >> >> This is for merging the java.security.Provider file from various >> providers and use the (merged) result for the final image build. >> >> Thanks, >> Valerie >> >> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>> >>> Correct, if the makefile related changes are removed then no need >>> for build team to review 7191662 webrev anymore. >>> There are other discussions ongoing and we should be able to reach a >>> decision in a day or two. >>> Will update the list again. >>> Thanks, >>> Valerie >>> >>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>> >>>>> Please find comments in line... >>>>> >>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>> Valerie, >>>>>> >>>>>> Did you see my comment yesterday? >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>> >>>>> Yes, we exchanged emails after this above one. I will follow up >>>>> your latest one later today. >>>>> >>>>>> >>>>>> Since you have reverted the java.security to keep the classname, >>>>>> to avoid causing merge conflict to jimage refresh, let?s remove >>>>>> the META-INF files in the first push and the build change. >>>>>> >>>>>> The security providers will be loaded via the fallback mechanism >>>>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>>>> ProviderLoader.load method to take the provider name instead of >>>>>> classname. >>>>> Sure, I can remove the META-INF files so the providers are loaded >>>>> through the legacyLoad(). >>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>> file provider loading. Since the current list still uses class >>>>> name, it should take class name when checking for matches while >>>>> iterating through the list returned by ServiceLoader. >>>>> This way, when changes are sync'ed into Jake, no extra change >>>>> required and the providers will be loaded through >>>>> ProviderLoader.load() automatically with the current list. >>>>> >>>>>> I?ll file a bug to follow up to change java.security to list the >>>>>> provider name. This will wait after the jimage refresh goes into >>>>>> jdk9/dev >>>>> Ok. >>>>> Thanks, >>>>> Valerie >>>> >>>> I'm not sure I followed completely here were this landed. Does this >>>> mean that there's currently no need for a build system code review >>>> on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>> that a new webrev will be posted instead? >>>> >>>> /Magnus >>>> >>>> >>>> >>>>>> . >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>> Peng wrote: >>>>>>> >>>>>>> Hi, build experts, >>>>>>> >>>>>>> Can you please review the make file related change, i.e. the new >>>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>> >>>>>>> This is for merging the java.security.Provider file from various >>>>>>> providers and use the (merged) result for the final image build. >>>>>>> >>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> (Java Security Team) >>>> >>> > From weijun.wang at oracle.com Sat Jun 6 03:24:03 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 06 Jun 2015 11:24:03 +0800 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 In-Reply-To: <5571C3E5.3030104@oracle.com> References: <556F65A9.8090507@oracle.com> <5571C3E5.3030104@oracle.com> Message-ID: <557267D3.5010001@oracle.com> ServicePermission: We can also add a ServicePermission(String,int) like FilePermission has. --Max >> http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/ From mandy.chung at oracle.com Sat Jun 6 05:43:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Jun 2015 22:43:18 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557231A3.4040403@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> Message-ID: <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> > On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: > > > I don't know image builder well enough to answer your question. The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. Mandy > Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. > > Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. > Thanks, > Valerie > > On 6/5/2015 12:21 AM, Erik Joelsson wrote: >> Hello Valerie, >> >> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >> >> /Erik >> >> On 2015-06-04 23:58, Valerie Peng wrote: >>> Build experts, >>> >>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>> >>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>> >>> Thanks, >>> Valerie >>> >>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>> Will update the list again. >>>> Thanks, >>>> Valerie >>>> >>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>> >>>>>> Please find comments in line... >>>>>> >>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>> Valerie, >>>>>>> >>>>>>> Did you see my comment yesterday? >>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>> >>>>>>> >>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>> >>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>> >>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>> Ok. >>>>>> Thanks, >>>>>> Valerie >>>>> >>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>>> . >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi, build experts, >>>>>>>> >>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>> >>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>> >>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> (Java Security Team) >>>>> >>>> >> From sean.coffey at oracle.com Sat Jun 6 09:55:07 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Sat, 06 Jun 2015 10:55:07 +0100 Subject: RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC In-Reply-To: <55720ECA.3090304@oracle.com> References: <55717822.5090806@oracle.com> <55720ECA.3090304@oracle.com> Message-ID: <5572C37B.4070804@oracle.com> thanks for review Valerie. I think the current JDK 9 builds already check for some module correctness. Hopefully - what I'm proposing will work post modules. My initial attempt had the java.base module trying to pull in the jdk.crypto.ec module. That would not be allowed. The current proposal doesn't seem to place any issue on modules and the current export rules work ok. Regards, Sean. On 05/06/2015 22:04, Valerie Peng wrote: > > This looks pretty good. > However, I suspect this will stop working once the Jake changes are > integrated as module boundaries are enforced? > Valerie > > > On 6/5/2015 3:21 AM, Se?n Coffey wrote: >> Looking to resolve a recently reported issue where the >> P11ECKeyFactory class has too much dependence on the SunEC provider. >> With some reshuffling and creation of a new P11ECUtil class, I was >> able to remove the call for lookup of SunEC Provider. The test picks >> up the regression when running with the SunPKCS11-NSS provider. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-8080102 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ >> >> -- >> Regards, >> Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jun 8 14:24:58 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 08 Jun 2015 10:24:58 -0400 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 In-Reply-To: <557267D3.5010001@oracle.com> References: <556F65A9.8090507@oracle.com> <5571C3E5.3030104@oracle.com> <557267D3.5010001@oracle.com> Message-ID: <5575A5BA.6000207@oracle.com> On 06/05/2015 11:24 PM, Weijun Wang wrote: > ServicePermission: > > We can also add a ServicePermission(String,int) like FilePermission has. Good point. Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.01/ Changes: - Fixed typo in SocketPermission: JDK-4301064 - Added "if (effective == newMask)" optimization to SocketPermission, FilePermission, and ServicePermission - Added ServicePermission(String,int) ctor and changed ServicePermissionCollection.add to call it. --Sean From konstantin.shefov at oracle.com Mon Jun 8 15:04:48 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 08 Jun 2015 18:04:48 +0300 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol Message-ID: <5575AF10.1000908@oracle.com> Hello, Please review distribution of some DTLS feature tests to TLS protocol. Some DTLS tests may also be used to test the same functionality in TLS protocol and its versions. It is test only improvement. bug: https://bugs.openjdk.java.net/browse/JDK-8085979 webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ Thanks -Konstantin From weijun.wang at oracle.com Mon Jun 8 16:33:59 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 09 Jun 2015 00:33:59 +0800 Subject: JEP 232 RFR: JDK-8065942 and JDK-8056179 In-Reply-To: <5575A5BA.6000207@oracle.com> References: <556F65A9.8090507@oracle.com> <5571C3E5.3030104@oracle.com> <557267D3.5010001@oracle.com> <5575A5BA.6000207@oracle.com> Message-ID: <5575C3F7.5000209@oracle.com> Great. Everything is fine. Thanks Max On 06/08/2015 10:24 PM, Sean Mullan wrote: > On 06/05/2015 11:24 PM, Weijun Wang wrote: >> ServicePermission: >> >> We can also add a ServicePermission(String,int) like FilePermission has. > > Good point. Updated webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.01/ > > Changes: > - Fixed typo in SocketPermission: JDK-4301064 > - Added "if (effective == newMask)" optimization to SocketPermission, > FilePermission, and ServicePermission > - Added ServicePermission(String,int) ctor and changed > ServicePermissionCollection.add to call it. > > --Sean From valerie.peng at oracle.com Mon Jun 8 23:44:56 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 08 Jun 2015 16:44:56 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> Message-ID: <557628F8.8000001@oracle.com> What is the bug id for the image refresh change? Just so I can keep a watch and hold my changes for the time being. My webrev has a new regression test which compares the list of providers found by ServiceLoader and Security.getProviders() call. So, if the META-INF/services/java.security.Provider file content is not correct, the new test would fail and it's a clear indication that ServiceLoader can't find one or more of the providers. Thanks, Valerie On 6/5/2015 10:43 PM, Mandy Chung wrote: >> On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: >> >> >> I don't know image builder well enough to answer your question. > The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. > > There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. > > Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. > > If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. > > Mandy > >> Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. >> >> Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. >> Thanks, >> Valerie >> >> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>> Hello Valerie, >>> >>> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >>> >>> /Erik >>> >>> On 2015-06-04 23:58, Valerie Peng wrote: >>>> Build experts, >>>> >>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>> >>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>>> Will update the list again. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>> Please find comments in line... >>>>>>> >>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>> Valerie, >>>>>>>> >>>>>>>> Did you see my comment yesterday? >>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>>> >>>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>>> >>>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>>> >>>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>>> Ok. >>>>>>> Thanks, >>>>>>> Valerie >>>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi, build experts, >>>>>>>>> >>>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>> >>>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>>> >>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> (Java Security Team) From mandy.chung at oracle.com Mon Jun 8 23:53:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 08 Jun 2015 16:53:50 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557628F8.8000001@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> Message-ID: <55762B0E.4090407@oracle.com> JDK-8066492 Mandy On 06/08/2015 04:44 PM, Valerie Peng wrote: > > What is the bug id for the image refresh change? Just so I can keep a > watch and hold my changes for the time being. > > My webrev has a new regression test which compares the list of > providers found by ServiceLoader and Security.getProviders() call. So, > if the META-INF/services/java.security.Provider file content is not > correct, the new test would fail and it's a clear indication that > ServiceLoader can't find one or more of the providers. > > Thanks, > Valerie > > On 6/5/2015 10:43 PM, Mandy Chung wrote: >>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>> wrote: >>> >>> >>> I don't know image builder well enough to answer your question. >> The current implementation of the image builder sorts the modules by >> their name that are mapped to the same class loader. That explains >> why java.naming is the first one containing >> META-INF/services/java.security.Provider in your current list. >> >> There is no guarantee in what particular order a module is processed >> first. I don?t know if the jimage refresh work will change the >> ordering either. Since this is temporary, I?m okay if you want to >> depend on the image build implementation as long as you have a test >> to catch it and verify >> java.naming/META-INF/services/java.security.Provider file content. >> The existing security tests may also catch it but I think it?s not >> obvious to indicate that the security tests fail because of the issue >> of the merged service configuration file. >> >> Please also hold off until the image refresh change goes into >> jdk9/dev so that you can verify if your build change still works. >> >> If you want to push earlier, another alternative we discussed earlier >> is to separate the META-INF/services file and make change and >> java.security to keep using classname. That can be pushed that in a >> second phase with a proper image builder support. >> >> Mandy >> >>> Based on my own experiment, it seems to pick up the one from >>> java.naming when duplication occurs, so that's why I saved the >>> merged result to there and named the Gensrc makefile with >>> java.naming. The result build work fine. >>> >>> Does this explain what I am trying to do here? If you have better >>> ways to get this done, I am certainly open to that idea. >>> Thanks, >>> Valerie >>> >>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>> Hello Valerie, >>>> >>>> The merging seems ok, but I thought there was non determinism in >>>> the image builder regarding which provider would get picked up. Is >>>> that resolved or do you really need to override all of those >>>> providers with your generated file in gensrc? I can assist in >>>> writing that makefile logic if needed. >>>> >>>> /Erik >>>> >>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>> Build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>> Correct, if the makefile related changes are removed then no need >>>>>> for build team to review 7191662 webrev anymore. >>>>>> There are other discussions ongoing and we should be able to >>>>>> reach a decision in a day or two. >>>>>> Will update the list again. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>> Please find comments in line... >>>>>>>> >>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>> Valerie, >>>>>>>>> >>>>>>>>> Did you see my comment yesterday? >>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> >>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>> your latest one later today. >>>>>>>> >>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>> build change. >>>>>>>>> >>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>> instead of classname. >>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>> loaded through the legacyLoad(). >>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>> file provider loading. Since the current list still uses class >>>>>>>> name, it should take class name when checking for matches while >>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>> required and the providers will be loaded through >>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>> >>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>> goes into jdk9/dev >>>>>>>> Ok. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>> this mean that there's currently no need for a build system code >>>>>>> review on >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>> that a new webrev will be posted instead? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>> Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi, build experts, >>>>>>>>>> >>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>> >>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>> image build. >>>>>>>>>> >>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> (Java Security Team) From sean.mullan at oracle.com Tue Jun 9 11:21:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 09 Jun 2015 07:21:48 -0400 Subject: sun.security.x509.DNSName leading dot in name constraints In-Reply-To: <201506090621.t596LS3j025801@hermes15.it.auth.gr> References: <201506090621.t596LS3j025801@hermes15.it.auth.gr> Message-ID: <5576CC4C.4000406@oracle.com> -Bcc jdk9-dev This question is more appropriate for security-dev, so I am copying that list for further discussion. --Sean On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote: > Hi all, > > I work for the Hellenic Academic and Research Institutions Certification Authority (https://www.harica.gr), a Root Certification Authority included in the NSS, Microsoft and Apple certificate stores. Our RootCA certificate uses the name constraints extension with a small error, instead of just gr, org and edu in the permitted subtrees it has .gr, .edu and .org. As a result certificates issued under our CA fail to verify with Java. We had the same issue with OpenSSL and gnuTLS but fortunately they modified their implementation to accommodate for our situation. I kindly ask if this is something that could also be done with OpenJDK, and if so what would be the best way to implement that. Currently we have a patch against the 'constrains' method of 'DNSName' that just ignores the leading dot in name constraints. > > Kind Regards, > Vyronas Tsingaras, > Aristotle University of Thessaloniki, IT Center > From sean.mullan at oracle.com Tue Jun 9 12:12:19 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 09 Jun 2015 08:12:19 -0400 Subject: sun.security.x509.DNSName leading dot in name constraints In-Reply-To: <5576CC4C.4000406@oracle.com> References: <201506090621.t596LS3j025801@hermes15.it.auth.gr> <5576CC4C.4000406@oracle.com> Message-ID: <5576D823.7010801@oracle.com> On 06/09/2015 07:21 AM, Sean Mullan wrote: > -Bcc jdk9-dev > > This question is more appropriate for security-dev, so I am copying that > list for further discussion. > > --Sean > > On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote: >> Hi all, >> >> I work for the Hellenic Academic and Research Institutions >> Certification Authority (https://www.harica.gr), a Root Certification >> Authority included in the NSS, Microsoft and Apple certificate stores. >> Our RootCA certificate uses the name constraints extension with a >> small error, instead of just gr, org and edu in the permitted subtrees >> it has .gr, .edu and .org. As a result certificates issued under our >> CA fail to verify with Java. We had the same issue with OpenSSL and >> gnuTLS but fortunately they modified their implementation to >> accommodate for our situation. I kindly ask if this is something that >> could also be done with OpenJDK, and if so what would be the best way >> to implement that. Currently we have a patch against the 'constrains' >> method of 'DNSName' that just ignores the leading dot in name >> constraints. We don't make exceptions for cases like this, as it is not compliant with RFC 5280. However, are the name constraints only on the root certificate? When specified this way, they are optional (see RFC 5280 section 6.2). Our implementation does not process them by default (you must specify them as an optional parameter to the TrustAnchor class). Are the name constraints included in other certificates chaining back to the root? --Sean >> >> Kind Regards, >> Vyronas Tsingaras, >> Aristotle University of Thessaloniki, IT Center >> From xuelei.fan at oracle.com Tue Jun 9 14:57:48 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 09 Jun 2015 22:57:48 +0800 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol In-Reply-To: <5575AF10.1000908@oracle.com> References: <5575AF10.1000908@oracle.com> Message-ID: <5576FEEC.9040501@oracle.com> Looks fine to me. Nice port to TLS protocols. A very minior comment about the class name. TLSUnSupportedCiphersTest.java: replease "UnSupported" with "Unsupported". Thanks, Xuelei On 6/8/2015 11:04 PM, Konstantin Shefov wrote: > Hello, > > Please review distribution of some DTLS feature tests to TLS protocol. > Some DTLS tests may also be used to test the same functionality in TLS > protocol and its versions. > It is test only improvement. > > bug: https://bugs.openjdk.java.net/browse/JDK-8085979 > webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ > > > Thanks > -Konstantin From xuelei.fan at oracle.com Tue Jun 9 15:07:55 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 09 Jun 2015 23:07:55 +0800 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol In-Reply-To: <5576FEEC.9040501@oracle.com> References: <5575AF10.1000908@oracle.com> <5576FEEC.9040501@oracle.com> Message-ID: <5577014B.4080004@oracle.com> On 6/9/2015 10:57 PM, Xuelei Fan wrote: > Looks fine to me. Nice port to TLS protocols. > > A very minior comment about the class name. > TLSUnSupportedCiphersTest.java: > replease "UnSupported" with "Unsupported". > typo: replace "UnSupported" with "Unsupported". > Thanks, > Xuelei > > On 6/8/2015 11:04 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review distribution of some DTLS feature tests to TLS protocol. >> Some DTLS tests may also be used to test the same functionality in TLS >> protocol and its versions. >> It is test only improvement. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8085979 >> webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ >> >> >> Thanks >> -Konstantin > From konstantin.shefov at oracle.com Tue Jun 9 15:31:23 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 09 Jun 2015 18:31:23 +0300 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol In-Reply-To: <5577014B.4080004@oracle.com> References: <5575AF10.1000908@oracle.com> <5576FEEC.9040501@oracle.com> <5577014B.4080004@oracle.com> Message-ID: <557706CB.30604@oracle.com> Xuelei, thanks for reviewing typo is corrected: http://cr.openjdk.java.net/~kshefov/8085979/webrev.01/ -Konstantin On 06/09/2015 06:07 PM, Xuelei Fan wrote: > On 6/9/2015 10:57 PM, Xuelei Fan wrote: >> Looks fine to me. Nice port to TLS protocols. >> >> A very minior comment about the class name. >> TLSUnSupportedCiphersTest.java: >> replease "UnSupported" with "Unsupported". >> > typo: replace "UnSupported" with "Unsupported". > >> Thanks, >> Xuelei >> >> On 6/8/2015 11:04 PM, Konstantin Shefov wrote: >>> Hello, >>> >>> Please review distribution of some DTLS feature tests to TLS protocol. >>> Some DTLS tests may also be used to test the same functionality in TLS >>> protocol and its versions. >>> It is test only improvement. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8085979 >>> webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ >>> >>> >>> Thanks >>> -Konstantin From xuelei.fan at oracle.com Tue Jun 9 15:47:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 09 Jun 2015 23:47:46 +0800 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol In-Reply-To: <557706CB.30604@oracle.com> References: <5575AF10.1000908@oracle.com> <5576FEEC.9040501@oracle.com> <5577014B.4080004@oracle.com> <557706CB.30604@oracle.com> Message-ID: <55770AA2.4060001@oracle.com> On 6/9/2015 11:31 PM, Konstantin Shefov wrote: > Xuelei, thanks for reviewing > > typo is corrected: > http://cr.openjdk.java.net/~kshefov/8085979/webrev.01/ > Why there are old "UnSupportedCiphersTest.java" files? If you have not committed the changeset, you can "hg forget" to undo a previous "hg add". As would avoid the unnecessary old file logs. Xuelei > -Konstantin > > On 06/09/2015 06:07 PM, Xuelei Fan wrote: >> On 6/9/2015 10:57 PM, Xuelei Fan wrote: >>> Looks fine to me. Nice port to TLS protocols. >>> >>> A very minior comment about the class name. >>> TLSUnSupportedCiphersTest.java: >>> replease "UnSupported" with "Unsupported". >>> >> typo: replace "UnSupported" with "Unsupported". >> >>> Thanks, >>> Xuelei >>> >>> On 6/8/2015 11:04 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review distribution of some DTLS feature tests to TLS protocol. >>>> Some DTLS tests may also be used to test the same functionality in TLS >>>> protocol and its versions. >>>> It is test only improvement. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8085979 >>>> webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ >>>> >>>> >>>> Thanks >>>> -Konstantin > From xuelei.fan at oracle.com Tue Jun 9 16:00:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Jun 2015 00:00:02 +0800 Subject: [9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol In-Reply-To: <55770AA2.4060001@oracle.com> References: <5575AF10.1000908@oracle.com> <5576FEEC.9040501@oracle.com> <5577014B.4080004@oracle.com> <557706CB.30604@oracle.com> <55770AA2.4060001@oracle.com> Message-ID: <55770D82.1050507@oracle.com> On 6/9/2015 11:47 PM, Xuelei Fan wrote: > On 6/9/2015 11:31 PM, Konstantin Shefov wrote: >> Xuelei, thanks for reviewing >> >> typo is corrected: >> http://cr.openjdk.java.net/~kshefov/8085979/webrev.01/ >> > Why there are old "UnSupportedCiphersTest.java" files? If you have not > committed the changeset, you can "hg forget" to undo a previous "hg > add". As would avoid the unnecessary old file logs. > Ooops, my fault. The old files are the previous DTLS tests. It's OK. Thanks for the update. Thanks, Xuelei > Xuelei > >> -Konstantin >> >> On 06/09/2015 06:07 PM, Xuelei Fan wrote: >>> On 6/9/2015 10:57 PM, Xuelei Fan wrote: >>>> Looks fine to me. Nice port to TLS protocols. >>>> >>>> A very minior comment about the class name. >>>> TLSUnSupportedCiphersTest.java: >>>> replease "UnSupported" with "Unsupported". >>>> >>> typo: replace "UnSupported" with "Unsupported". >>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 6/8/2015 11:04 PM, Konstantin Shefov wrote: >>>>> Hello, >>>>> >>>>> Please review distribution of some DTLS feature tests to TLS protocol. >>>>> Some DTLS tests may also be used to test the same functionality in TLS >>>>> protocol and its versions. >>>>> It is test only improvement. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8085979 >>>>> webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ >>>>> >>>>> >>>>> Thanks >>>>> -Konstantin >> > From sean.mullan at oracle.com Thu Jun 11 13:54:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Jun 2015 09:54:15 -0400 Subject: RFR: JDK-6826789: SecureClassLoader should not use CodeSource URLs as HashMap keys Message-ID: <55799307.7040803@oracle.com> This is the fifth in a series of fixes for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~mullan/webrevs/6826789/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-6826789 This fix changes the keys used in the ProtectionDomain cache in SecureClassLoader from URLs to Strings. The URL.hashCode method can trigger a potentially expensive name service lookup. The String form of the URL avoids that lookup, resulting in a big performance improvement. Thanks, Sean [1] http://openjdk.java.net/jeps/232 From weijun.wang at oracle.com Thu Jun 11 15:33:48 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jun 2015 23:33:48 +0800 Subject: RFR: JDK-6826789: SecureClassLoader should not use CodeSource URLs as HashMap keys In-Reply-To: <55799307.7040803@oracle.com> References: <55799307.7040803@oracle.com> Message-ID: <5579AA5C.50304@oracle.com> Hi Sean I remember you mentioned that although no name lookup is performed here the permissions will be calculated correctly, even if they are granted to different host strings which are actually equivalent (your new test proves this). The URL strings still must be resolved somewhere else to make this happen. Can you add a comment on where? Thanks Max On 06/11/2015 09:54 PM, Sean Mullan wrote: > This is the fifth in a series of fixes for JEP 232 (Improve > Secure Application Performance) [1]. > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/6826789/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-6826789 > > This fix changes the keys used in the ProtectionDomain cache in > SecureClassLoader from URLs to Strings. The URL.hashCode method can > trigger a potentially expensive name service lookup. The String form of > the URL avoids that lookup, resulting in a big performance improvement. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 From sean.mullan at oracle.com Thu Jun 11 16:06:53 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Jun 2015 12:06:53 -0400 Subject: RFR: JDK-6826789: SecureClassLoader should not use CodeSource URLs as HashMap keys In-Reply-To: <5579AA5C.50304@oracle.com> References: <55799307.7040803@oracle.com> <5579AA5C.50304@oracle.com> Message-ID: <5579B21D.6030101@oracle.com> On 6/11/15 11:33 AM, Weijun Wang wrote: > Hi Sean > > I remember you mentioned that although no name lookup is performed here > the permissions will be calculated correctly, even if they are granted > to different host strings which are actually equivalent (your new test > proves this). The URL strings still must be resolved somewhere else to > make this happen. Can you add a comment on where? Yes, I can do that, and there is some info in the bug about this. Basically, the CodeSource URL will be canonicalized (and resolved through the name service if applicable) by the policy provider when determining what permissions to grant (at this point it will call CodeSource.implies which will trigger it). So you still may take a performance hit at some point, but only if a permission check is needed. I should have also pointed out that this improvement benefits apps that don't have a SecurityManager enabled (the startup/loading of classes should be faster). --Sean > > Thanks > Max > > On 06/11/2015 09:54 PM, Sean Mullan wrote: >> This is the fifth in a series of fixes for JEP 232 (Improve >> Secure Application Performance) [1]. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/webrevs/6826789/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-6826789 >> >> This fix changes the keys used in the ProtectionDomain cache in >> SecureClassLoader from URLs to Strings. The URL.hashCode method can >> trigger a potentially expensive name service lookup. The String form of >> the URL avoids that lookup, resulting in a big performance improvement. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 From anthony.scarpino at oracle.com Thu Jun 11 18:01:50 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 11 Jun 2015 11:01:50 -0700 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <5579CD0E.2070801@oracle.com> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I had reviewed back in February. There are two changes from the previous review. One is the separate method for the range checking in jdk:GHASH.java in update(). The other is disabing UseGHASHIntrinsics for arch64 in hotspot. http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ thanks Tony From fotisl at it.auth.gr Thu Jun 11 08:49:05 2015 From: fotisl at it.auth.gr (Fotis Loukos) Date: Thu, 11 Jun 2015 11:49:05 +0300 Subject: sun.security.x509.DNSName leading dot in name constraints In-Reply-To: <5576D823.7010801@oracle.com> References: <201506090621.t596LS3j025801@hermes15.it.auth.gr> <5576CC4C.4000406@oracle.com> <5576D823.7010801@oracle.com> Message-ID: <55794B81.3010709@it.auth.gr> Hello, On 06/09/2015 03:12 PM, Sean Mullan wrote: > On 06/09/2015 07:21 AM, Sean Mullan wrote: >> -Bcc jdk9-dev >> >> This question is more appropriate for security-dev, so I am copying that >> list for further discussion. >> >> --Sean >> >> On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote: >>> Hi all, >>> >>> I work for the Hellenic Academic and Research Institutions >>> Certification Authority (https://www.harica.gr), a Root Certification >>> Authority included in the NSS, Microsoft and Apple certificate stores. >>> Our RootCA certificate uses the name constraints extension with a >>> small error, instead of just gr, org and edu in the permitted subtrees >>> it has .gr, .edu and .org. As a result certificates issued under our >>> CA fail to verify with Java. We had the same issue with OpenSSL and >>> gnuTLS but fortunately they modified their implementation to >>> accommodate for our situation. I kindly ask if this is something that >>> could also be done with OpenJDK, and if so what would be the best way >>> to implement that. Currently we have a patch against the 'constrains' >>> method of 'DNSName' that just ignores the leading dot in name >>> constraints. > > We don't make exceptions for cases like this, as it is not compliant with RFC 5280. However, are the name constraints only on the root certificate? When specified this way, they are optional (see RFC 5280 section 6.2). Our implementation does not process them by default (you must specify them as an optional parameter to the TrustAnchor class). Are the name constraints included in other certificates chaining back to the root? > According to RFC 5280 DNS name restrictions are not domain names. For checking if a constraint is satisfied, you should add zero or more labels to the left-hand side of the constraint and then you generate the domain name. Thus, we believe that our implementation is compliant with RFC 5280. As you noticed, by default the name constraints at the trust anchor are not checked, however we wanted to know if it is possible to successfully validate certificates if they are enforced by the programmer at his application. Regards, Fotis Loukos, PhD HARICA Public Key Infrastructure > --Sean > > >>> >>> Kind Regards, >>> Vyronas Tsingaras, >>> Aristotle University of Thessaloniki, IT Center >>> From aph at redhat.com Fri Jun 12 11:06:22 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jun 2015 12:06:22 +0100 Subject: RFR: 8046943: RSA Acceleration Message-ID: <557ABD2E.7050608@redhat.com> http://cr.openjdk.java.net/~aph/8046943-hs-1/ http://cr.openjdk.java.net/~aph/8046943-jdk-1/ Before: rsa 512 bits 0.000134s 0.000009s 7444.2 111853.3 rsa 1024 bits 0.000674s 0.000029s 1483.9 34456.9 rsa 2048 bits 0.003945s 0.000100s 253.5 9994.7 rsa 4096 bits 0.027015s 0.000373s 37.0 2681.6 After: rsa 512 bits 0.000059s 0.000004s 17022.3 224141.1 rsa 1024 bits 0.000258s 0.000013s 3871.5 78851.0 rsa 2048 bits 0.001506s 0.000042s 664.1 23844.3 rsa 4096 bits 0.010214s 0.000153s 97.9 6516.0 There are some issues we need to discuss. The runtime code is in sharedRuntime_x86_64.cpp even though it's mostly written in C. My thinking here is that porters will want to tweak the code for their back ends, or maybe write it in assembler. It's little-endian and would need some reworking for big-endian machines. But maybe there should be a common version of the code in share/ ? Should it be in optoRuntime instead? It could be called from C1 or even the interpreter, but it's C2-only right now. I've done nothing about 32-bit targets, but I think they would benefit. I had to make some small changes to the Java library. 1. Montgomery multiplication works on whole words. Given that this is a 64-bit implementation I had to force the size of the arrays in oddModPow to be a multiple of 64 bits, i.e. the length of the arrays must be even. Given that RSA and Diffie-Hellman keys are usually a multiple of 64 bits in length I don't think this will be a real performance issue in practice. 2. I needed a 64-bit inverse rather than a 32-bit inverse. This is a single computation, done once for each modular exponentiation, so it makes an immeasurably small difference to the total runtime. 3. I fused squaring and multiplication into a single montgomeryMultiply method. This has two advantages. Firstly, we only need a single intrinsic, and secondly the decision whether to use multiply or squaring can be made in the runtime library. If the target does not support the montgomeryMultiply intrinsic there is no slowdown when using C2 because it removes the if (a == b) test in if (a == b) { product = squareToLen(a, len, product); } else { product = multiplyToLen(a, len, b, len, product); } Andrew. From aph at redhat.com Fri Jun 12 11:29:31 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jun 2015 12:29:31 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <557ABD2E.7050608@redhat.com> References: <557ABD2E.7050608@redhat.com> Message-ID: <557AC29B.3030103@redhat.com> On 06/12/2015 12:06 PM, Andrew Haley wrote: Sorry, I forgot the column labels. The are: sign verify sign/s verify/s > rsa 512 bits 0.000134s 0.000009s 7444.2 111853.3 > rsa 1024 bits 0.000674s 0.000029s 1483.9 34456.9 > rsa 2048 bits 0.003945s 0.000100s 253.5 9994.7 > rsa 4096 bits 0.027015s 0.000373s 37.0 2681.6 > > After: > > rsa 512 bits 0.000059s 0.000004s 17022.3 224141.1 > rsa 1024 bits 0.000258s 0.000013s 3871.5 78851.0 > rsa 2048 bits 0.001506s 0.000042s 664.1 23844.3 > rsa 4096 bits 0.010214s 0.000153s 97.9 6516.0 Andrew. From sean.mullan at oracle.com Fri Jun 12 11:52:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Jun 2015 07:52:48 -0400 Subject: [PATCH] CipherStream produces new byte array on every update or doFinal operation In-Reply-To: <54E78FF0.9050805@oracle.com> References: <20150218090630.95DF.B5B9BC9E@qualeed.com> <54E78FF0.9050805@oracle.com> Message-ID: <557AC810.10904@oracle.com> FYI, I created a bug to track this: https://bugs.openjdk.java.net/browse/JDK-8087327 --Sean On 02/20/2015 02:50 PM, Valerie Peng wrote: > > I started with this, but I have a pressing higher priority tasks at hand. > So, it will take me a few weeks to wrap this up. > Regards, > Valerie > > On 2/17/2015 4:06 PM, Dai Nakanishi wrote: >> Hi, >> >> CipherInputStream and CipherOutputStream call the Cipher methods update >> and doFinal which produce new byte array. It may consume a large amount >> of memory. >> >> The purpose of my patch is to avoid this. Could you review the patch? >> >> Thanks, >> Dai >> >> --- old/src/share/classes/javax/crypto/CipherInputStream.java Thu >> Feb 12 11:55:05 2015 +0900 >> +++ new/src/share/classes/javax/crypto/CipherInputStream.java Tue >> Feb 17 17:12:08 2015 +0900 >> @@ -108,34 +108,50 @@ >> read = true; >> if (readin == -1) { >> done = true; >> + ensureCapacity(0); >> try { >> - obuffer = cipher.doFinal(); >> - } catch (IllegalBlockSizeException | BadPaddingException >> e) { >> + ofinish = cipher.doFinal(obuffer, 0); >> + } catch (IllegalBlockSizeException | BadPaddingException >> + | ShortBufferException e) { >> obuffer = null; >> throw new IOException(e); >> } >> - if (obuffer == null) >> + if (ofinish == 0) >> return -1; >> else { >> ostart = 0; >> - ofinish = obuffer.length; >> return ofinish; >> } >> } >> + ensureCapacity(readin); >> try { >> - obuffer = cipher.update(ibuffer, 0, readin); >> + ofinish = cipher.update(ibuffer, 0, readin, obuffer); >> } catch (IllegalStateException e) { >> obuffer = null; >> throw e; >> + } catch (ShortBufferException e) { >> + obuffer = null; >> + throw new IOException(e); >> } >> ostart = 0; >> - if (obuffer == null) >> - ofinish = 0; >> - else ofinish = obuffer.length; >> return ofinish; >> } >> >> /** >> + * Ensure the capacity of the output buffer for the next >> + * update or doFinal operation, given the input length >> + *inputLen (in bytes) >> + * >> + * @param inputLen the input length (in bytes) >> + */ >> + private void ensureCapacity(int inputLen) { >> + int outputLen = cipher.getOutputSize(inputLen); >> + if (obuffer == null || obuffer.length< outputLen) { >> + obuffer = new byte[outputLen]; >> + } >> + } >> + >> + /** >> * Constructs a CipherInputStream from an InputStream and a >> * Cipher. >> *
    Note: if the specified input stream or cipher is >> @@ -311,10 +327,12 @@ >> try { >> // throw away the unprocessed data >> if (!done) { >> - cipher.doFinal(); >> + ensureCapacity(0); >> + cipher.doFinal(obuffer, 0); >> } >> } >> - catch (BadPaddingException | IllegalBlockSizeException ex) { >> + catch (BadPaddingException | IllegalBlockSizeException >> + | ShortBufferException ex) { >> /* If no data has been read from the stream to be >> en/decrypted, >> we supress any exceptions, and close quietly. */ >> if (read) { >> >> >> --- old/src/share/classes/javax/crypto/CipherOutputStream.java Thu >> Feb 12 11:55:05 2015 +0900 >> +++ new/src/share/classes/javax/crypto/CipherOutputStream.java Tue >> Feb 17 18:48:01 2015 +0900 >> @@ -74,6 +74,9 @@ >> // the buffer holding data ready to be written out >> private byte[] obuffer; >> >> + // the number of bytes stored in the output buffer >> + private int ostored = 0; >> + >> // stream status >> private boolean closed = false; >> >> @@ -118,10 +121,15 @@ >> */ >> public void write(int b) throws IOException { >> ibuffer[0] = (byte) b; >> - obuffer = cipher.update(ibuffer, 0, 1); >> - if (obuffer != null) { >> - output.write(obuffer); >> - obuffer = null; >> + ensureCapacity(1); >> + try { >> + ostored = cipher.update(ibuffer, 0, 1, obuffer); >> + } catch (ShortBufferException e) { >> + throw new IOException(e); >> + } >> + if (ostored> 0) { >> + output.write(obuffer, 0, ostored); >> + ostored = 0; >> } >> }; >> >> @@ -155,10 +163,15 @@ >> * @since JCE1.2 >> */ >> public void write(byte b[], int off, int len) throws IOException { >> - obuffer = cipher.update(b, off, len); >> - if (obuffer != null) { >> - output.write(obuffer); >> - obuffer = null; >> + ensureCapacity(len); >> + try { >> + ostored = cipher.update(b, off, len, obuffer); >> + } catch (ShortBufferException e) { >> + throw new IOException(e); >> + } >> + if (ostored> 0) { >> + output.write(obuffer, 0, ostored); >> + ostored = 0; >> } >> } >> >> @@ -177,9 +190,9 @@ >> * @since JCE1.2 >> */ >> public void flush() throws IOException { >> - if (obuffer != null) { >> - output.write(obuffer); >> - obuffer = null; >> + if (obuffer != null&& ostored> 0) { >> + output.write(obuffer, 0, ostored); >> + ostored = 0; >> } >> output.flush(); >> } >> @@ -206,14 +219,31 @@ >> } >> >> closed = true; >> + ensureCapacity(0); >> try { >> - obuffer = cipher.doFinal(); >> - } catch (IllegalBlockSizeException | BadPaddingException e) { >> + ostored = cipher.doFinal(obuffer, 0); >> + } catch (IllegalBlockSizeException | BadPaddingException >> + | ShortBufferException e) { >> obuffer = null; >> + ostored = 0; >> } >> try { >> flush(); >> } catch (IOException ignored) {} >> out.close(); >> + } >> + >> + /** >> + * Ensure the capacity of the output buffer for the next >> + * update or doFinal operation, given the input length >> + *inputLen (in bytes) >> + * >> + * @param inputLen the input length (in bytes) >> + */ >> + private void ensureCapacity(int inputLen) { >> + int outputLen = cipher.getOutputSize(inputLen); >> + if (obuffer == null || obuffer.length< outputLen) { >> + obuffer = new byte[outputLen]; >> + } >> } >> } >> From sean.mullan at oracle.com Fri Jun 12 17:29:07 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Jun 2015 13:29:07 -0400 Subject: RFR: 8087283 : Add support for the XML Signature here() function to the JDK XPath implementation Message-ID: <557B16E3.1010109@oracle.com> Please review this change to add support for the XML Signature here() function to the JDK XPath implementation. The here function is not defined in its own namespace. Therefore it needs to be implemented by extending the function library of XPath in the same namespace. Currently, the JDK XML Signature implementation uses reflection to invoke a method of an implementation-specific class in the JDK XPath library to register the here function. This fix provides a much cleaner solution that avoids use of reflection by extending the built-in set of XPath functions to include the here function. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8087283/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8087283 Thanks, Sean From valerie.peng at oracle.com Fri Jun 12 18:22:00 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 12 Jun 2015 11:22:00 -0700 Subject: [PATCH] CipherStream produces new byte array on every update or doFinal operation In-Reply-To: <557AC810.10904@oracle.com> References: <20150218090630.95DF.B5B9BC9E@qualeed.com> <54E78FF0.9050805@oracle.com> <557AC810.10904@oracle.com> Message-ID: <557B2348.8000807@oracle.com> Thanks! I have test/modified the patch locally but have yet to create a bug to track it. Valerie On 6/12/2015 4:52 AM, Sean Mullan wrote: > FYI, I created a bug to track this: > https://bugs.openjdk.java.net/browse/JDK-8087327 > > --Sean > > On 02/20/2015 02:50 PM, Valerie Peng wrote: >> >> I started with this, but I have a pressing higher priority tasks at >> hand. >> So, it will take me a few weeks to wrap this up. >> Regards, >> Valerie >> >> On 2/17/2015 4:06 PM, Dai Nakanishi wrote: >>> Hi, >>> >>> CipherInputStream and CipherOutputStream call the Cipher methods update >>> and doFinal which produce new byte array. It may consume a large amount >>> of memory. >>> >>> The purpose of my patch is to avoid this. Could you review the patch? >>> >>> Thanks, >>> Dai >>> >>> --- old/src/share/classes/javax/crypto/CipherInputStream.java Thu >>> Feb 12 11:55:05 2015 +0900 >>> +++ new/src/share/classes/javax/crypto/CipherInputStream.java Tue >>> Feb 17 17:12:08 2015 +0900 >>> @@ -108,34 +108,50 @@ >>> read = true; >>> if (readin == -1) { >>> done = true; >>> + ensureCapacity(0); >>> try { >>> - obuffer = cipher.doFinal(); >>> - } catch (IllegalBlockSizeException | BadPaddingException >>> e) { >>> + ofinish = cipher.doFinal(obuffer, 0); >>> + } catch (IllegalBlockSizeException | BadPaddingException >>> + | ShortBufferException e) { >>> obuffer = null; >>> throw new IOException(e); >>> } >>> - if (obuffer == null) >>> + if (ofinish == 0) >>> return -1; >>> else { >>> ostart = 0; >>> - ofinish = obuffer.length; >>> return ofinish; >>> } >>> } >>> + ensureCapacity(readin); >>> try { >>> - obuffer = cipher.update(ibuffer, 0, readin); >>> + ofinish = cipher.update(ibuffer, 0, readin, obuffer); >>> } catch (IllegalStateException e) { >>> obuffer = null; >>> throw e; >>> + } catch (ShortBufferException e) { >>> + obuffer = null; >>> + throw new IOException(e); >>> } >>> ostart = 0; >>> - if (obuffer == null) >>> - ofinish = 0; >>> - else ofinish = obuffer.length; >>> return ofinish; >>> } >>> >>> /** >>> + * Ensure the capacity of the output buffer for the next >>> + * update or doFinal operation, given the input length >>> + *inputLen (in bytes) >>> + * >>> + * @param inputLen the input length (in bytes) >>> + */ >>> + private void ensureCapacity(int inputLen) { >>> + int outputLen = cipher.getOutputSize(inputLen); >>> + if (obuffer == null || obuffer.length< outputLen) { >>> + obuffer = new byte[outputLen]; >>> + } >>> + } >>> + >>> + /** >>> * Constructs a CipherInputStream from an InputStream and a >>> * Cipher. >>> *
    Note: if the specified input stream or cipher is >>> @@ -311,10 +327,12 @@ >>> try { >>> // throw away the unprocessed data >>> if (!done) { >>> - cipher.doFinal(); >>> + ensureCapacity(0); >>> + cipher.doFinal(obuffer, 0); >>> } >>> } >>> - catch (BadPaddingException | IllegalBlockSizeException ex) { >>> + catch (BadPaddingException | IllegalBlockSizeException >>> + | ShortBufferException ex) { >>> /* If no data has been read from the stream to be >>> en/decrypted, >>> we supress any exceptions, and close quietly. */ >>> if (read) { >>> >>> >>> --- old/src/share/classes/javax/crypto/CipherOutputStream.java Thu >>> Feb 12 11:55:05 2015 +0900 >>> +++ new/src/share/classes/javax/crypto/CipherOutputStream.java Tue >>> Feb 17 18:48:01 2015 +0900 >>> @@ -74,6 +74,9 @@ >>> // the buffer holding data ready to be written out >>> private byte[] obuffer; >>> >>> + // the number of bytes stored in the output buffer >>> + private int ostored = 0; >>> + >>> // stream status >>> private boolean closed = false; >>> >>> @@ -118,10 +121,15 @@ >>> */ >>> public void write(int b) throws IOException { >>> ibuffer[0] = (byte) b; >>> - obuffer = cipher.update(ibuffer, 0, 1); >>> - if (obuffer != null) { >>> - output.write(obuffer); >>> - obuffer = null; >>> + ensureCapacity(1); >>> + try { >>> + ostored = cipher.update(ibuffer, 0, 1, obuffer); >>> + } catch (ShortBufferException e) { >>> + throw new IOException(e); >>> + } >>> + if (ostored> 0) { >>> + output.write(obuffer, 0, ostored); >>> + ostored = 0; >>> } >>> }; >>> >>> @@ -155,10 +163,15 @@ >>> * @since JCE1.2 >>> */ >>> public void write(byte b[], int off, int len) throws >>> IOException { >>> - obuffer = cipher.update(b, off, len); >>> - if (obuffer != null) { >>> - output.write(obuffer); >>> - obuffer = null; >>> + ensureCapacity(len); >>> + try { >>> + ostored = cipher.update(b, off, len, obuffer); >>> + } catch (ShortBufferException e) { >>> + throw new IOException(e); >>> + } >>> + if (ostored> 0) { >>> + output.write(obuffer, 0, ostored); >>> + ostored = 0; >>> } >>> } >>> >>> @@ -177,9 +190,9 @@ >>> * @since JCE1.2 >>> */ >>> public void flush() throws IOException { >>> - if (obuffer != null) { >>> - output.write(obuffer); >>> - obuffer = null; >>> + if (obuffer != null&& ostored> 0) { >>> + output.write(obuffer, 0, ostored); >>> + ostored = 0; >>> } >>> output.flush(); >>> } >>> @@ -206,14 +219,31 @@ >>> } >>> >>> closed = true; >>> + ensureCapacity(0); >>> try { >>> - obuffer = cipher.doFinal(); >>> - } catch (IllegalBlockSizeException | BadPaddingException e) { >>> + ostored = cipher.doFinal(obuffer, 0); >>> + } catch (IllegalBlockSizeException | BadPaddingException >>> + | ShortBufferException e) { >>> obuffer = null; >>> + ostored = 0; >>> } >>> try { >>> flush(); >>> } catch (IOException ignored) {} >>> out.close(); >>> + } >>> + >>> + /** >>> + * Ensure the capacity of the output buffer for the next >>> + * update or doFinal operation, given the input length >>> + *inputLen (in bytes) >>> + * >>> + * @param inputLen the input length (in bytes) >>> + */ >>> + private void ensureCapacity(int inputLen) { >>> + int outputLen = cipher.getOutputSize(inputLen); >>> + if (obuffer == null || obuffer.length< outputLen) { >>> + obuffer = new byte[outputLen]; >>> + } >>> } >>> } >>> From huizhe.wang at oracle.com Fri Jun 12 19:23:34 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 12 Jun 2015 12:23:34 -0700 Subject: RFR: 8087283 : Add support for the XML Signature here() function to the JDK XPath implementation In-Reply-To: <557B16E3.1010109@oracle.com> References: <557B16E3.1010109@oracle.com> Message-ID: <557B31B6.5000100@oracle.com> Hi Sean, The change looks good to me. Thanks, Joe On 6/12/2015 10:29 AM, Sean Mullan wrote: > Please review this change to add support for the XML Signature here() > function to the JDK XPath implementation. The here function is not > defined in its own namespace. Therefore it needs to be implemented by > extending the function library of XPath in the same namespace. > > Currently, the JDK XML Signature implementation uses reflection to > invoke a method of an implementation-specific class in the JDK XPath > library to register the here function. This fix provides a much > cleaner solution that avoids use of reflection by extending the > built-in set of XPath functions to include the here function. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8087283/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8087283 > > Thanks, > Sean From Alan.Bateman at oracle.com Fri Jun 12 19:28:14 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Jun 2015 20:28:14 +0100 Subject: RFR: 8087283 : Add support for the XML Signature here() function to the JDK XPath implementation In-Reply-To: <557B16E3.1010109@oracle.com> References: <557B16E3.1010109@oracle.com> Message-ID: <557B32CE.6000400@oracle.com> On 12/06/2015 18:29, Sean Mullan wrote: > Please review this change to add support for the XML Signature here() > function to the JDK XPath implementation. The here function is not > defined in its own namespace. Therefore it needs to be implemented by > extending the function library of XPath in the same namespace. > > Currently, the JDK XML Signature implementation uses reflection to > invoke a method of an implementation-specific class in the JDK XPath > library to register the here function. This fix provides a much > cleaner solution that avoids use of reflection by extending the > built-in set of XPath functions to include the here function. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8087283/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8087283 The changes look okay to me too. -Alan From vladimir.kozlov at oracle.com Fri Jun 12 22:16:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Jun 2015 15:16:39 -0700 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <5579CD0E.2070801@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> Message-ID: <557B5A47.5090008@oracle.com> This implementation looks good to me. You need second review since changes are big. Thanks, Vladimir On 6/11/15 11:01 AM, Anthony Scarpino wrote: > Now that JEP 246 is targeted, I can proceed a with the GHASH changes I > had reviewed back in February. > > There are two changes from the previous review. One is the separate > method for the range checking in jdk:GHASH.java in update(). The other > is disabing UseGHASHIntrinsics for arch64 in hotspot. > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ > > thanks > > Tony > From fweimer at redhat.com Mon Jun 15 09:58:10 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 15 Jun 2015 11:58:10 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <556E5ECC.4080404@oracle.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> <554AA643.4050101@oracle.com> <554AFFB2.6070500@redhat.com> <556E5ECC.4080404@oracle.com> Message-ID: <557EA1B2.1070603@redhat.com> On 06/03/2015 03:56 AM, Xuelei Fan wrote: > I can sponsor you for the specification update approval and changeset > integration if needed. I'd really appreciate that. > I still have a few comments about this fix: > > 1. TLS_FALLBACK_SCSV may still be miss-used as it is defined as a > default enabled cipher suites. Are you sure about that? The test case looks for the string "FALLBACK" among the supported and enabled cipher suites, and it's not there. > Some applications may just get all supported cipher suites and enable > them all for a certain circumstance. For example: > > String[] suites = sslSocket.getSupportedCipherSuites(); > sslSocket.setEnabledCipherSuites(suites); > > As would result in unexpected behavior as you concerned about this protocol. I should add further tests to cover this kind of misuse. > What do you think if TLS_FALLBACK_SCSV is not defined as a supported > (enabled) cipher suite? I mean SSLSocket.getSupportedCipherSuites() > would not return TLS_FALLBACK_SCSV in any cases. Right, that's the best behavior. > 2. SSLEngineImpl > Better to update SSLEngineImpl.java in this fix as what you did for > SSLSocketImpl.java I've been trying to write a test case which basically does this InputStream \ / InputStream >-- SSLEngine --< OutputStream / \ OutputStream Essentially reimplementing SSLSocket on top of Socket, using SSLEngine. Do you have a pointer to similar code in OpenJDK? It would also be helpful to people who try to implement more complicated variants of STARTTLS. SSLEngine appears to be quite difficult to use directly. > 3. src/java.base/share/classes/javax/net/ssl/SSLParameters.java > ------------ > 472 * Note: Performing protocol downgrades outside the TLS > 473 * protocol can introduce security vulnerabilities. The > 474 * built-in version negotiation mechanism of the TLS protocol > 475 * should be used instead of explicit protocol downgrades. > 476 * See section 4 of RFC 7507 for additional advice. > > Sounds like it is a part of "implNote". Not as far as I understand the scope of ?implNote?. The note above describes expected application behavior (?call this method if you implement your own fallback?). It's not an implementation detail of the TLS impleemntation. > > ------------ > 478 * @implNote > 479 * The default JSSE provider uses the TLS_FALLBACK_SCSV signaling > 480 * ciphersuite value to indicate protocol fallback, as specified > 481 * in RFC 7507. > > As this is a public spec, any JSSE provider should follow this spec. > I'd like to say: > "A JSSE provider should use the TLS_FALLBACK_SCSV ..." Fine, we can update the spec if the mechanism changes due to TLS 1.3 interop issues. > ------------ > 491 public final void setIndicateProtocolFallback( > boolean indicateFallback) { > 506 public final boolean getIndicateProtocolFallback() > > "setIndicate" does not sound like instinctive enough to me. What do you > think: > void indicateProtocolFallback(boolean useProtocolFallback) > boolean isProtocolFallback() > or > void setUseProtocolFallback(boolean useProtocolFallback) > boolean getUseProtocolFallback() I deliberately used a setter and getter because I thought these standard. The slightly awkward name is due to the fact that it's just a flag send to the server, and it does not cause the TLS implementation to perform the fallback on its own. What about this? public void setProtocolFallbackInProgress(boolean inProgress) {?} public boolean isProtocolFallbackInProgress() {?} -- Florian Weimer / Red Hat Product Security From anthony.scarpino at oracle.com Mon Jun 15 16:50:35 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2015 09:50:35 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <557ABD2E.7050608@redhat.com> References: <557ABD2E.7050608@redhat.com> Message-ID: <557F025B.9010203@oracle.com> [Resent: I dropped the security list by mistake] On 06/12/2015 04:06 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8046943-hs-1/ > http://cr.openjdk.java.net/~aph/8046943-jdk-1/ Please don't use the JEP 246 in the comments when you push. There are a number of changesets related to 246 and I'd rather not have one associated with it. We can link the a separate bug id to the JEP. > > Before: > > rsa 512 bits 0.000134s 0.000009s 7444.2 111853.3 > rsa 1024 bits 0.000674s 0.000029s 1483.9 34456.9 > rsa 2048 bits 0.003945s 0.000100s 253.5 9994.7 > rsa 4096 bits 0.027015s 0.000373s 37.0 2681.6 > > After: > > rsa 512 bits 0.000059s 0.000004s 17022.3 224141.1 > rsa 1024 bits 0.000258s 0.000013s 3871.5 78851.0 > rsa 2048 bits 0.001506s 0.000042s 664.1 23844.3 > rsa 4096 bits 0.010214s 0.000153s 97.9 6516.0 > > There are some issues we need to discuss. > > The runtime code is in sharedRuntime_x86_64.cpp even though it's > mostly written in C. My thinking here is that porters will want to > tweak the code for their back ends, or maybe write it in assembler. > It's little-endian and would need some reworking for big-endian > machines. But maybe there should be a common version of the code in > share/ ? > > Should it be in optoRuntime instead? It could be called from C1 or > even the interpreter, but it's C2-only right now. > > I've done nothing about 32-bit targets, but I think they would > benefit. > > I had to make some small changes to the Java library. > > 1. Montgomery multiplication works on whole words. Given that this > is a 64-bit implementation I had to force the size of the arrays in > oddModPow to be a multiple of 64 bits, i.e. the length of the arrays > must be even. Given that RSA and Diffie-Hellman keys are usually a > multiple of 64 bits in length I don't think this will be a real > performance issue in practice. > > 2. I needed a 64-bit inverse rather than a 32-bit inverse. This is a > single computation, done once for each modular exponentiation, so it > makes an immeasurably small difference to the total runtime. > > 3. I fused squaring and multiplication into a single > montgomeryMultiply method. This has two advantages. Firstly, we only > need a single intrinsic, and secondly the decision whether to use > multiply or squaring can be made in the runtime library. If the > target does not support the montgomeryMultiply intrinsic there is no > slowdown when using C2 because it removes the if (a == b) test in > > if (a == b) { > product = squareToLen(a, len, product); > } else { > product = multiplyToLen(a, len, b, len, product); > } I don't agree with fusing them together. I think there should two separate intrinsics. For one, SPARC has a montsqr and montmul instructions. Additionally if someone wants to call montgomerySquare, they should be able to call it directly with it's needed number of arguments and not pass 'a' twice to satisfy an internal if(). Tony From aph at redhat.com Mon Jun 15 16:58:21 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jun 2015 17:58:21 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <557EFF94.5000006@oracle.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> Message-ID: <557F042D.4060707@redhat.com> On 06/15/2015 05:38 PM, Anthony Scarpino wrote: > On 06/12/2015 04:06 AM, Andrew Haley wrote: >> http://cr.openjdk.java.net/~aph/8046943-hs-1/ >> http://cr.openjdk.java.net/~aph/8046943-jdk-1/ > > Please don't use the JEP 246 in the comments when you push. There are a > number of changesets related to 246 and I'd rather not have one > associated with it. We can link the a separate bug id to the JEP. Right. >> 3. I fused squaring and multiplication into a single >> montgomeryMultiply method. This has two advantages. Firstly, we only >> need a single intrinsic, and secondly the decision whether to use >> multiply or squaring can be made in the runtime library. If the >> target does not support the montgomeryMultiply intrinsic there is no >> slowdown when using C2 because it removes the if (a == b) test in >> >> if (a == b) { >> product = squareToLen(a, len, product); >> } else { >> product = multiplyToLen(a, len, b, len, product); >> } > > I don't agree with fusing them together. I think there should two > separate intrinsics. For one, SPARC has a montsqr and montmul > instructions. Additionally if someone wants to call montgomerySquare, > they should be able to call it directly with it's needed number of > arguments and not pass 'a' twice to satisfy an internal if(). OK, fair enough. I'll think a little more about the best way to do this. Out of curiosity I just had a look at the SPARC instruction specifications, and happily (it certainly surprised me!) they are almost exactly the same as what I've done, so using those instructions should be a trivial change after this patch. The SPARC instruction seems to be limited to 32 words (2048 bits) but I guess you'd just use the software for larger sizes. Andrew. From anthony.scarpino at oracle.com Mon Jun 15 17:06:47 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2015 10:06:47 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <557F042D.4060707@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> Message-ID: <557F0627.40400@oracle.com> On 06/15/2015 09:58 AM, Andrew Haley wrote: > On 06/15/2015 05:38 PM, Anthony Scarpino wrote: >> On 06/12/2015 04:06 AM, Andrew Haley wrote: >>> http://cr.openjdk.java.net/~aph/8046943-hs-1/ >>> http://cr.openjdk.java.net/~aph/8046943-jdk-1/ >> >> Please don't use the JEP 246 in the comments when you push. There are a >> number of changesets related to 246 and I'd rather not have one >> associated with it. We can link the a separate bug id to the JEP. > > Right. > >>> 3. I fused squaring and multiplication into a single >>> montgomeryMultiply method. This has two advantages. Firstly, we only >>> need a single intrinsic, and secondly the decision whether to use >>> multiply or squaring can be made in the runtime library. If the >>> target does not support the montgomeryMultiply intrinsic there is no >>> slowdown when using C2 because it removes the if (a == b) test in >>> >>> if (a == b) { >>> product = squareToLen(a, len, product); >>> } else { >>> product = multiplyToLen(a, len, b, len, product); >>> } >> >> I don't agree with fusing them together. I think there should two >> separate intrinsics. For one, SPARC has a montsqr and montmul >> instructions. Additionally if someone wants to call montgomerySquare, >> they should be able to call it directly with it's needed number of >> arguments and not pass 'a' twice to satisfy an internal if(). > > OK, fair enough. I'll think a little more about the best way to do > this. > > Out of curiosity I just had a look at the SPARC instruction > specifications, and happily (it certainly surprised me!) they are > almost exactly the same as what I've done, so using those instructions > should be a trivial change after this patch. The SPARC instruction > seems to be limited to 32 words (2048 bits) but I guess you'd just use > the software for larger sizes. > > Andrew. > Correct, I was prototyping a SPARC intrinsic in May and we independently had similar methods in BigInteger. At least I believe you had a montgomerySqr and montgomeryMul method in BigInteger back in April/May. The instruction gets tedious getting the data to the instruction and the limitation hurts. Tony From valerie.peng at oracle.com Mon Jun 15 20:54:12 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Jun 2015 13:54:12 -0700 Subject: RFR 8087157: PKCS11 provider not instantiated with security manager Message-ID: <557F3B74.5000904@oracle.com> Sean, Given how trivial this is, I initially covered it in the fix for 7191662. However, fix for 7191662 took longer than anticipated to go in and now SQE has filed a bug for this. Thus, I separated this out into a separate webrev. Can u please take a look? http://cr.openjdk.java.net/~valeriep/8087157/webrev.01/ Thanks, Valerie From anthony.scarpino at oracle.com Mon Jun 15 23:26:12 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2015 16:26:12 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <557B5A47.5090008@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> Message-ID: <557F5F14.70709@oracle.com> Hi other reviewers, I'm hoping someone else can review this. Tony On 06/12/2015 03:16 PM, Vladimir Kozlov wrote: > This implementation looks good to me. You need second review since > changes are big. > > Thanks, > Vladimir > > On 6/11/15 11:01 AM, Anthony Scarpino wrote: >> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I >> had reviewed back in February. >> >> There are two changes from the previous review. One is the separate >> method for the range checking in jdk:GHASH.java in update(). The other >> is disabling UseGHASHIntrinsics for arch64 in hotspot. >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ >> >> thanks >> >> Tony >> From valerie.peng at oracle.com Mon Jun 15 23:58:04 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Jun 2015 16:58:04 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557628F8.8000001@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> Message-ID: <557F668C.5090101@oracle.com> It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. Here is the latest webrev (Security source/test changes only, no more makefile changes) http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ Summary of changes from webrev.03: 1) switch back to provider class names for java.security file 2) separated out the java.policy change into its own as SQE has filed a bug for it 3) updated sun.security.jca.Providers class due to 1) 4) fixed sun.security.tools.jarsigner.Main to use the new Provider.configure() api 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and configuring PKCS11 provider Thanks, Valerie On 6/8/2015 4:44 PM, Valerie Peng wrote: > > What is the bug id for the image refresh change? Just so I can keep a > watch and hold my changes for the time being. > > My webrev has a new regression test which compares the list of > providers found by ServiceLoader and Security.getProviders() call. So, > if the META-INF/services/java.security.Provider file content is not > correct, the new test would fail and it's a clear indication that > ServiceLoader can't find one or more of the providers. > > Thanks, > Valerie > > On 6/5/2015 10:43 PM, Mandy Chung wrote: >>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>> wrote: >>> >>> >>> I don't know image builder well enough to answer your question. >> The current implementation of the image builder sorts the modules by >> their name that are mapped to the same class loader. That explains >> why java.naming is the first one containing >> META-INF/services/java.security.Provider in your current list. >> >> There is no guarantee in what particular order a module is processed >> first. I don?t know if the jimage refresh work will change the >> ordering either. Since this is temporary, I?m okay if you want to >> depend on the image build implementation as long as you have a test >> to catch it and verify >> java.naming/META-INF/services/java.security.Provider file content. >> The existing security tests may also catch it but I think it?s not >> obvious to indicate that the security tests fail because of the issue >> of the merged service configuration file. >> >> Please also hold off until the image refresh change goes into >> jdk9/dev so that you can verify if your build change still works. >> >> If you want to push earlier, another alternative we discussed earlier >> is to separate the META-INF/services file and make change and >> java.security to keep using classname. That can be pushed that in a >> second phase with a proper image builder support. >> >> Mandy >> >>> Based on my own experiment, it seems to pick up the one from >>> java.naming when duplication occurs, so that's why I saved the >>> merged result to there and named the Gensrc makefile with >>> java.naming. The result build work fine. >>> >>> Does this explain what I am trying to do here? If you have better >>> ways to get this done, I am certainly open to that idea. >>> Thanks, >>> Valerie >>> >>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>> Hello Valerie, >>>> >>>> The merging seems ok, but I thought there was non determinism in >>>> the image builder regarding which provider would get picked up. Is >>>> that resolved or do you really need to override all of those >>>> providers with your generated file in gensrc? I can assist in >>>> writing that makefile logic if needed. >>>> >>>> /Erik >>>> >>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>> Build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>> Correct, if the makefile related changes are removed then no need >>>>>> for build team to review 7191662 webrev anymore. >>>>>> There are other discussions ongoing and we should be able to >>>>>> reach a decision in a day or two. >>>>>> Will update the list again. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>> Please find comments in line... >>>>>>>> >>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>> Valerie, >>>>>>>>> >>>>>>>>> Did you see my comment yesterday? >>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> >>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>> your latest one later today. >>>>>>>> >>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>> build change. >>>>>>>>> >>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>> instead of classname. >>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>> loaded through the legacyLoad(). >>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>> file provider loading. Since the current list still uses class >>>>>>>> name, it should take class name when checking for matches while >>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>> required and the providers will be loaded through >>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>> >>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>> goes into jdk9/dev >>>>>>>> Ok. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>> this mean that there's currently no need for a build system code >>>>>>> review on >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>> that a new webrev will be posted instead? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>> Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi, build experts, >>>>>>>>>> >>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>> >>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>> image build. >>>>>>>>>> >>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> (Java Security Team) From john.r.rose at oracle.com Tue Jun 16 00:20:09 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 17:20:09 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <557F5F14.70709@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: Thanks for taking this on. It looks good, except for one thing. The intrinsic does not need to be an instance method, and doing so creates an undesirable coupling between the JVM and JDK. Specifically, the JDK should not need to know about subkeyH and state fields. The Java code should pass those as plain (array long[2]) arguments to the intrinsic method processBlocks, which should be adjusted to be static. The domain check routine should be adjusted to be static also. On my wish list for the future (but not now) is even less coupling with the JVM. The loop code for processBlocks should be written in Java, with various intrinsics (xmulx*) for dealing with single operations on 128-bit values (stored in long[2] boxes and 64-bit registers). The Unsafe misaligned access routines could help simplify this also, if the coding were done in Java. This is not too hard to express in Java and compile to excellent code. There will be a little extra awkwardness working with 64x2-vectors in a way that will compile naturally to a range of ALUs (both 64- and 128-bit). If we get it right we can reduce the amount of assembly code in the JVM and get even more timely access to new data-processing instructions. Would you please file a followup bug (low pri. for now) to track this, at least for GHASH and other crypto loops? ? John On Jun 15, 2015, at 4:26 PM, Anthony Scarpino wrote: > > Hi other reviewers, > > I'm hoping someone else can review this. > > Tony > > On 06/12/2015 03:16 PM, Vladimir Kozlov wrote: >> This implementation looks good to me. You need second review since >> changes are big. >> >> Thanks, >> Vladimir >> >> On 6/11/15 11:01 AM, Anthony Scarpino wrote: >>> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I >>> had reviewed back in February. >>> >>> There are two changes from the previous review. One is the separate >>> method for the range checking in jdk:GHASH.java in update(). The other >>> is disabling UseGHASHIntrinsics for arch64 in hotspot. >>> >>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ >>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ >>> >>> thanks >>> >>> Tony >>> > From xuelei.fan at oracle.com Tue Jun 16 03:49:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Jun 2015 11:49:34 +0800 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <557EA1B2.1070603@redhat.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> <554AA643.4050101@oracle.com> <554AFFB2.6070500@redhat.com> <556E5ECC.4080404@oracle.com> <557EA1B2.1070603@redhat.com> Message-ID: <557F9CCE.5030504@oracle.com> On 6/15/2015 5:58 PM, Florian Weimer wrote: > On 06/03/2015 03:56 AM, Xuelei Fan wrote: > >> I can sponsor you for the specification update approval and changeset >> integration if needed. > > I'd really appreciate that. > >> I still have a few comments about this fix: >> >> 1. TLS_FALLBACK_SCSV may still be miss-used as it is defined as a >> default enabled cipher suites. > > Are you sure about that? The test case looks for the string "FALLBACK" > among the supported and enabled cipher suites, and it's not there. > Ah, I see your point. You defined K_FALLBACK_SCSV as not allowed KeyExchange (line 343), and the cipher suite TLS_FALLBACK_SCSV as not allowed cipher suites (line 1097-1098) although it is in the block of the default enabled cipher suites code. I would like to remove the two updates above as they are not actually allowed to be used. >> Some applications may just get all supported cipher suites and enable >> them all for a certain circumstance. For example: >> >> String[] suites = sslSocket.getSupportedCipherSuites(); >> sslSocket.setEnabledCipherSuites(suites); >> >> As would result in unexpected behavior as you concerned about this protocol. > > I should add further tests to cover this kind of misuse. > >> What do you think if TLS_FALLBACK_SCSV is not defined as a supported >> (enabled) cipher suite? I mean SSLSocket.getSupportedCipherSuites() >> would not return TLS_FALLBACK_SCSV in any cases. > > Right, that's the best behavior. > >> 2. SSLEngineImpl >> Better to update SSLEngineImpl.java in this fix as what you did for >> SSLSocketImpl.java > > I've been trying to write a test case which basically does this > > InputStream \ / InputStream > >-- SSLEngine --< > OutputStream / \ OutputStream > > Essentially reimplementing SSLSocket on top of Socket, using SSLEngine. > > Do you have a pointer to similar code in OpenJDK? See the templates: jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java jdk/test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java > It would also be > helpful to people who try to implement more complicated variants of > STARTTLS. > > SSLEngine appears to be quite difficult to use directly. > It's an AIO programming style. Quite different from socket programming. >> 3. src/java.base/share/classes/javax/net/ssl/SSLParameters.java >> ------------ >> 472 * Note: Performing protocol downgrades outside the TLS >> 473 * protocol can introduce security vulnerabilities. The >> 474 * built-in version negotiation mechanism of the TLS protocol >> 475 * should be used instead of explicit protocol downgrades. >> 476 * See section 4 of RFC 7507 for additional advice. >> >> Sounds like it is a part of "implNote". > > Not as far as I understand the scope of ?implNote?. The note above > describes expected application behavior (?call this method if you > implement your own fallback?). It's not an implementation detail of the > TLS impleemntation. > I see. >> >> ------------ >> 478 * @implNote >> 479 * The default JSSE provider uses the TLS_FALLBACK_SCSV signaling >> 480 * ciphersuite value to indicate protocol fallback, as specified >> 481 * in RFC 7507. >> >> As this is a public spec, any JSSE provider should follow this spec. >> I'd like to say: >> "A JSSE provider should use the TLS_FALLBACK_SCSV ..." > > Fine, we can update the spec if the mechanism changes due to TLS 1.3 > interop issues. > >> ------------ >> 491 public final void setIndicateProtocolFallback( >> boolean indicateFallback) { >> 506 public final boolean getIndicateProtocolFallback() >> >> "setIndicate" does not sound like instinctive enough to me. What do you >> think: >> void indicateProtocolFallback(boolean useProtocolFallback) >> boolean isProtocolFallback() >> or >> void setUseProtocolFallback(boolean useProtocolFallback) >> boolean getUseProtocolFallback() > > I deliberately used a setter and getter because I thought these > standard. My preference, too. > The slightly awkward name is due to the fact that it's just a > flag send to the server, and it does not cause the TLS implementation to > perform the fallback on its own. What about this? > > public void setProtocolFallbackInProgress(boolean inProgress) {?} > public boolean isProtocolFallbackInProgress() {?} > Sounds much better to me, except that the name is really long. What do you think: void setUseProtocolFallbackMode(boolean useProtocolFallbackMode) boolean getUseProtocolFallbackMode() ;-) Only three letters shorter. Or void setProtocolFallbackMode(boolean useProtocolFallbackMode) boolean getProtocolFallbackMode() Thanks, Xuelei From sean.mullan at oracle.com Tue Jun 16 12:51:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jun 2015 08:51:48 -0400 Subject: RFR 8087157: PKCS11 provider not instantiated with security manager In-Reply-To: <557F3B74.5000904@oracle.com> References: <557F3B74.5000904@oracle.com> Message-ID: <55801BE4.5000907@oracle.com> On 06/15/2015 04:54 PM, Valerie Peng wrote: > Sean, > > Given how trivial this is, I initially covered it in the fix for 7191662. > However, fix for 7191662 took longer than anticipated to go in and now > SQE has filed a bug for this. > Thus, I separated this out into a separate webrev. Can u please take a > look? > > http://cr.openjdk.java.net/~valeriep/8087157/webrev.01/ I am pretty sure you don't need to run the test in othervm mode, since jtreg agentvm mode should be able to cleanup/disable the SecurityManager so that the VM can be reused. You could double-check with Jon Gibbons to be sure. Otherwise, looks good. --Sean From aph at redhat.com Tue Jun 16 14:33:40 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Jun 2015 15:33:40 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <557F042D.4060707@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> Message-ID: <558033C4.8040104@redhat.com> On 06/15/2015 05:58 PM, Andrew Haley wrote: >>> 3. I fused squaring and multiplication into a single >>> >> montgomeryMultiply method. ... >> > >> > I don't agree with fusing them together. I think there should two >> > separate intrinsics. For one, SPARC has a montsqr and montmul >> > instructions. Additionally if someone wants to call montgomerySquare, >> > they should be able to call it directly with it's needed number of >> > arguments and not pass 'a' twice to satisfy an internal if(). > OK, fair enough. I'll think a little more about the best way to do > this. Done thusly. The only thing I had any doubt about was whether to use a single flag for squaring and multiplication. This patch uses separate flags. http://cr.openjdk.java.net/~aph/8046943-hs-2/ http://cr.openjdk.java.net/~aph/8046943-jdk-2/ Andrew. From sean.mullan at oracle.com Tue Jun 16 14:54:59 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jun 2015 10:54:59 -0400 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess Message-ID: <558038C3.8000902@oracle.com> This is the sixth in a series of fixes for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8072692 This fix adds several optimizations to the package matching algorithm used by the SecurityManager.checkPackageAcccess method. These improvements result in a 5-7x increase in throughput of this method. A performance chart has been attached to the bug with more information. A new test is included which uses a state machine to verify that the matching algorithm is working correctly. Special thanks to Daniel Fuchs for contributing this fix and the test. Thanks, Sean [1] http://openjdk.java.net/jeps/232 From mandy.chung at oracle.com Tue Jun 16 16:13:19 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Jun 2015 09:13:19 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557F668C.5090101@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> Message-ID: <7A152BA1-336C-40EB-B1AE-BAD31B254436@oracle.com> I skimmed it and looks okay to me. Thanks for separating this build work and avoid interfering the jimage refresh work. Mandy > On Jun 15, 2015, at 4:58 PM, Valerie Peng wrote: > > > It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. > > Here is the latest webrev (Security source/test changes only, no more makefile changes) > http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ > > Summary of changes from webrev.03: > 1) switch back to provider class names for java.security file > 2) separated out the java.policy change into its own as SQE has filed a bug for it > 3) updated sun.security.jca.Providers class due to 1) > 4) fixed sun.security.tools.jarsigner.Main to use the new Provider.configure() api > 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and configuring PKCS11 provider > > Thanks, > Valerie > > On 6/8/2015 4:44 PM, Valerie Peng wrote: >> >> What is the bug id for the image refresh change? Just so I can keep a watch and hold my changes for the time being. >> >> My webrev has a new regression test which compares the list of providers found by ServiceLoader and Security.getProviders() call. So, if the META-INF/services/java.security.Provider file content is not correct, the new test would fail and it's a clear indication that ServiceLoader can't find one or more of the providers. >> >> Thanks, >> Valerie >> >> On 6/5/2015 10:43 PM, Mandy Chung wrote: >>>> On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: >>>> >>>> >>>> I don't know image builder well enough to answer your question. >>> The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. >>> >>> There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. >>> >>> Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. >>> >>> If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. >>> >>> Mandy >>> >>>> Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. >>>> >>>> Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. >>>> Thanks, >>>> Valerie >>>> >>>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>>> Hello Valerie, >>>>> >>>>> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >>>>> >>>>> /Erik >>>>> >>>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>>> Build experts, >>>>>> >>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>>> >>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>>>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>>>>> Will update the list again. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>>> Please find comments in line... >>>>>>>>> >>>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>>> Valerie, >>>>>>>>>> >>>>>>>>>> Did you see my comment yesterday? >>>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>>>>> >>>>>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>>>>> >>>>>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>>>>> >>>>>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>>>>> Ok. >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, build experts, >>>>>>>>>>> >>>>>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>>>>> >>>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> (Java Security Team) From sean.mullan at oracle.com Tue Jun 16 16:23:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jun 2015 12:23:06 -0400 Subject: [9] RFR: 8074784: Additional tests for XML DSig API In-Reply-To: <555CEBA5.30403@oracle.com> References: <55521D03.5000800@oracle.com> <555CE5EF.5030409@oracle.com> <555CEBA5.30403@oracle.com> Message-ID: <55804D6A.9070004@oracle.com> On 05/20/2015 04:16 PM, Artem Smotrakov wrote: > Hi Sean, > > Yes, at first, I thought about updating the existing tests in > test/javax/xml/crypto/dsig directory. But then I noticed that both > GenerationTests and ValidationTests has ~30 test cases. And new > Detached.java test contains >30 test cases. If one of test cases fails, > JTREG will show that full test failed. As a result, it may hide failures > of other test cases (an engineer should look at logs carefully). You could always change that to continue on error and run all tests before reporting a failure. That was just originally the way the test was created, it isn't set in stone. > Also it > may be better to split tests if possible when some tools for automated > failures analysis is used (for example, Java SQE uses such a tool). > > That was the main reason why I added a separate test. Not sure if > performance may be an issue, I have not done any measurement. Yes, but there is still a lot of common infrastructure in this test and ValidationTests that could be combined. You have made use of lambdas and streams to create a nice way to structure and run the different variants of tests. But a detached signature is really just another variant, and I think your test could be easily adapted to also test enveloped and enveloping signatures, as well as the other cases in ValidationTests. So, it would be nice to combine these tests. I would be ok with filing a follow-on issue to do that, though. I noticed a few typos: 151: s/fot/for 332: s/transfrom/transform/ 418: s/validaition/validation/ I also would recommend reordering the imports in alphabetical order. Looks fine otherwise. Thanks, Sean > > Artem > > On 05/20/2015 10:52 PM, Sean Mullan wrote: >> Hi Artem, >> >> Is there a reason this needs to be a separate test? It seems like it >> would be better to fold it into the existing GenerationTests and >> ValidationTests in the test/javax/xml/crypto/dsig directory, so you >> could reuse common code. >> >> Thanks, >> Sean >> >> On 05/12/2015 11:32 AM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review a new test for generating and validation of detached XML >>> digital signatures. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074784 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.00/ >>> >>> Artem > From openjdk at suche.org Tue Jun 16 16:49:00 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 16 Jun 2015 18:49:00 +0200 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <558038C3.8000902@oracle.com> References: <558038C3.8000902@oracle.com> Message-ID: <5580537C.20706@suche.org> Hi, two points that come directly to my mind when i checked the code: 1) An Error in the description. + // If plast >= plen then restrictedPkg is longer than pkg by at + // least one char. This means pkg cannot start with restrictedPkg, + // since restrictedPkg will be longer than pkg. + // + // Similarly if plast != plen, then pkg + "." cannot be the same + // as restrictedPkg, since pkg + "." will have a different length + // than restrictedPkg. If this would be correct then where would never be an match because !(plast >= plen) && !(plast != plen) must be true for an possible match. That could be rewriten to (plast < plen) && (plast == plen) and this is always FALSE. 2) Would it be worth to use the state Engine instead of looping over the array ? Gru? Thomas On 16.06.2015 16:54, Sean Mullan wrote: > This is the sixth in a series of fixes for JEP 232 (Improve Secure > Application Performance) [1]. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8072692 > > This fix adds several optimizations to the package matching algorithm > used by the SecurityManager.checkPackageAcccess method. These > improvements result in a 5-7x increase in throughput of this method. A > performance chart has been attached to the bug with more information. > > A new test is included which uses a state machine to verify that the > matching algorithm is working correctly. > > Special thanks to Daniel Fuchs for contributing this fix and the test. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 From daniel.fuchs at oracle.com Tue Jun 16 17:41:07 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Jun 2015 19:41:07 +0200 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <5580537C.20706@suche.org> References: <558038C3.8000902@oracle.com> <5580537C.20706@suche.org> Message-ID: <55805FB3.90807@oracle.com> On 16/06/15 18:49, Thomas Lu?nig wrote: > Hi, > > two points that come directly to my mind when i checked the code: > > 1) An Error in the description. > > + // If plast >= plen then restrictedPkg is longer than pkg by at > + // least one char. This means pkg cannot start with restrictedPkg, > + // since restrictedPkg will be longer than pkg. > + // > + // Similarly if plast != plen, then pkg + "." cannot be the same > + // as restrictedPkg, since pkg + "." will have a different length > + // than restrictedPkg. > > If this would be correct then where would never be an match because > !(plast >= plen) && !(plast != plen) must be true for an possible match. > That could be rewriten to (plast < plen) && (plast == plen) and this is always FALSE. Hi Thomas - I believe the description is correct: plast >= plen <=> restrictedPkg.length() -1 >= pkg.length() <=> restrictedPkg.length() >= pkg.length() + 1 which does means pkg.startsWith(restrictedPkg) == false plast != plen <=> restrictedPkg.length() -1 != pkg.length() <=> restrictedPkg.length() != pkg.length() + 1 which does means that restrictedPkg.equals(pkg + ".") == false > 2) Would it be worth to use the state Engine instead of looping over the array ? When I investigated the issue I found that using the state engine only brought a marginal improvement - compared to what is proposed here. Given the additional complexity that the state engine brings - I believe that looping over the array is the appropriate choice. The state engine is still in the test in case someone decides one day that the marginal improvements are worthy ;-) best regards, -- daniel > > Gru? Thomas > > > > On 16.06.2015 16:54, Sean Mullan wrote: >> This is the sixth in a series of fixes for JEP 232 (Improve Secure >> Application Performance) [1]. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8072692 >> >> This fix adds several optimizations to the package matching algorithm >> used by the SecurityManager.checkPackageAcccess method. These >> improvements result in a 5-7x increase in throughput of this method. A >> performance chart has been attached to the bug with more information. >> >> A new test is included which uses a state machine to verify that the >> matching algorithm is working correctly. >> >> Special thanks to Daniel Fuchs for contributing this fix and the test. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 > From sean.mullan at oracle.com Tue Jun 16 20:34:17 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jun 2015 16:34:17 -0400 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557F668C.5090101@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> Message-ID: <55808849.5080800@oracle.com> On 06/15/2015 07:58 PM, Valerie Peng wrote: > > It seems that the jimage refresh change may still take some time, so we > will end up removing the makefile related changes and then deferring the > ServiceLoader related changes to Jake workspace. > > Here is the latest webrev (Security source/test changes only, no more > makefile changes) > http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ > > Summary of changes from webrev.03: > 1) switch back to provider class names for java.security file Why is there an entry for security.provider.tbd=sun.security.pkcs11.SunPKCS11 on line 90? > 2) separated out the java.policy change into its own as SQE has filed a > bug for it > 3) updated sun.security.jca.Providers class due to 1) > 4) fixed sun.security.tools.jarsigner.Main to use the new > Provider.configure() api > 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and > configuring PKCS11 provider Looks fine otherwise. --Sean > > Thanks, > Valerie > > On 6/8/2015 4:44 PM, Valerie Peng wrote: >> >> What is the bug id for the image refresh change? Just so I can keep a >> watch and hold my changes for the time being. >> >> My webrev has a new regression test which compares the list of >> providers found by ServiceLoader and Security.getProviders() call. So, >> if the META-INF/services/java.security.Provider file content is not >> correct, the new test would fail and it's a clear indication that >> ServiceLoader can't find one or more of the providers. >> >> Thanks, >> Valerie >> >> On 6/5/2015 10:43 PM, Mandy Chung wrote: >>>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>>> wrote: >>>> >>>> >>>> I don't know image builder well enough to answer your question. >>> The current implementation of the image builder sorts the modules by >>> their name that are mapped to the same class loader. That explains >>> why java.naming is the first one containing >>> META-INF/services/java.security.Provider in your current list. >>> >>> There is no guarantee in what particular order a module is processed >>> first. I don?t know if the jimage refresh work will change the >>> ordering either. Since this is temporary, I?m okay if you want to >>> depend on the image build implementation as long as you have a test >>> to catch it and verify >>> java.naming/META-INF/services/java.security.Provider file content. >>> The existing security tests may also catch it but I think it?s not >>> obvious to indicate that the security tests fail because of the issue >>> of the merged service configuration file. >>> >>> Please also hold off until the image refresh change goes into >>> jdk9/dev so that you can verify if your build change still works. >>> >>> If you want to push earlier, another alternative we discussed earlier >>> is to separate the META-INF/services file and make change and >>> java.security to keep using classname. That can be pushed that in a >>> second phase with a proper image builder support. >>> >>> Mandy >>> >>>> Based on my own experiment, it seems to pick up the one from >>>> java.naming when duplication occurs, so that's why I saved the >>>> merged result to there and named the Gensrc makefile with >>>> java.naming. The result build work fine. >>>> >>>> Does this explain what I am trying to do here? If you have better >>>> ways to get this done, I am certainly open to that idea. >>>> Thanks, >>>> Valerie >>>> >>>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>>> Hello Valerie, >>>>> >>>>> The merging seems ok, but I thought there was non determinism in >>>>> the image builder regarding which provider would get picked up. Is >>>>> that resolved or do you really need to override all of those >>>>> providers with your generated file in gensrc? I can assist in >>>>> writing that makefile logic if needed. >>>>> >>>>> /Erik >>>>> >>>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>>> Build experts, >>>>>> >>>>>> Can you please review the make file related change, i.e. the new >>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>>> >>>>>> This is for merging the java.security.Provider file from various >>>>>> providers and use the (merged) result for the final image build. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>>> Correct, if the makefile related changes are removed then no need >>>>>>> for build team to review 7191662 webrev anymore. >>>>>>> There are other discussions ongoing and we should be able to >>>>>>> reach a decision in a day or two. >>>>>>> Will update the list again. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>>> Please find comments in line... >>>>>>>>> >>>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>>> Valerie, >>>>>>>>>> >>>>>>>>>> Did you see my comment yesterday? >>>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>>> >>>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>>> your latest one later today. >>>>>>>>> >>>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>>> build change. >>>>>>>>>> >>>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>>> instead of classname. >>>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>>> loaded through the legacyLoad(). >>>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>>> file provider loading. Since the current list still uses class >>>>>>>>> name, it should take class name when checking for matches while >>>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>>> required and the providers will be loaded through >>>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>>> >>>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>>> goes into jdk9/dev >>>>>>>>> Ok. >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>>> this mean that there's currently no need for a build system code >>>>>>>> review on >>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>>> that a new webrev will be posted instead? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>>> Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, build experts, >>>>>>>>>>> >>>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>>> image build. >>>>>>>>>>> >>>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> (Java Security Team) From weijun.wang at oracle.com Wed Jun 17 00:42:26 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jun 2015 08:42:26 +0800 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <558038C3.8000902@oracle.com> References: <558038C3.8000902@oracle.com> Message-ID: <5580C272.60407@oracle.com> 1478 final int plast = restrictedPkg.length() - 1; Why is it named plast? 1494 // - we check that restrictedPkg.length is pkg.length + 1, 1495 // - we check that restrictedPkg starts with pkg, 1496 // - and we check that the last character in restrictedPkg 1497 // is '.' Seems redundant. The check below is not difficult to read. Also, is checking the "." at the end of restrictedPkg useful? On the one hand we know every item in package.access should always end with it. On the other hand, if someone really adds a "sun" there, the 1st part of the check could go wrong (For example, "sunw" matches). IMHO, either we don't check it at all (hoping property is always set correctly), or we always check for it (cover both "sun.tail" and "sun"). Thanks Max On 06/16/2015 10:54 PM, Sean Mullan wrote: > This is the sixth in a series of fixes for JEP 232 (Improve Secure > Application Performance) [1]. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8072692 > > This fix adds several optimizations to the package matching algorithm > used by the SecurityManager.checkPackageAcccess method. These > improvements result in a 5-7x increase in throughput of this method. A > performance chart has been attached to the bug with more information. > > A new test is included which uses a state machine to verify that the > matching algorithm is working correctly. > > Special thanks to Daniel Fuchs for contributing this fix and the test. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 From valerie.peng at oracle.com Wed Jun 17 02:40:40 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 16 Jun 2015 19:40:40 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55808849.5080800@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> <55808849.5080800@oracle.com> Message-ID: <5580DE28.2000807@oracle.com> It's to make the runtime configuration of 3rd party PKCS11 provider easier on non-Solaris systems. With this entry, callers can simply do Security.getProvider("SunPKCS11") and then call Provider.configure with their own configuration file. Otherwise, they will have to use reflection, e.g. Class.forName("sun.security.pkcs11.SunPKCS11") and then call its newInstance() method and then call Provider.configure method. Or, iteration through the ServiceLoader until the SunPKCS11 provider is found. Both doesn't seem very user-friendly in my view. Valerie On 6/16/2015 1:34 PM, Sean Mullan wrote: > On 06/15/2015 07:58 PM, Valerie Peng wrote: >> >> It seems that the jimage refresh change may still take some time, so we >> will end up removing the makefile related changes and then deferring the >> ServiceLoader related changes to Jake workspace. >> >> Here is the latest webrev (Security source/test changes only, no more >> makefile changes) >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ >> >> Summary of changes from webrev.03: >> 1) switch back to provider class names for java.security file > > Why is there an entry for > security.provider.tbd=sun.security.pkcs11.SunPKCS11 on line 90? > >> 2) separated out the java.policy change into its own as SQE has filed a >> bug for it >> 3) updated sun.security.jca.Providers class due to 1) >> 4) fixed sun.security.tools.jarsigner.Main to use the new >> Provider.configure() api >> 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and >> configuring PKCS11 provider > > Looks fine otherwise. > > --Sean > >> >> Thanks, >> Valerie >> >> On 6/8/2015 4:44 PM, Valerie Peng wrote: >>> >>> What is the bug id for the image refresh change? Just so I can keep a >>> watch and hold my changes for the time being. >>> >>> My webrev has a new regression test which compares the list of >>> providers found by ServiceLoader and Security.getProviders() call. So, >>> if the META-INF/services/java.security.Provider file content is not >>> correct, the new test would fail and it's a clear indication that >>> ServiceLoader can't find one or more of the providers. >>> >>> Thanks, >>> Valerie >>> >>> On 6/5/2015 10:43 PM, Mandy Chung wrote: >>>>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>>>> wrote: >>>>> >>>>> >>>>> I don't know image builder well enough to answer your question. >>>> The current implementation of the image builder sorts the modules by >>>> their name that are mapped to the same class loader. That explains >>>> why java.naming is the first one containing >>>> META-INF/services/java.security.Provider in your current list. >>>> >>>> There is no guarantee in what particular order a module is processed >>>> first. I don?t know if the jimage refresh work will change the >>>> ordering either. Since this is temporary, I?m okay if you want to >>>> depend on the image build implementation as long as you have a test >>>> to catch it and verify >>>> java.naming/META-INF/services/java.security.Provider file content. >>>> The existing security tests may also catch it but I think it?s not >>>> obvious to indicate that the security tests fail because of the issue >>>> of the merged service configuration file. >>>> >>>> Please also hold off until the image refresh change goes into >>>> jdk9/dev so that you can verify if your build change still works. >>>> >>>> If you want to push earlier, another alternative we discussed earlier >>>> is to separate the META-INF/services file and make change and >>>> java.security to keep using classname. That can be pushed that in a >>>> second phase with a proper image builder support. >>>> >>>> Mandy >>>> >>>>> Based on my own experiment, it seems to pick up the one from >>>>> java.naming when duplication occurs, so that's why I saved the >>>>> merged result to there and named the Gensrc makefile with >>>>> java.naming. The result build work fine. >>>>> >>>>> Does this explain what I am trying to do here? If you have better >>>>> ways to get this done, I am certainly open to that idea. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>>>> Hello Valerie, >>>>>> >>>>>> The merging seems ok, but I thought there was non determinism in >>>>>> the image builder regarding which provider would get picked up. Is >>>>>> that resolved or do you really need to override all of those >>>>>> providers with your generated file in gensrc? I can assist in >>>>>> writing that makefile logic if needed. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>>>> Build experts, >>>>>>> >>>>>>> Can you please review the make file related change, i.e. the new >>>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>>>> >>>>>>> This is for merging the java.security.Provider file from various >>>>>>> providers and use the (merged) result for the final image build. >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>>>> Correct, if the makefile related changes are removed then no need >>>>>>>> for build team to review 7191662 webrev anymore. >>>>>>>> There are other discussions ongoing and we should be able to >>>>>>>> reach a decision in a day or two. >>>>>>>> Will update the list again. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>>>> Please find comments in line... >>>>>>>>>> >>>>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>>>> Valerie, >>>>>>>>>>> >>>>>>>>>>> Did you see my comment yesterday? >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>>>> your latest one later today. >>>>>>>>>> >>>>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>>>> build change. >>>>>>>>>>> >>>>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>>>> instead of classname. >>>>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>>>> loaded through the legacyLoad(). >>>>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>>>> file provider loading. Since the current list still uses class >>>>>>>>>> name, it should take class name when checking for matches while >>>>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>>>> required and the providers will be loaded through >>>>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>>>> >>>>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>>>> goes into jdk9/dev >>>>>>>>>> Ok. >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>>>> this mean that there's currently no need for a build system code >>>>>>>>> review on >>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>>>> that a new webrev will be posted instead? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>>>> Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, build experts, >>>>>>>>>>>> >>>>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>>>> image build. >>>>>>>>>>>> >>>>>>>>>>>> The rest of source code changes are reviewed by my team >>>>>>>>>>>> already. >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> (Java Security Team) From daniel.fuchs at oracle.com Wed Jun 17 07:27:50 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Jun 2015 09:27:50 +0200 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <5580C272.60407@oracle.com> References: <558038C3.8000902@oracle.com> <5580C272.60407@oracle.com> Message-ID: <55812176.6060305@oracle.com> Hi Max, On 6/17/15 2:42 AM, Weijun Wang wrote: > 1478 final int plast = restrictedPkg.length() - 1; > > Why is it named plast? Right. That's a bad name. Maybe 'rlast' would be more appropriate. Any better name for 'the index of the last character in restrictedPkg'? > > 1494 // - we check that restrictedPkg.length is pkg.length + 1, > 1495 // - we check that restrictedPkg starts with pkg, > 1496 // - and we check that the last character in restrictedPkg > 1497 // is '.' > > Seems redundant. The check below is not difficult to read. > > Also, is checking the "." at the end of restrictedPkg useful? On the > one hand we know every item in package.access should always end with > it. On the other hand, if someone really adds a "sun" there, the 1st > part of the check could go wrong (For example, "sunw" matches). IMHO, > either we don't check it at all (hoping property is always set > correctly), or we always check for it (cover both "sun.tail" and "sun"). Possibly - but that would be a behavioral change. The current test: plast == plen && restrictedPkg.startsWith(pkg) && restrictedPkg.charAt(plast) == '.' is strictly equivalent to the old test: restrictedPkg.equals(pkg + ".") (side note: pkg + "." was the root of the perf issue). best regards, -- daniel > > Thanks > Max > > On 06/16/2015 10:54 PM, Sean Mullan wrote: >> This is the sixth in a series of fixes for JEP 232 (Improve Secure >> Application Performance) [1]. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8072692 >> >> This fix adds several optimizations to the package matching algorithm >> used by the SecurityManager.checkPackageAcccess method. These >> improvements result in a 5-7x increase in throughput of this method. A >> performance chart has been attached to the bug with more information. >> >> A new test is included which uses a state machine to verify that the >> matching algorithm is working correctly. >> >> Special thanks to Daniel Fuchs for contributing this fix and the test. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 17 08:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Jun 2015 09:34:12 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557F668C.5090101@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> Message-ID: <55813104.7050109@oracle.com> On 16/06/2015 00:58, Valerie Peng wrote: > > It seems that the jimage refresh change may still take some time, so > we will end up removing the makefile related changes and then > deferring the ServiceLoader related changes to Jake workspace. > > Here is the latest webrev (Security source/test changes only, no more > makefile changes) > http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ > > Summary of changes from webrev.03: > 1) switch back to provider class names for java.security file > 2) separated out the java.policy change into its own as SQE has filed > a bug for it > 3) updated sun.security.jca.Providers class due to 1) > 4) fixed sun.security.tools.jarsigner.Main to use the new > Provider.configure() api > 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching > and configuring PKCS11 provider I'm also happy with dropping the make file changes and the META-INF/services files from this patch. Not for this patch but at some point I think we should re-examine the javadoc in Provider to make it clearer how it can be deployed as a service provider. Specifically the wording "A provider normally identifies itself with a file named java.security.Provider in the resource directory META-INF/services" could be re-examined. -Alan. From sean.mullan at oracle.com Wed Jun 17 12:06:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Jun 2015 08:06:10 -0400 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <55812176.6060305@oracle.com> References: <558038C3.8000902@oracle.com> <5580C272.60407@oracle.com> <55812176.6060305@oracle.com> Message-ID: <558162B2.1040902@oracle.com> On 06/17/2015 03:27 AM, Daniel Fuchs wrote: > Hi Max, > > On 6/17/15 2:42 AM, Weijun Wang wrote: >> 1478 final int plast = restrictedPkg.length() - 1; >> >> Why is it named plast? > > Right. That's a bad name. Maybe 'rlast' would be more appropriate. > Any better name for 'the index of the last character in restrictedPkg'? rlast seems ok to me. I will change it. >> 1494 // - we check that restrictedPkg.length is pkg.length + 1, >> 1495 // - we check that restrictedPkg starts with pkg, >> 1496 // - and we check that the last character in restrictedPkg >> 1497 // is '.' >> >> Seems redundant. The check below is not difficult to read. Ok, I will remove those lines. >> Also, is checking the "." at the end of restrictedPkg useful? On the >> one hand we know every item in package.access should always end with >> it. On the other hand, if someone really adds a "sun" there, the 1st >> part of the check could go wrong (For example, "sunw" matches). IMHO, >> either we don't check it at all (hoping property is always set >> correctly), or we always check for it (cover both "sun.tail" and "sun"). > > Possibly - but that would be a behavioral change. The current test: > > plast == plen && restrictedPkg.startsWith(pkg) && restrictedPkg.charAt(plast) == '.' > > > is strictly equivalent to the old test: > > restrictedPkg.equals(pkg + ".") Right, and this is an interesting observation. However, because it is a behavior change and there may be potential compatibility issues, I think we should open a separate issue to do that. Any other comments, Max? --Sean > > > (side note: pkg + "." was the root of the perf issue). > > > best regards, > > -- daniel > >> >> Thanks >> Max >> >> On 06/16/2015 10:54 PM, Sean Mullan wrote: >>> This is the sixth in a series of fixes for JEP 232 (Improve Secure >>> Application Performance) [1]. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8072692 >>> >>> This fix adds several optimizations to the package matching algorithm >>> used by the SecurityManager.checkPackageAcccess method. These >>> improvements result in a 5-7x increase in throughput of this method. A >>> performance chart has been attached to the bug with more information. >>> >>> A new test is included which uses a state machine to verify that the >>> matching algorithm is working correctly. >>> >>> Special thanks to Daniel Fuchs for contributing this fix and the test. >>> >>> Thanks, >>> Sean >>> >>> [1] http://openjdk.java.net/jeps/232 > From weijun.wang at oracle.com Wed Jun 17 12:42:21 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jun 2015 20:42:21 +0800 Subject: RFR: 8072692: Improve performance of SecurityManager.checkPackageAccess In-Reply-To: <558162B2.1040902@oracle.com> References: <558038C3.8000902@oracle.com> <5580C272.60407@oracle.com> <55812176.6060305@oracle.com> <558162B2.1040902@oracle.com> Message-ID: <55816B2D.3030300@oracle.com> >> >> Possibly - but that would be a behavioral change. The current test: >> >> plast == plen && restrictedPkg.startsWith(pkg) && >> restrictedPkg.charAt(plast) == '.' >> >> >> is strictly equivalent to the old test: >> >> restrictedPkg.equals(pkg + ".") Yes, I understand. > > Right, and this is an interesting observation. However, because it is a > behavior change and there may be potential compatibility issues, I think > we should open a separate issue to do that. Agreed. > > Any other comments, Max? None. Thanks Max > > --Sean > >> >> >> (side note: pkg + "." was the root of the perf issue). >> >> >> best regards, >> >> -- daniel >> >>> >>> Thanks >>> Max >>> >>> On 06/16/2015 10:54 PM, Sean Mullan wrote: >>>> This is the sixth in a series of fixes for JEP 232 (Improve Secure >>>> Application Performance) [1]. >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072692/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8072692 >>>> >>>> This fix adds several optimizations to the package matching algorithm >>>> used by the SecurityManager.checkPackageAcccess method. These >>>> improvements result in a 5-7x increase in throughput of this method. A >>>> performance chart has been attached to the bug with more information. >>>> >>>> A new test is included which uses a state machine to verify that the >>>> matching algorithm is working correctly. >>>> >>>> Special thanks to Daniel Fuchs for contributing this fix and the test. >>>> >>>> Thanks, >>>> Sean >>>> >>>> [1] http://openjdk.java.net/jeps/232 >> From weijun.wang at oracle.com Wed Jun 17 16:25:41 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jun 2015 00:25:41 +0800 Subject: RFR 8064890: SecureClassLoader should use a ConcurrentHashMap Message-ID: <55819F85.9060500@oracle.com> This fix is also a part for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~weijun/8064890/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8064890 The fix uses a ConcurrentHashMap to avoid synchronization. Note: 1. ConcurrentHashMap does not accept null keys. 2. Lambda cannot be used at such an early stage. Noreg-cleanup. Thanks Max [1] http://openjdk.java.net/jeps/232 From anthony.scarpino at oracle.com Wed Jun 17 17:40:43 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jun 2015 10:40:43 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: <5581B11B.3050903@oracle.com> On 06/15/2015 05:20 PM, John Rose wrote: > Thanks for taking this on. > > It looks good, except for one thing. The intrinsic does not need to be > an instance method, and doing so creates an undesirable coupling between > the JVM and JDK. Specifically, the JDK should not need to know about > subkeyH and state fields. The Java code should pass those as plain > (array long[2]) arguments to the intrinsic method processBlocks, which > should be adjusted to be static. The domain check routine should be > adjusted to be static also. > > On my wish list for the future (but not now) is even less coupling > with the JVM. The loop code for processBlocks should be written in Java, > with various intrinsics (xmulx*) for dealing with single operations on > 128-bit values (stored in long[2] boxes and 64-bit registers). I forgot the exact numbers, but having the loop in assembly instead of java resulted in about 10-15% performance improvement. The tighter loop was definitely beneficial. > The > Unsafe misaligned access routines could help simplify this also, if the > coding were done in Java. This is not too hard to express in Java and > compile to excellent code. There will be a little extra awkwardness > working with 64x2-vectors in a way that will compile naturally to a > range of ALUs (both 64- and 128-bit). I would have to look back at that again.. At first I was going to use Unsafe, but it seemed more complicated coding-wise compared to the assembly I saw that was in AES and SHA already. > If we get it right we can reduce > the amount of assembly code in the JVM and get even more timely access > to new data-processing instructions. Would you please file a followup > bug (low pri. for now) to track this, at least for GHASH and other > crypto loops? > > ? John Sure, I can file them. Tony From john.r.rose at oracle.com Wed Jun 17 18:40:22 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Jun 2015 11:40:22 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581B11B.3050903@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581B11B.3050903@oracle.com> Message-ID: On Jun 17, 2015, at 10:40 AM, Anthony Scarpino wrote: > > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to be >> an instance method, and doing so creates an undesirable coupling between >> the JVM and JDK. Specifically, the JDK should not need to know about >> subkeyH and state fields. The Java code should pass those as plain >> (array long[2]) arguments to the intrinsic method processBlocks, which >> should be adjusted to be static. The domain check routine should be >> adjusted to be static also. >> >> On my wish list for the future (but not now) is even less coupling >> with the JVM. The loop code for processBlocks should be written in Java, >> with various intrinsics (xmulx*) for dealing with single operations on >> 128-bit values (stored in long[2] boxes and 64-bit registers). > > I forgot the exact numbers, but having the loop in assembly instead of java resulted in about 10-15% performance improvement. The tighter loop was definitely beneficial. That's good information; please put it in the RFE. IMO the best (overall) way to get that 10-15% back is to get the JIT to tighten the loop. If that works, it will of course benefit all Java loops. > The >> Unsafe misaligned access routines could help simplify this also, if the >> coding were done in Java. This is not too hard to express in Java and >> compile to excellent code. There will be a little extra awkwardness >> working with 64x2-vectors in a way that will compile naturally to a >> range of ALUs (both 64- and 128-bit). > > I would have to look back at that again.. At first I was going to use Unsafe, but it seemed more complicated coding-wise compared to the assembly I saw that was in AES and SHA already. Yes; that makes perfect sense. I want to get to the place, eventually, when the next coder looks at how "stuff gets done", they will see less assembly and more Java, and take the Java route. > >> If we get it right we can reduce >> the amount of assembly code in the JVM and get even more timely access >> to new data-processing instructions. Would you please file a followup >> bug (low pri. for now) to track this, at least for GHASH and other >> crypto loops? >> >> ? John > > Sure, I can file them. Good; thanks. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jun 17 20:08:53 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Jun 2015 16:08:53 -0400 Subject: RFR 8064890: SecureClassLoader should use a ConcurrentHashMap In-Reply-To: <55819F85.9060500@oracle.com> References: <55819F85.9060500@oracle.com> Message-ID: <5581D3D5.8040209@oracle.com> On line 222, I would probably name the parameter "key" instead of "dummy" since that is what it is, even though it is not used. Looks good otherwise. Thanks, Sean On 06/17/2015 12:25 PM, Weijun Wang wrote: > This fix is also a part for JEP 232 (Improve Secure Application > Performance) [1]. > > webrev: http://cr.openjdk.java.net/~weijun/8064890/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8064890 > > The fix uses a ConcurrentHashMap to avoid synchronization. > > Note: > > 1. ConcurrentHashMap does not accept null keys. > > 2. Lambda cannot be used at such an early stage. > > Noreg-cleanup. > > Thanks > Max > > > [1] http://openjdk.java.net/jeps/232 From anthony.scarpino at oracle.com Wed Jun 17 22:31:44 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jun 2015 15:31:44 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: <5581F550.3080403@oracle.com> On 06/15/2015 05:20 PM, John Rose wrote: > Thanks for taking this on. > > It looks good, except for one thing. The intrinsic does not need to > be an instance method, and doing so creates an undesirable coupling > between the JVM and JDK. Specifically, the JDK should not need to > know about subkeyH and state fields. The Java code should pass those > as plain (array long[2]) arguments to the intrinsic method > processBlocks, which should be adjusted to be static. The domain > check routine should be adjusted to be static also. > Hi John, the updated webrevs are at: http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ thanks Tony From rajan.halade at oracle.com Wed Jun 17 23:00:14 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 17 Jun 2015 16:00:14 -0700 Subject: RFR: 8060103: CheckBlacklistedCerts.java thinks its openjdk build Message-ID: <5581FBFE.4010407@oracle.com> May I request you to review small fix to CheckBlacklistedCerts test to correctly determine if OpenJDK build is used. Webrev: http://cr.openjdk.java.net/~rhalade/8060103/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8060103 Thanks, Rajan From john.r.rose at oracle.com Wed Jun 17 23:06:40 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Jun 2015 16:06:40 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581F550.3080403@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581F550.3080403@oracle.com> Message-ID: Thumbs up. Thanks! ? John On Jun 17, 2015, at 3:31 PM, Anthony Scarpino wrote: > > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to >> be an instance method, and doing so creates an undesirable coupling >> between the JVM and JDK. Specifically, the JDK should not need to >> know about subkeyH and state fields. The Java code should pass those >> as plain (array long[2]) arguments to the intrinsic method >> processBlocks, which should be adjusted to be static. The domain >> check routine should be adjusted to be static also. >> > > Hi John, > > the updated webrevs are at: > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ > > thanks > > Tony > From vladimir.kozlov at oracle.com Wed Jun 17 23:40:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Jun 2015 16:40:37 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581F550.3080403@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581F550.3080403@oracle.com> Message-ID: <55820575.3040706@oracle.com> Looks good to me too. Please, push into jdk9/hs-comp so we get testing of intrinsic in Hotspot nightly testing. Thanks, Vladimir On 6/17/15 3:31 PM, Anthony Scarpino wrote: > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to >> be an instance method, and doing so creates an undesirable coupling >> between the JVM and JDK. Specifically, the JDK should not need to >> know about subkeyH and state fields. The Java code should pass those >> as plain (array long[2]) arguments to the intrinsic method >> processBlocks, which should be adjusted to be static. The domain >> check routine should be adjusted to be static also. >> > > Hi John, > > the updated webrevs are at: > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ > > thanks > > Tony > From weijun.wang at oracle.com Thu Jun 18 03:00:45 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jun 2015 11:00:45 +0800 Subject: RFR: 8060103: CheckBlacklistedCerts.java thinks its openjdk build In-Reply-To: <5581FBFE.4010407@oracle.com> References: <5581FBFE.4010407@oracle.com> Message-ID: <5582345D.5040909@oracle.com> Change looks fine. Thanks Max On 6/18/2015 7:00 AM, Rajan Halade wrote: > May I request you to review small fix to CheckBlacklistedCerts test to > correctly determine if OpenJDK build is used. > > Webrev: http://cr.openjdk.java.net/~rhalade/8060103/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8060103 > > Thanks, > Rajan From weijun.wang at oracle.com Thu Jun 18 07:21:31 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jun 2015 15:21:31 +0800 Subject: Please review CR 8050409: Test for JAAS getPrivateCredentials In-Reply-To: <54EE36A1.5020802@oracle.com> References: <54EE36A1.5020802@oracle.com> Message-ID: <5582717B.90005@oracle.com> Hi Amanda The test looks fine. Thanks Max On 2/26/2015 4:54 AM, Amanda Jiang wrote: > Hi All, > > Could you please review following changeset, which includes one new test > to test permission checks with Subject.getPrivateCredentials. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050409 > Webrev:http://cr.openjdk.java.net/~tyan/amandaj/8050409/webrev.02/ > > Thanks, > Amanda > From anthony.scarpino at oracle.com Thu Jun 18 17:00:38 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 18 Jun 2015 10:00:38 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <558033C4.8040104@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> Message-ID: <5582F936.5020008@oracle.com> On 06/16/2015 07:33 AM, Andrew Haley wrote: > On 06/15/2015 05:58 PM, Andrew Haley wrote: >>>> 3. I fused squaring and multiplication into a single >>>>>> montgomeryMultiply method. ... >>>> >>>> I don't agree with fusing them together. I think there should two >>>> separate intrinsics. For one, SPARC has a montsqr and montmul >>>> instructions. Additionally if someone wants to call montgomerySquare, >>>> they should be able to call it directly with it's needed number of >>>> arguments and not pass 'a' twice to satisfy an internal if(). > >> OK, fair enough. I'll think a little more about the best way to do >> this. > > Done thusly. The only thing I had any doubt about was whether to use a > single flag for squaring and multiplication. This patch uses separate > flags. > > http://cr.openjdk.java.net/~aph/8046943-hs-2/ > http://cr.openjdk.java.net/~aph/8046943-jdk-2/ > > Andrew. > I'm happy with the jdk change.. thanks.. Question, on the hotspot side you said in a previous post this was C2-only. Was there a reason you don't have it for all? Personally I'd enable it for all unless there was a performance hit in a particular mode. Tony From aph at redhat.com Thu Jun 18 17:07:22 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Jun 2015 18:07:22 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <5582F936.5020008@oracle.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> Message-ID: <5582FACA.4060103@redhat.com> On 06/18/2015 06:00 PM, Anthony Scarpino wrote: > Question, on the hotspot side you said in a previous post this was > C2-only. Was there a reason you don't have it for all? None. It's up for negotiation. What do you want? C1, interp? Andrew. From anthony.scarpino at oracle.com Thu Jun 18 17:20:10 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 18 Jun 2015 10:20:10 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <5582FACA.4060103@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> Message-ID: <5582FDCA.8010507@oracle.com> On 06/18/2015 10:07 AM, Andrew Haley wrote: > On 06/18/2015 06:00 PM, Anthony Scarpino wrote: >> Question, on the hotspot side you said in a previous post this was >> C2-only. Was there a reason you don't have it for all? > > None. It's up for negotiation. What do you want? C1, interp? > > Andrew. > I'd defer to the hotspot guys on what's best. I'm just not aware of any purposeful limitations of AES, SHA, and GHASH intrinsics, none of these are in the c2_globals.hpp file, so I'm assuming that's what controlling the c2-only. Tony From sean.mullan at oracle.com Thu Jun 18 19:24:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Jun 2015 15:24:10 -0400 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <5580DE28.2000807@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> <55808849.5080800@oracle.com> <5580DE28.2000807@oracle.com> Message-ID: <55831ADA.7050501@oracle.com> On 06/16/2015 10:40 PM, Valerie Peng wrote: > It's to make the runtime configuration of 3rd party PKCS11 provider > easier on non-Solaris systems. > > With this entry, callers can simply do Security.getProvider("SunPKCS11") > and then call Provider.configure with their own configuration file. > Otherwise, they will have to use reflection, e.g. > Class.forName("sun.security.pkcs11.SunPKCS11") and then call its > newInstance() method and then call Provider.configure method. Or, > iteration through the ServiceLoader until the SunPKCS11 provider is > found. Both doesn't seem very user-friendly in my view. Agreed, I also think this will provide a better out-of-the-box experience as it avoids having to modify/override the java.security file to add a PKCS11 provider on non-Solaris platforms. --Sean From vladimir.kozlov at oracle.com Thu Jun 18 19:28:08 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jun 2015 12:28:08 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <5582FDCA.8010507@oracle.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> Message-ID: <55831BC8.9060001@oracle.com> Andrew, We have few new rules regarding intrinsics. You need to add private static java method which does range checks because their are not executed in intrinsic code - see squareToLen() implementation, for example. Note, we will rewrite multiplyToLen() too soon. Also method which will be intrinsified should be private static too and you can move allocation from it (like we did for squareToLen()) to avoid allocation in intrinsic code. Your Hotspot changes are hard to accept. We have to compile for solaris with Sun compilers which does not work with such changes: "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3525: Warning: parameter in inline asm statement unused: %3. "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3525: Warning: parameter in inline asm statement unused: %6. "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3701: Error: The function "__builtin_expect" must have a prototype. "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3707: Error: The function "__builtin_alloca" must have a prototype. May be you can convert the code to stub and add new MacroAssembler functions which you can use in sharedRuntime_x86_64.cpp. Yes, it is a lot of handwriting but we need it to work on all OSs. Also on Solaris you can add asm code similar what we do in solaris_x86_64.il. It may allow you to rewrite to assembler stub. Or don't do this intrinsic on Solaris (only linux and Mac). Regards, Vladimir On 6/18/15 10:20 AM, Anthony Scarpino wrote: > On 06/18/2015 10:07 AM, Andrew Haley wrote: >> On 06/18/2015 06:00 PM, Anthony Scarpino wrote: >>> Question, on the hotspot side you said in a previous post this was >>> C2-only. Was there a reason you don't have it for all? >> >> None. It's up for negotiation. What do you want? C1, interp? >> >> Andrew. >> > > I'd defer to the hotspot guys on what's best. I'm just not aware of any > purposeful limitations of AES, SHA, and GHASH intrinsics, none of these > are in the c2_globals.hpp file, so I'm assuming that's what controlling > the c2-only. > > Tony > From valerie.peng at oracle.com Thu Jun 18 21:44:34 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 18 Jun 2015 14:44:34 -0700 Subject: RFR 8087157: PKCS11 provider not instantiated with security manager In-Reply-To: <55801BE4.5000907@oracle.com> References: <557F3B74.5000904@oracle.com> <55801BE4.5000907@oracle.com> Message-ID: <55833BC2.8080203@oracle.com> Well, the othervm mode is needed not because of the cleanup/disable of SecurityManager, but to ensure that SunPKCS11 provider is created under a SecurityManager. Without the othervm mode, the test will always pass even if the necessary permission is not in java.policy because SunPKCS11 provider is already created and present when this test is run. This is also a surprise to me when I first run the regression test against the before-fix java.policy and the test kept passing unexpectedly. Valerie On 6/16/2015 5:51 AM, Sean Mullan wrote: > On 06/15/2015 04:54 PM, Valerie Peng wrote: >> Sean, >> >> Given how trivial this is, I initially covered it in the fix for >> 7191662. >> However, fix for 7191662 took longer than anticipated to go in and now >> SQE has filed a bug for this. >> Thus, I separated this out into a separate webrev. Can u please take a >> look? >> >> http://cr.openjdk.java.net/~valeriep/8087157/webrev.01/ > > I am pretty sure you don't need to run the test in othervm mode, since > jtreg agentvm mode should be able to cleanup/disable the > SecurityManager so that the VM can be reused. You could double-check > with Jon Gibbons to be sure. Otherwise, looks good. > > --Sean > From sean.mullan at oracle.com Thu Jun 18 23:17:50 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Jun 2015 19:17:50 -0400 Subject: RFR 8087157: PKCS11 provider not instantiated with security manager In-Reply-To: <55833BC2.8080203@oracle.com> References: <557F3B74.5000904@oracle.com> <55801BE4.5000907@oracle.com> <55833BC2.8080203@oracle.com> Message-ID: <5583519E.80705@oracle.com> On 06/18/2015 05:44 PM, Valerie Peng wrote: > Well, the othervm mode is needed not because of the cleanup/disable of > SecurityManager, but to ensure that SunPKCS11 provider is created under > a SecurityManager. > > Without the othervm mode, the test will always pass even if the > necessary permission is not in java.policy because SunPKCS11 provider is > already created and present when this test is run. This is also a > surprise to me when I first run the regression test against the > before-fix java.policy and the test kept passing unexpectedly. Ok, that makes sense now. Thanks, Sean > > Valerie > > On 6/16/2015 5:51 AM, Sean Mullan wrote: >> On 06/15/2015 04:54 PM, Valerie Peng wrote: >>> Sean, >>> >>> Given how trivial this is, I initially covered it in the fix for >>> 7191662. >>> However, fix for 7191662 took longer than anticipated to go in and now >>> SQE has filed a bug for this. >>> Thus, I separated this out into a separate webrev. Can u please take a >>> look? >>> >>> http://cr.openjdk.java.net/~valeriep/8087157/webrev.01/ >> >> I am pretty sure you don't need to run the test in othervm mode, since >> jtreg agentvm mode should be able to cleanup/disable the >> SecurityManager so that the VM can be reused. You could double-check >> with Jon Gibbons to be sure. Otherwise, looks good. >> >> --Sean >> From jamil.j.nimeh at oracle.com Fri Jun 19 00:27:12 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 18 Jun 2015 17:27:12 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) Message-ID: <558361E0.2060409@oracle.com> Hello all, I have a first cut at the OCSP stapling webrev posted for your review: JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ A couple items to note: * I'm in the process of updating the JEP with some more details. I should be done with these changes by tonight (PDT). * Missing are some of the TLS end-to-end tests. These tests have been coded and run outside the jtreg framework, but for some reason things hang in jtreg. I've included some of the supporting classes that these tests will use (CertificateBuilder.java and SimpleOCSPResponder.java) so folks could review those if they're interested. I will update the webrev and notify the list as soon as I've got the tests working in jtreg. Thanks to everyone who has helped along the way. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From amanda.jiang at oracle.com Fri Jun 19 03:21:44 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 18 Jun 2015 22:21:44 -0500 Subject: Please review CR 8050409: Test for JAAS getPrivateCredentials In-Reply-To: <5582717B.90005@oracle.com> References: <54EE36A1.5020802@oracle.com> <5582717B.90005@oracle.com> Message-ID: <55838AC8.2090606@oracle.com> Max, Thanks for reviewing this, could you please sponsor it? (My JDK author ID is amjiang) Thanks, Amanda On 6/18/15, 2:21 AM, Weijun Wang wrote: > Hi Amanda > > The test looks fine. > > Thanks > Max > > On 2/26/2015 4:54 AM, Amanda Jiang wrote: >> Hi All, >> >> Could you please review following changeset, which includes one new test >> to test permission checks with Subject.getPrivateCredentials. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8050409 >> Webrev:http://cr.openjdk.java.net/~tyan/amandaj/8050409/webrev.02/ >> >> Thanks, >> Amanda >> From xuelei.fan at oracle.com Fri Jun 19 04:21:12 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 19 Jun 2015 12:21:12 +0800 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558361E0.2060409@oracle.com> References: <558361E0.2060409@oracle.com> Message-ID: <558398B8.9000803@oracle.com> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java ================================================================= - * Obtains a {@link List} containing all status responses presented by - * the peer. + * Obtains a {@link List} containing DER-encoded OCSP responses + * (using the ASN.1 type OCSPResponse defined in RFC 6960) for + * the client to verify status of the server's certificate during + * handshaking. As this method can be called from both client and server side, "by the peer" may be confusing. Better to indicate the encode. Alternatively, the encode can also be specified in return value description. ---------------------------- - * In server mode, the call will return an empty {@link List} - * as the client does not present status responses in a - * CertificateStatus message. - *

    - * In client mode, a {@link List} containing one or more status - * responses will be returned if the server sent responses in a - * CertificateStatus handshake message. Otherwise an empty - * {@link List} will be returned. I think, actually there is no difference of the return value for client side and server side. Easy to understand if joining them together. Maybe better move to the return value description. Better to describe the sequence of the returned value and the item may be empty (not null) in order to follow the spec at the end paragraph of page 6, RFC 6961. ---------------------------- - * If one or more responses have been set, {@link - * X509ExtendedTrustManager} objects will attempt to use them - * during server certificate verification. - *

    - * Note: This method can be used only when using certificate-based - * cipher suites; using it with non-certificate-based cipher suites, - * such as Kerberos, will return an empty {@link List}. + * This method only apply to certificate-based server + * authentication. {@code X509ExtendedTrustManager} will use the + * returned value for server certificates validation. "certificate-based authentication" is a more general expression than "certificate-based cipher suites". Kerberos may also use certicate, I would suggest to remove the example. ---------------------------- - * @return a non-null immutable list of byte arrays, each entry - * containing a single status response. + * @return a non-null immutable list of byte arrays, each entry + * containing a DER-encoded OCSP response (using the + * ASN.1 type OCSPResponse defined in RFC 6960) for + * server certificate(s) authentication. The returned + * list may be empty if no OCSP response was presented + * during handshaking. Just for your consideration. Xuelei On 6/19/2015 8:27 AM, Jamil Nimeh wrote: > Hello all, > > I have a first cut at the OCSP stapling webrev posted for your review: > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ > > A couple items to note: > > * I'm in the process of updating the JEP with some more details. I > should be done with these changes by tonight (PDT). > * Missing are some of the TLS end-to-end tests. These tests have been > coded and run outside the jtreg framework, but for some reason > things hang in jtreg. I've included some of the supporting classes > that these tests will use (CertificateBuilder.java and > SimpleOCSPResponder.java) so folks could review those if they're > interested. I will update the webrev and notify the list as soon as > I've got the tests working in jtreg. > > Thanks to everyone who has helped along the way. > > --Jamil > > From aph at redhat.com Fri Jun 19 08:34:28 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Jun 2015 09:34:28 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <55831BC8.9060001@oracle.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> Message-ID: <5583D414.5050502@redhat.com> On 18/06/15 20:28, Vladimir Kozlov wrote: > We have few new rules regarding intrinsics. > You need to add private static java method which does range checks > because their are not executed in intrinsic code - see squareToLen() > implementation, for example. Okay. > Note, we will rewrite multiplyToLen() too soon. Right. > Also method which will be intrinsified should be private static too and > you can move allocation from it (like we did for squareToLen()) to avoid > allocation in intrinsic code. I like that. It's surely a lot less complicated than what I've got right now. > Your Hotspot changes are hard to accept. We have to compile for solaris > with Sun compilers which does not work with such changes: > > "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3525: Warning: > parameter in inline asm statement unused: %3. > "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3525: Warning: > parameter in inline asm statement unused: %6. > "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3701: Error: The > function "__builtin_expect" must have a prototype. > "hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp", line 3707: Error: The > function "__builtin_alloca" must have a prototype. Sure. I didn't realize that you were compiling that code with non-GCC. __builtin_alloca() can just be replaced by alloca() on on-GCC. > May be you can convert the code to stub and add new MacroAssembler > functions which you can use in sharedRuntime_x86_64.cpp. I don't think so. It's fast because it is truly inline assembler, inserted into the C code. If I had some way to access an x86 Solaris machine I'd test it there. But those warnings about unused parameters are just warnings. It may be that the code would work on a Sun compiler. Can you please try to replace __builtin_alloca() with alloca() and then tell me if the code works? > Yes, it is a lot of handwriting but we need it to work on all OSs. Sure, I get that. I knew there would be a few goes around with this, but it's worth the pain for the performance improvement. Andrew. From weijun.wang at oracle.com Fri Jun 19 10:04:08 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Jun 2015 18:04:08 +0800 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently Message-ID: <5583E918.5060609@oracle.com> I might have found a reason for SunMSCAPI crash http://cr.openjdk.java.net/~weijun/8023546/webrev.00 Before this fix, the native function convertToLittleEndian() fails if you want to convert a 63 byte array to a 64 byte one. However, I observed that when a 1024 bit RSA private key is generated, its prime exponent p can be only 63 bytes long. Function is updated to accept this case. I'm not a cryptographer so if you believe the p must be of 64 bytes long please tell me. Thanks Max From jamil.j.nimeh at oracle.com Fri Jun 19 15:19:07 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 19 Jun 2015 08:19:07 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558398B8.9000803@oracle.com> References: <558361E0.2060409@oracle.com> <558398B8.9000803@oracle.com> Message-ID: <558432EB.8000808@oracle.com> Hi Xuelei, those are all good comments. I'll make the changes. Thanks for the quick spec feedback. --Jamil On 6/18/2015 9:21 PM, Xuelei Fan wrote: > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java > ================================================================= > - * Obtains a {@link List} containing all status responses presented by > - * the peer. > + * Obtains a {@link List} containing DER-encoded OCSP responses > + * (using the ASN.1 type OCSPResponse defined in RFC 6960) for > + * the client to verify status of the server's certificate during > + * handshaking. > > As this method can be called from both client and server side, "by the > peer" may be confusing. > > Better to indicate the encode. Alternatively, the encode can also be > specified in return value description. > > ---------------------------- > > - * In server mode, the call will return an empty {@link List} > - * as the client does not present status responses in a > - * CertificateStatus message. > - *

    > - * In client mode, a {@link List} containing one or more status > - * responses will be returned if the server sent responses in a > - * CertificateStatus handshake message. Otherwise an empty > - * {@link List} will be returned. > > I think, actually there is no difference of the return value for client > side and server side. Easy to understand if joining them together. > Maybe better move to the return value description. > > Better to describe the sequence of the returned value and the item may > be empty (not null) in order to follow the spec at the end paragraph of > page 6, RFC 6961. > > ---------------------------- > - * If one or more responses have been set, {@link > - * X509ExtendedTrustManager} objects will attempt to use them > - * during server certificate verification. > - *

    > - * Note: This method can be used only when using certificate-based > - * cipher suites; using it with non-certificate-based cipher suites, > - * such as Kerberos, will return an empty {@link List}. > + * This method only apply to certificate-based server > + * authentication. {@code X509ExtendedTrustManager} will use the > + * returned value for server certificates validation. > > "certificate-based authentication" is a more general expression than > "certificate-based cipher suites". Kerberos may also use certicate, I > would suggest to remove the example. > > ---------------------------- > > - * @return a non-null immutable list of byte arrays, each entry > - * containing a single status response. > + * @return a non-null immutable list of byte arrays, each entry > + * containing a DER-encoded OCSP response (using the > + * ASN.1 type OCSPResponse defined in RFC 6960) for > + * server certificate(s) authentication. The returned > + * list may be empty if no OCSP response was presented > + * during handshaking. > > Just for your consideration. > > Xuelei > > On 6/19/2015 8:27 AM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have been >> coded and run outside the jtreg framework, but for some reason >> things hang in jtreg. I've included some of the supporting classes >> that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon as >> I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> From ivan.gerasimov at oracle.com Fri Jun 19 19:17:58 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Jun 2015 22:17:58 +0300 Subject: RFR 8098854: Do cleanup in a proper order in mscapi Message-ID: <55846AE6.30004@oracle.com> Hello everyone! The changeset consists of two parts: - checking systematically for NULL result of FindClass() and GetMethodID(), - calling CryptReleaseContext() after CryptDestroyHash(), as it is suggested in MSDN [1]. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8098854 WEBREV: http://cr.openjdk.java.net/~igerasim/8098854/00/webrev/ [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380268(v=vs.85).aspx Sincerely yours, Ivan From amanda.jiang at oracle.com Fri Jun 19 22:33:41 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 19 Jun 2015 17:33:41 -0500 Subject: RFR 8050461: Tests for syntax checking of JAAS configuration file Message-ID: <558498C5.4060602@oracle.com> Hello, Please help to review following changeset, which includes new tests to Verify syntax checking of java.security.auth.login.config file. Bug: https://bugs.openjdk.java.net/browse/JDK-8050461 Webrev: http://cr.openjdk.java.net/~amjiang/8050461/webrev.02/ Thanks, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Jun 20 14:42:04 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 20 Jun 2015 22:42:04 +0800 Subject: RFR 8050461: Tests for syntax checking of JAAS configuration file In-Reply-To: <558498C5.4060602@oracle.com> References: <558498C5.4060602@oracle.com> Message-ID: <55857BBC.7000306@oracle.com> Hi Amanda I'd rather see 5 JAAS conf files directly included (instead of generating them with codes). Then it seems you can write a single test with 5 @run lines. Thanks Max On 6/20/2015 6:33 AM, Amanda Jiang wrote: > Hello, > > Please help to review following changeset, which includes new tests to > Verify syntax checking of java.security.auth.login.config file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050461 > Webrev: http://cr.openjdk.java.net/~amjiang/8050461/webrev.02/ > > Thanks, > Amanda From openjdk at suche.org Sun Jun 21 13:46:52 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 21 Jun 2015 15:46:52 +0200 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558361E0.2060409@oracle.com> References: <558361E0.2060409@oracle.com> Message-ID: <5586C04C.5080401@suche.org> Hi, here are some comments about what i was thinking: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java.patch - Why not make the parsed message available ? If the client wan't to check it he need to parse/implement the handling again. http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java.patch - Why not allow to toggle each of the extensions individually ? I think after Heartbleed this would be an good idee + if (enableStatusRequestExtension) { + clientHelloMessage.addCertStatusReqListV2Extension(); + clientHelloMessage.addCertStatusRequestExtension(); + } http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/x509/PKIXExtensions.java.patch - Why to break the comments earlyer ? From openjdk at suche.org Sun Jun 21 15:21:58 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 21 Jun 2015 17:21:58 +0200 Subject: RFR: 8060103: CheckBlacklistedCerts.java thinks its openjdk build In-Reply-To: <5581FBFE.4010407@oracle.com> References: <5581FBFE.4010407@oracle.com> Message-ID: <5586D696.9040908@suche.org> Hi, we are talking about security. So is there any reason why the OpenJDK should include not the same Blacklisted Certificates as in other Jdk Versions? Or with other words does it make sense to do other blacklist tests in openjdk at all ? Gru? Thomas On 18.06.2015 01:00, Rajan Halade wrote: > May I request you to review small fix to CheckBlacklistedCerts test to > correctly determine if OpenJDK build is used. > > Webrev: http://cr.openjdk.java.net/~rhalade/8060103/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8060103 > > Thanks, > Rajan From jamil.j.nimeh at oracle.com Sun Jun 21 15:56:17 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 21 Jun 2015 08:56:17 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <5586C04C.5080401@suche.org> References: <558361E0.2060409@oracle.com> <5586C04C.5080401@suche.org> Message-ID: <5586DEA1.60109@oracle.com> Hi Thomas, thanks for the comments. I have some follow-ups below On 06/21/2015 06:46 AM, Thomas Lu?nig wrote: > Hi, > > here are some comments about what i was thinking: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java.patch > - Why not make the parsed message available ? > If the client wan't to check it he need to parse/implement the > handling again. You're not the first person who has asked for a handshake message to be exposed to the consumer. I think folks have asked for ClientHello and verify messages in the past. It would be better if we could expose parsed messages in a more general way rather than do a one-off for CertificateStatus or the hellos or whatnot. Also, I would think we'd want a way that would work equally well for SSLEngines and SSLSockets. Putting that aside, the CertificateStatus message doesn't have much more to it than the responses itself. That you have the OCSP DER-encoded responses broken out already means you have the message more or less parsed, with the exception that the response DER encodings haven't been turned into an object, but JDK doesn't have anything to do that today that isn't sun-private. The X509TrustManager, if configured to do revocation checking at all, should handle the checks so the client doesn't have to. Can you tell me a little more about what environment a customer would want to re-check the responses above and beyond what is done already? Could those checks be done with a custom CertPathChecker registered with the PKIXBuilderParameters used in the trust manager? > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java.patch > - Why not allow to toggle each of the extensions individually ? > I think after Heartbleed this would be an good idee > + if (enableStatusRequestExtension) { > + clientHelloMessage.addCertStatusReqListV2Extension(); > + clientHelloMessage.addCertStatusRequestExtension(); > + } I suppose we could, I didn't because I just didn't want two more properties, that's all. At one point there was some discussion about a single property that could be used to toggle the presence of multiple extensions, which could help prevent an explosion in the number of enable/disable properties related to TLS extensions. Maybe we need to reopen that discussion. > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/x509/PKIXExtensions.java.patch > - Why to break the comments earlyer ? > > You lost me on this last one, can you clarify what you mean? Do you not like where I added the OCSP nonce definition? From openjdk at suche.org Sun Jun 21 19:12:19 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 21 Jun 2015 21:12:19 +0200 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <5586DEA1.60109@oracle.com> References: <558361E0.2060409@oracle.com> <5586C04C.5080401@suche.org> <5586DEA1.60109@oracle.com> Message-ID: <55870C93.6020902@suche.org> On 21.06.2015 17:56, Jamil Nimeh wrote: > > The X509TrustManager, if configured to do revocation checking at all, > should handle the checks so the client doesn't have to. Can you tell > me a little more about what environment a customer would want to > re-check the responses above and beyond what is done already? Could > those checks be done with a custom CertPathChecker registered with the > PKIXBuilderParameters used in the trust manager? One example would be Certificate Transparency that use the same response message but with other content. >> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java.patch >> >> - Why not allow to toggle each of the extensions individually ? >> I think after Heartbleed this would be an good idee >> + if (enableStatusRequestExtension) { >> + clientHelloMessage.addCertStatusReqListV2Extension(); >> + clientHelloMessage.addCertStatusRequestExtension(); >> + } > I suppose we could, I didn't because I just didn't want two more > properties, that's all. At one point there was some discussion about > a single property that could be used to toggle the presence of > multiple extensions, which could help prevent an explosion in the > number of enable/disable properties related to TLS extensions. Maybe > we need to reopen that discussion. Even one property would be ok if it is not boolean but decimal. 0 := Off 1 := Simple Request 2 := ListV2 Request 3 := Both Types >> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/x509/PKIXExtensions.java.patch >> >> - Why to break the comments earlyer ? >> >> > You lost me on this last one, can you clarify what you mean? Do you > not like where I added the OCSP nonce definition? There are many changes like these sample where only the line length is changes. I ask because today the monitors become wider but not higher so if we have small line length but many lines the screen contain less information. The qeustion is if the changes are due to some new rules. - * Allows additional identities to be bound to the subject of the certificate. + * Allows additional identities to be bound to the subject of the + * certificate. Gru? Thomas From mstjohns at comcast.net Mon Jun 22 04:21:07 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 22 Jun 2015 00:21:07 -0400 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: <5583E918.5060609@oracle.com> References: <5583E918.5060609@oracle.com> Message-ID: Hmm... It is possible to randomly generate a prime which is expressed in less than the full number of provided bytes so it is possible (and legal) for sourceLength to be less than or equal to destination length. What should probably be checked here though is : if (sourceLength > destinationLength) { return -1; } (E.g. if you're trying to stuff N bytes in an N-1 length array it will be bad). For the rest, it seems clumsy to do it that way (the loop and if statement) - instead maybe do an int off = sourceLength; for (int i = 0; i < sourceLength; i++) { destination[i] = sourceBytes[--off]; // note the pre decrement! } if (sourceLength < destinationLength) { memset (destination + sourceLength, 0, destinationLength - sourceLength); } To copy and then clear. And then return destinationLength; Mike At 06:04 AM 6/19/2015, Weijun Wang wrote: >I might have found a reason for SunMSCAPI crash > > http://cr.openjdk.java.net/~weijun/8023546/webrev.00 > >Before this fix, the native function convertToLittleEndian() fails if you want to convert a 63 byte array to a 64 byte one. However, I observed that when a 1024 bit RSA private key is generated, its prime exponent p can be only 63 bytes long. Function is updated to accept this case. > >I'm not a cryptographer so if you believe the p must be of 64 bytes long please tell me. > >Thanks >Max From mstjohns at comcast.net Mon Jun 22 04:35:30 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 22 Jun 2015 00:35:30 -0400 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: <20150622042103.8B88F119FB8@aojmv0009> References: <5583E918.5060609@oracle.com> <20150622042103.8B88F119FB8@aojmv0009> Message-ID: At 12:21 AM 6/22/2015, Michael StJohns wrote: >Hmm... > >It is possible to randomly generate a prime which is expressed in less than the full number of provided bytes so it is possible (and legal) for sourceLength to be less than or equal to destination length. What should probably be checked here though is : *sigh* The following should have been : int off = sourceLength; if (sourceLength > destinationLength) { if (sourceLength > (destinationLength +1)) { return -1; } off++; sourceLength == destinationLength; } If you're taking a 65 byte big endian representation and trimming the sign byte to get 64 bytes, that's OK. If you're taking a 66 byte representation and trying to stuff it into 64 bytes, you're throwing away 1 byte of meaningful data. >if (sourceLength > destinationLength) { > return -1; >} > >(E.g. if you're trying to stuff N bytes in an N-1 length array it will be bad). > >For the rest, it seems clumsy to do it that way (the loop and if statement) - instead maybe do an > >int off = sourceLength; > >for (int i = 0; i < sourceLength; i++) { > destination[i] = sourceBytes[--off]; // note the pre decrement! >} > >if (sourceLength < destinationLength) { > memset (destination + sourceLength, 0, destinationLength - sourceLength); >} > > >To copy and then clear. > >And then > >return destinationLength; *sigh* return sourceLength; >Mike > > > > > >At 06:04 AM 6/19/2015, Weijun Wang wrote: >>I might have found a reason for SunMSCAPI crash >> >> http://cr.openjdk.java.net/~weijun/8023546/webrev.00 >> >>Before this fix, the native function convertToLittleEndian() fails if you want to convert a 63 byte array to a 64 byte one. However, I observed that when a 1024 bit RSA private key is generated, its prime exponent p can be only 63 bytes long. Function is updated to accept this case. >> >>I'm not a cryptographer so if you believe the p must be of 64 bytes long please tell me. >> >>Thanks >>Max From jamil.j.nimeh at oracle.com Mon Jun 22 16:16:45 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 22 Jun 2015 09:16:45 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55870C93.6020902@suche.org> References: <558361E0.2060409@oracle.com> <5586C04C.5080401@suche.org> <5586DEA1.60109@oracle.com> <55870C93.6020902@suche.org> Message-ID: <558834ED.8050306@oracle.com> Just one follow up from a previous set of comments: On 06/21/2015 12:12 PM, Thomas Lu?nig wrote: > On 21.06.2015 17:56, Jamil Nimeh wrote: >> The X509TrustManager, if configured to do revocation checking at all, >> should handle the checks so the client doesn't have to. Can you tell >> me a little more about what environment a customer would want to >> re-check the responses above and beyond what is done already? Could >> those checks be done with a custom CertPathChecker registered with the >> PKIXBuilderParameters used in the trust manager? > One example would be Certificate Transparency that use the same response > message but with other content. I did a very cursory scan of RFC 6962...correct me if I'm wrong, but CT's intersection with OCSP stapling is just that the OCSP response has a specific OCSP extension in it, (The certificate timestamp list) correct? If that's the case, then the List of byte arrays handed back by ExtendedSSLSession.getStatusResponses() essentially gives you the parsed message back. The CertificateStatus HandshakeMessage object doesn't hold the OCSP responses in a parsed form such as sun.security.provider.certpath.OCSPResponse. It just hangs onto the byte arrays in the order they are received. By getting the list out of the getStatusResponses method, you're getting the parsed message, with the exception of the leading type (ocsp vs. ocsp_multi). I don't know if exposing the HandshakeMessage object would get you anything more useful, at least as it is implemented today. >>> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java.patch >>> >>> - Why not allow to toggle each of the extensions individually ? >>> I think after Heartbleed this would be an good idee >>> + if (enableStatusRequestExtension) { >>> + clientHelloMessage.addCertStatusReqListV2Extension(); >>> + clientHelloMessage.addCertStatusRequestExtension(); >>> + } >> I suppose we could, I didn't because I just didn't want two more >> properties, that's all. At one point there was some discussion about >> a single property that could be used to toggle the presence of >> multiple extensions, which could help prevent an explosion in the >> number of enable/disable properties related to TLS extensions. Maybe >> we need to reopen that discussion. > Even one property would be ok if it is not boolean but decimal. > 0 := Off > 1 := Simple Request > 2 := ListV2 Request > 3 := Both Types > >>> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/sun/security/x509/PKIXExtensions.java.patch >>> >>> - Why to break the comments earlyer ? >>> >>> >> You lost me on this last one, can you clarify what you mean? Do you >> not like where I added the OCSP nonce definition? > There are many changes like these sample where only the line length is > changes. > I ask because today the monitors become wider but not higher so if we > have small line length but many lines the screen contain less information. > The qeustion is if the changes are due to some new rules. > > - * Allows additional identities to be bound to the subject of the certificate. > + * Allows additional identities to be bound to the subject of the > + * certificate. > > Gru? Thomas > > From xuelei.fan at oracle.com Tue Jun 23 03:26:22 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Jun 2015 11:26:22 +0800 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558361E0.2060409@oracle.com> References: <558361E0.2060409@oracle.com> Message-ID: <5588D1DE.8030507@oracle.com> src/java.base/share/classes/sun/security/ssl/HandshakeStateManager.java ======================================================================= Thanks for the correction of typos, etc. line 777-797. Mayber, we can use the "default" block at line 857, and may not need the block from line 777 to 797. What do you think? src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ================================================================== - private final boolean enableStatusRequestExtension = + private final static boolean enableStatusRequestExtension = May not want to support dynamic system property. --------------------------- - private byte setCertValidationFailure(CertificateException cexc) + private byte getCerticateAlert(CertificateException cexc) Looks more like a getter method than a setter method. --------------------------- - private void checkServerCerts(X509Certificate[] certs) - throws CertificateException { + private void checkServerCerts(X509Certificate[] certs) + throws IOException { The caller is always handle the thrown exception with the same code: try { checkServerCerts(deferredCerts); } catch (CertificateException e) { // This will throw an exception, so include the // original error. fatalSE(setCertValidationFailure(e), e); } What do you think if moving the code into checkServerCerts() and throwing IOException? --------------------------- if (staplingActive && ignoredOptStates.contains( ... } The same code block is used in several places in processMessage(). I understand the point. However, this code block need to be inserted into every message of the server hello series messages, or need careful analysis of the message sequence. As may not quite friendly for maintaining. What do you think if moving the block to the header of processMessage()? void processMessage(byte type, int messageLen) throws IOException { // check the handshake state List ignoredOptStates = handshakeState.check(type); + if (staplingActive && ignoredOptStates.contains( + ... + } --------------------------- 753 // Only enable the stapling feature if the client asserted 754 // these extensions. 755 if (enableStatusRequestExtension) { 756 staplingActive = true; + } else { + fatalSE(Alerts.alert_unexpected_message, "..."); 757 } Maybe, better to terminate the connection with a fatal unexpected_message if the extension is not requested. Xuelei On 6/19/2015 8:27 AM, Jamil Nimeh wrote: > Hello all, > > I have a first cut at the OCSP stapling webrev posted for your review: > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ > > A couple items to note: > > * I'm in the process of updating the JEP with some more details. I > should be done with these changes by tonight (PDT). > * Missing are some of the TLS end-to-end tests. These tests have been > coded and run outside the jtreg framework, but for some reason > things hang in jtreg. I've included some of the supporting classes > that these tests will use (CertificateBuilder.java and > SimpleOCSPResponder.java) so folks could review those if they're > interested. I will update the webrev and notify the list as soon as > I've got the tests working in jtreg. > > Thanks to everyone who has helped along the way. > > --Jamil > > From weijun.wang at oracle.com Tue Jun 23 06:34:40 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Jun 2015 14:34:40 +0800 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: <201506220435.t5M4YQvn039290@userp2050.oracle.com> References: <5583E918.5060609@oracle.com> <20150622042103.8B88F119FB8@aojmv0009> <201506220435.t5M4YQvn039290@userp2050.oracle.com> Message-ID: <5588FE00.3030808@oracle.com> Hi Michael Webrev updated at http://cr.openjdk.java.net/~weijun/8023546/webrev.01 I added a check about the extra sign byte, I even added a null check in KeyStore.java, although if the fix is done right they should never happen. The return value of the convertToLittleEndian() function is now always destinationLength. This was also the value before the fix, which is the number of bytes we actually write, including zeroes. Personally I'm still a little afraid of --x (and x++, if it's used in an expression), so I kept the old style. Can anyone with a reviewer badge also look at this? Thanks Max From jamil.j.nimeh at oracle.com Tue Jun 23 07:04:23 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 23 Jun 2015 00:04:23 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <5588D1DE.8030507@oracle.com> References: <558361E0.2060409@oracle.com> <5588D1DE.8030507@oracle.com> Message-ID: <558904F7.4050204@oracle.com> Hi Xuelei, thanks for the comments. Keep 'em coming! On 06/22/2015 08:26 PM, Xuelei Fan wrote: > src/java.base/share/classes/sun/security/ssl/HandshakeStateManager.java > ======================================================================= > Thanks for the correction of typos, etc. > > line 777-797. > Mayber, we can use the "default" block at line 857, and may not need the > block from line 777 to 797. What do you think? I think that would work. I'll remove the cert status case and see what happens. > > src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > ================================================================== > - private final boolean enableStatusRequestExtension = > + private final static boolean enableStatusRequestExtension = > May not want to support dynamic system property. Actually I did want it to take that value of the property at instantiation time so people could selectively turn it on and off before creating sockets/engines. What concerns do you have about it being dynamic? > > --------------------------- > > - private byte setCertValidationFailure(CertificateException cexc) > + private byte getCerticateAlert(CertificateException cexc) > Looks more like a getter method than a setter method. I guess it's a little of both. But I have no problem with changing the name. > > --------------------------- > > - private void checkServerCerts(X509Certificate[] certs) > - throws CertificateException { > + private void checkServerCerts(X509Certificate[] certs) > + throws IOException { > > The caller is always handle the thrown exception with the same code: > > try { > checkServerCerts(deferredCerts); > } catch (CertificateException e) { > // This will throw an exception, so include the > // original error. > fatalSE(setCertValidationFailure(e), e); > } > > What do you think if moving the code into checkServerCerts() and > throwing IOException? That would be fine. At the time I wrote it, I wasn't sure if I'd be doing the same thing as a consequence of checkServerCerts throwing a CPVE. But it turned out to be the same in all cases and I never went back to clean that up. Good catch. I'll get this fixed up. > > --------------------------- > > if (staplingActive && ignoredOptStates.contains( > ... > } > > The same code block is used in several places in processMessage(). I > understand the point. However, this code block need to be inserted into > every message of the server hello series messages, or need careful > analysis of the message sequence. As may not quite friendly for > maintaining. > > What do you think if moving the block to the header of processMessage()? > > void processMessage(byte type, int messageLen) throws IOException { > // check the handshake state > List ignoredOptStates = handshakeState.check(type); > + if (staplingActive && ignoredOptStates.contains( > + ... > + } I know. I didn't like the duplication either, but I wasn't sure if I could just call it at the top safely so I instead moved it into each state transition from Server Certificate. If we can do it once at the top like I did in the pre-DTLS code, then that's by far the better way to go. I'll try that out. > --------------------------- > > 753 // Only enable the stapling feature if the client asserted > 754 // these extensions. > 755 if (enableStatusRequestExtension) { > 756 staplingActive = true; > + } else { > + fatalSE(Alerts.alert_unexpected_message, "..."); > 757 } > > Maybe, better to terminate the connection with a fatal > unexpected_message if the extension is not requested. Yes, I think you're right. I'll fix this up too. > > Xuelei > > > On 6/19/2015 8:27 AM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have been >> coded and run outside the jtreg framework, but for some reason >> things hang in jtreg. I've included some of the supporting classes >> that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon as >> I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> From xuelei.fan at oracle.com Tue Jun 23 07:39:30 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Jun 2015 15:39:30 +0800 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558904F7.4050204@oracle.com> References: <558361E0.2060409@oracle.com> <5588D1DE.8030507@oracle.com> <558904F7.4050204@oracle.com> Message-ID: <55890D32.1000607@oracle.com> On 6/23/2015 3:04 PM, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java >> ================================================================== >> - private final boolean enableStatusRequestExtension = >> + private final static boolean enableStatusRequestExtension = >> May not want to support dynamic system property. > Actually I did want it to take that value of the property at > instantiation time so people could selectively turn it on and off before > creating sockets/engines. What concerns do you have about it being > dynamic? Caches, for example session/trust manager/key manager, are used a lot in SSL/TLS handshaking. Dynamic system property may make the behavior a little bit complicated. In general, if not necessary, I would prefer to use static system property as what we did before for similar properties. Developers only need to understand one mode, as would simplify the learning curve, I think. Anyway, not a big concerns of mine. Xuelei From ecki at zusammenkunft.net Tue Jun 23 08:03:13 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 23 Jun 2015 10:03:13 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150522233435.000040e2.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> Message-ID: <20150623100313.00005423.ecki@zusammenkunft.net> Hello, just for the records, IBM has issued in their June 2015 Security update a Logjam fix in 8 SR1-FP1 and 7R1 SP3-FP1 (and others). Unfortunatelly I havent found online documentation yet which describes what actually has changed. (their previous CVE analysis workaround did recommend to turn of DHE completely before, so they did not use the keySize syntax either). Gruss Bernd From vincent.x.ryan at oracle.com Tue Jun 23 08:05:46 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 23 Jun 2015 09:05:46 +0100 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: <5588FE00.3030808@oracle.com> References: <5583E918.5060609@oracle.com> <20150622042103.8B88F119FB8@aojmv0009> <201506220435.t5M4YQvn039290@userp2050.oracle.com> <5588FE00.3030808@oracle.com> Message-ID: Your fix looks good. Thanks Max. > On 23 Jun 2015, at 07:34, Weijun Wang wrote: > > Hi Michael > > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8023546/webrev.01 > > I added a check about the extra sign byte, I even added a null check in KeyStore.java, although if the fix is done right they should never happen. > > The return value of the convertToLittleEndian() function is now always destinationLength. This was also the value before the fix, which is the number of bytes we actually write, including zeroes. > > Personally I'm still a little afraid of --x (and x++, if it's used in an expression), so I kept the old style. > > Can anyone with a reviewer badge also look at this? > > Thanks > Max > From ecki at zusammenkunft.net Tue Jun 23 08:17:30 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 23 Jun 2015 10:17:30 +0200 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55890D32.1000607@oracle.com> References: <558361E0.2060409@oracle.com> <5588D1DE.8030507@oracle.com> <558904F7.4050204@oracle.com> <55890D32.1000607@oracle.com> Message-ID: <20150623101730.0000232e.ecki@zusammenkunft.net> Hello, this is a general comment, not necesarily applicable for the OCSP stapling options directly: Am Tue, 23 Jun 2015 15:39:30 +0800 schrieb Xuelei Fan : > Caches, for example session/trust manager/key manager, are used a lot > in SSL/TLS handshaking. Dynamic system property may make the > behavior a little bit complicated. In general, if not necessary, I > would prefer to use static system property as what we did before for > similar properties. Developers only need to understand one mode, as > would simplify the learning curve, I think. But its a huge problem when you have to interface with multiple partners. This especially is for turning features on and off. One server does not allow to use SNI, the other requires it. One would use a weak DHE key when DHE is enabled, the other would not use forward secrecy without. Some implementation fails with OCSP extensions the other not (etc). So a general interface for setting those parameters on the context/sesssion/factory instead of (only) system properties would be great. Gruss Bernd From xuelei.fan at oracle.com Tue Jun 23 08:34:36 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Jun 2015 16:34:36 +0800 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <20150623101730.0000232e.ecki@zusammenkunft.net> References: <558361E0.2060409@oracle.com> <5588D1DE.8030507@oracle.com> <558904F7.4050204@oracle.com> <55890D32.1000607@oracle.com> <20150623101730.0000232e.ecki@zusammenkunft.net> Message-ID: <55891A1C.3010400@oracle.com> On 6/23/2015 4:17 PM, Bernd Eckenfels wrote: > Hello, > > this is a general comment, not necesarily applicable for the OCSP > stapling options directly: > > Am Tue, 23 Jun 2015 15:39:30 +0800 > schrieb Xuelei Fan : > >> Caches, for example session/trust manager/key manager, are used a lot >> in SSL/TLS handshaking. Dynamic system property may make the >> behavior a little bit complicated. In general, if not necessary, I >> would prefer to use static system property as what we did before for >> similar properties. Developers only need to understand one mode, as >> would simplify the learning curve, I think. > > But its a huge problem when you have to interface with multiple > partners. This especially is for turning features on and off. One > server does not allow to use SNI, the other requires it. One would use > a weak DHE key when DHE is enabled, the other would not use forward > secrecy without. Some implementation fails with OCSP extensions the > other not (etc). > > So a general interface for setting those parameters on the > context/sesssion/factory instead of (only) system properties would be > great. > Yes. System properties should not be the preferable approach. API level methods are needed. May address in a separated bug in the near future. Thanks, Xuelei From jamil.j.nimeh at oracle.com Tue Jun 23 16:15:43 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 23 Jun 2015 09:15:43 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <20150623101730.0000232e.ecki@zusammenkunft.net> References: <558361E0.2060409@oracle.com> <5588D1DE.8030507@oracle.com> <558904F7.4050204@oracle.com> <55890D32.1000607@oracle.com> <20150623101730.0000232e.ecki@zusammenkunft.net> Message-ID: <5589862F.8050805@oracle.com> On 06/23/2015 01:17 AM, Bernd Eckenfels wrote: > Hello, > > this is a general comment, not necesarily applicable for the OCSP > stapling options directly: > > Am Tue, 23 Jun 2015 15:39:30 +0800 > schrieb Xuelei Fan: > >> Caches, for example session/trust manager/key manager, are used a lot >> in SSL/TLS handshaking. Dynamic system property may make the >> behavior a little bit complicated. In general, if not necessary, I >> would prefer to use static system property as what we did before for >> similar properties. Developers only need to understand one mode, as >> would simplify the learning curve, I think. > But its a huge problem when you have to interface with multiple > partners. This especially is for turning features on and off. One > server does not allow to use SNI, the other requires it. One would use > a weak DHE key when DHE is enabled, the other would not use forward > secrecy without. Some implementation fails with OCSP extensions the > other not (etc). > > So a general interface for setting those parameters on the > context/sesssion/factory instead of (only) system properties would be > great. > > Gruss > Bernd Hi Bernd, Having an API to control stapling was part of the original design. In the months that followed, other initiatives like a general-purpose TLS extensions API made us decide to hold off on trying to make something specific to this one extension. We didn't want to come out of the gate with an API that was very shortly superseded by another more general purpose one. That is also why I tried to give at least a little dynamic control over the properties we do have. For instance, if you want to have different server-side stapling settings that affect cache lifetimes or sizing, or not passing OCSP extensions, those properties can be set before you create an SSLContext. Then they can be altered before creating a second SSLContext to get different behavior. As Xuelei said, in the future there will be a way to customize stapling behavior both client and server side. --Jamil From konstantin.shefov at oracle.com Wed Jun 24 10:29:16 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 24 Jun 2015 13:29:16 +0300 Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules In-Reply-To: <558A81B2.8050509@oracle.com> References: <558A8016.106@oracle.com> <558A81B2.8050509@oracle.com> Message-ID: <558A867C.1020502@oracle.com> Alan, Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They have just the same dependencies as "test/javax/net/ssl/TLS" and the TEST.properties file just like one suggested in this fix. If yes, it is not worth changing TEST.properties any more. -Konstantin On 06/24/2015 01:08 PM, Alan Bateman wrote: > On 24/06/2015 11:01, Konstantin Shefov wrote: >> Hello, >> >> Please review the test bug fix >> https://bugs.openjdk.java.net/browse/JDK-8129595 >> Webrev is http://cr.openjdk.java.net/~kshefov/8129595/webrev.00/ > security-dev would be a better place to review this. > > The updates to TEST.properties look okay but I suspect the proposed > patch is incomplete - for example the tests that use SSLEngineTestCase > use sun.security.krb5 classes so they will need to be added to the > @modules line. > > -Alan From Alan.Bateman at oracle.com Wed Jun 24 10:52:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jun 2015 11:52:12 +0100 Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules In-Reply-To: <558A867C.1020502@oracle.com> References: <558A8016.106@oracle.com> <558A81B2.8050509@oracle.com> <558A867C.1020502@oracle.com> Message-ID: <558A8BDC.3030006@oracle.com> On 24/06/2015 11:29, Konstantin Shefov wrote: > Alan, > > Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They > have just the same dependencies as "test/javax/net/ssl/TLS" and the > TEST.properties file just like one suggested in this fix. > If yes, it is not worth changing TEST.properties any more. Alexander Kulyakhtin has been working on a tool that uses jdeps to get the dependences of each test. It's not in OpenJDK yet but I'm sure he can help you get the @modules right for these tests. -Alan From aph at redhat.com Wed Jun 24 10:53:45 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2015 11:53:45 +0100 Subject: Building SA Message-ID: <558A8C39.9090708@redhat.com> Now that tools.jar is gone from build images, what is the right way to build the seviceability agent? Thanks, Andrew. From sean.mullan at oracle.com Wed Jun 24 14:17:24 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Jun 2015 10:17:24 -0400 Subject: RFR: 8060103: CheckBlacklistedCerts.java thinks its openjdk build In-Reply-To: <5586D696.9040908@suche.org> References: <5581FBFE.4010407@oracle.com> <5586D696.9040908@suche.org> Message-ID: <558ABBF4.3030608@oracle.com> On 06/21/2015 11:21 AM, Thomas Lu?nig wrote: > Hi, > > we are talking about security. So is there any reason why the OpenJDK > should include not the same Blacklisted Certificates > as in other Jdk Versions? Although we have included some blacklisted certificates in OpenJDK, there are cases where it makes more sense for each vendor to also be able to maintain their own list, as the certificates may only be applicable to the root CA certificates or extensions that they include, etc. Thanks, Sean > Or with other words does it make sense to do > other blacklist tests in openjdk at all ? > > Gru? Thomas > > On 18.06.2015 01:00, Rajan Halade wrote: >> May I request you to review small fix to CheckBlacklistedCerts test to >> correctly determine if OpenJDK build is used. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8060103/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060103 >> >> Thanks, >> Rajan > From sean.mullan at oracle.com Wed Jun 24 15:26:24 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Jun 2015 11:26:24 -0400 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: References: <5583E918.5060609@oracle.com> <20150622042103.8B88F119FB8@aojmv0009> <201506220435.t5M4YQvn039290@userp2050.oracle.com> <5588FE00.3030808@oracle.com> Message-ID: <558ACC20.1070901@oracle.com> Also, https://bugs.openjdk.java.net/browse/JDK-8025202 might be a duplicate. The symptoms look similar. --Sean On 06/23/2015 04:05 AM, Vincent Ryan wrote: > Your fix looks good. Thanks Max. > >> On 23 Jun 2015, at 07:34, Weijun Wang wrote: >> >> Hi Michael >> >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8023546/webrev.01 >> >> I added a check about the extra sign byte, I even added a null check in KeyStore.java, although if the fix is done right they should never happen. >> >> The return value of the convertToLittleEndian() function is now always destinationLength. This was also the value before the fix, which is the number of bytes we actually write, including zeroes. >> >> Personally I'm still a little afraid of --x (and x++, if it's used in an expression), so I kept the old style. >> >> Can anyone with a reviewer badge also look at this? >> >> Thanks >> Max >> > From konstantin.shefov at oracle.com Wed Jun 24 15:40:52 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 24 Jun 2015 18:40:52 +0300 Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules In-Reply-To: <558A8BDC.3030006@oracle.com> References: <558A8016.106@oracle.com> <558A81B2.8050509@oracle.com> <558A867C.1020502@oracle.com> <558A8BDC.3030006@oracle.com> Message-ID: <558ACF84.2090701@oracle.com> Hi Alan, Please review updated patch. I made it using the tool Alexander Kulyakhtin has given me. http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ Thanks -Konstantin On 06/24/2015 01:52 PM, Alan Bateman wrote: > > > On 24/06/2015 11:29, Konstantin Shefov wrote: >> Alan, >> >> Do the tests form "test/javax/net/ssl/DTLS" compile against jake? >> They have just the same dependencies as "test/javax/net/ssl/TLS" and >> the TEST.properties file just like one suggested in this fix. >> If yes, it is not worth changing TEST.properties any more. > Alexander Kulyakhtin has been working on a tool that uses jdeps to get > the dependences of each test. It's not in OpenJDK yet but I'm sure he > can help you get the @modules right for these tests. > > -Alan From Alan.Bateman at oracle.com Wed Jun 24 15:46:29 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jun 2015 16:46:29 +0100 Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules In-Reply-To: <558ACF84.2090701@oracle.com> References: <558A8016.106@oracle.com> <558A81B2.8050509@oracle.com> <558A867C.1020502@oracle.com> <558A8BDC.3030006@oracle.com> <558ACF84.2090701@oracle.com> Message-ID: <558AD0D5.2090109@oracle.com> On 24/06/2015 16:40, Konstantin Shefov wrote: > Hi Alan, > > Please review updated patch. I made it using the tool Alexander > Kulyakhtin has given me. > > http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ This looks okay to me. Thanks for sorting this out. -Alan From alexander.kulyakhtin at oracle.com Wed Jun 24 12:59:14 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 24 Jun 2015 05:59:14 -0700 (PDT) Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules Message-ID: <874180dc-709e-480d-b22a-a6bf25d55b45@default> Konstantin, Shura has developed a tool to add @modules to jtreg tests specified as input. The wiki is here: https://wiki.se.oracle.com/display/JPG/@modules+in+JTReg+tests#id- at modulesinJTRegtests-Script Please, let me know if any additional help is needed, or if there are any issues. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: konstantin.shefov at oracle.com, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Wednesday, June 24, 2015 1:52:12 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules On 24/06/2015 11:29, Konstantin Shefov wrote: > Alan, > > Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They > have just the same dependencies as "test/javax/net/ssl/TLS" and the > TEST.properties file just like one suggested in this fix. > If yes, it is not worth changing TEST.properties any more. Alexander Kulyakhtin has been working on a tool that uses jdeps to get the dependences of each test. It's not in OpenJDK yet but I'm sure he can help you get the @modules right for these tests. -Alan From alexander.kulyakhtin at oracle.com Wed Jun 24 13:02:16 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 24 Jun 2015 06:02:16 -0700 (PDT) Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules Message-ID: Adding Shura ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: Alan.Bateman at oracle.com Cc: core-libs-dev at openjdk.java.net, konstantin.shefov at oracle.com, security-dev at openjdk.java.net Sent: Wednesday, June 24, 2015 3:59:14 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules Konstantin, Shura has developed a tool to add @modules to jtreg tests specified as input. The wiki is here: https://wiki.se.oracle.com/display/JPG/@modules+in+JTReg+tests#id- at modulesinJTRegtests-Script Please, let me know if any additional help is needed, or if there are any issues. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: konstantin.shefov at oracle.com, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Wednesday, June 24, 2015 1:52:12 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules On 24/06/2015 11:29, Konstantin Shefov wrote: > Alan, > > Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They > have just the same dependencies as "test/javax/net/ssl/TLS" and the > TEST.properties file just like one suggested in this fix. > If yes, it is not worth changing TEST.properties any more. Alexander Kulyakhtin has been working on a tool that uses jdeps to get the dependences of each test. It's not in OpenJDK yet but I'm sure he can help you get the @modules right for these tests. -Alan From alexander.kulyakhtin at oracle.com Wed Jun 24 15:50:47 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 24 Jun 2015 08:50:47 -0700 (PDT) Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules Message-ID: <796df539-506e-441b-87cd-ffb1086b9010@default> Konstantin, Apparently the script does not yet provide for the same formatting as was done with the bulk updates. You may want to make the changes format consistent with how it was done for multiple modules in the bulk update patches such as here: http://sette0.ru.oracle.com/akulyakh/open_no_peers/webrev/test/java/awt/image/multiresolution/MultiResolutionToolkitImageTest.java.udiff.html I'm going to change the script so it provides for the same formatting. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: konstantin.shefov at oracle.com, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Wednesday, June 24, 2015 6:46:30 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules On 24/06/2015 16:40, Konstantin Shefov wrote: > Hi Alan, > > Please review updated patch. I made it using the tool Alexander > Kulyakhtin has given me. > > http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ This looks okay to me. Thanks for sorting this out. -Alan From alexander.kulyakhtin at oracle.com Wed Jun 24 15:54:07 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 24 Jun 2015 08:54:07 -0700 (PDT) Subject: [9] Review request: JDK-8129595: New DTLS tests need @modules Message-ID: Sorry, I didn't realize these are TEST.properties files, not java files. The changes are ok, sorry for the confusion. Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: konstantin.shefov at oracle.com, Alan.Bateman at oracle.com Cc: core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net Sent: Wednesday, June 24, 2015 6:50:47 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules Konstantin, Apparently the script does not yet provide for the same formatting as was done with the bulk updates. You may want to make the changes format consistent with how it was done for multiple modules in the bulk update patches such as here: http://sette0.ru.oracle.com/akulyakh/open_no_peers/webrev/test/java/awt/image/multiresolution/MultiResolutionToolkitImageTest.java.udiff.html I'm going to change the script so it provides for the same formatting. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: konstantin.shefov at oracle.com, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Wednesday, June 24, 2015 6:46:30 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK-8129595: New DTLS tests need @modules On 24/06/2015 16:40, Konstantin Shefov wrote: > Hi Alan, > > Please review updated patch. I made it using the tool Alexander > Kulyakhtin has given me. > > http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ This looks okay to me. Thanks for sorting this out. -Alan From weijun.wang at oracle.com Thu Jun 25 00:58:40 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jun 2015 08:58:40 +0800 Subject: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently In-Reply-To: <558ACC20.1070901@oracle.com> References: <5583E918.5060609@oracle.com> <20150622042103.8B88F119FB8@aojmv0009> <201506220435.t5M4YQvn039290@userp2050.oracle.com> <5588FE00.3030808@oracle.com> <558ACC20.1070901@oracle.com> Message-ID: <558B5240.7060008@oracle.com> On 06/24/2015 11:26 PM, Sean Mullan wrote: > Also, https://bugs.openjdk.java.net/browse/JDK-8025202 might be a > duplicate. The symptoms look similar. Yes. Closed. --Max From xuelei.fan at oracle.com Thu Jun 25 04:32:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Jun 2015 12:32:43 +0800 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558361E0.2060409@oracle.com> References: <558361E0.2060409@oracle.com> Message-ID: <558B846B.7020803@oracle.com> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java ====================================================================== A key/trust manager would better to be immutable. private final ThreadLocal clientValidator ... private final ThreadLocal serverValidator ... ThreadLocal does not work here for some circumstance. In AIO programming, multiple connections may share the same thread. Better to keep key/trust manager and validator immutable. I think, using the status as a validate() method parameter, rather than update the validator status should work. Xuelei On 6/19/2015 8:27 AM, Jamil Nimeh wrote: > Hello all, > > I have a first cut at the OCSP stapling webrev posted for your review: > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ > > A couple items to note: > > * I'm in the process of updating the JEP with some more details. I > should be done with these changes by tonight (PDT). > * Missing are some of the TLS end-to-end tests. These tests have been > coded and run outside the jtreg framework, but for some reason > things hang in jtreg. I've included some of the supporting classes > that these tests will use (CertificateBuilder.java and > SimpleOCSPResponder.java) so folks could review those if they're > interested. I will update the webrev and notify the list as soon as > I've got the tests working in jtreg. > > Thanks to everyone who has helped along the way. > > --Jamil > > From weijun.wang at oracle.com Thu Jun 25 08:21:36 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jun 2015 16:21:36 +0800 Subject: RFR 8058290: JAAS Krb5LoginModule has suspect ticket-renewal logic, relies on clockskew grace Message-ID: <558BBA10.8090301@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8058290/webrev.00/ After this fix, a "renewTGT=true" in JAAS config for Krb5LoginModule means "renew if old enough", as suggested by the bug reporter [1]. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8058290 From artem.smotrakov at oracle.com Thu Jun 25 10:56:52 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 25 Jun 2015 13:56:52 +0300 Subject: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes Message-ID: <558BDE74.8080002@oracle.com> Hello, Please review this fix for 9. A string which contains a number of principals can be passed to constructor of DelegationPermission. The class parses this string, and extracts principals. But hashCode() method in DelegationPermission uses Permission.getName() to calculate a hash. Permission.getName() method returns the original string which was passed to constructor. As a result, semantically equal instances of DelegationPermission may return different hash codes. Changes: - updated hashCode() method - re-factored equals() and implies() method - removed some unused and commented code in DelegationPermission class - added a test Bug: https://bugs.openjdk.java.net/browse/JDK-8129575 Webrev: http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.01/ Artem From sean.mullan at oracle.com Thu Jun 25 11:14:45 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jun 2015 07:14:45 -0400 Subject: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes In-Reply-To: <558BDE74.8080002@oracle.com> References: <558BDE74.8080002@oracle.com> Message-ID: <558BE2A5.2000800@oracle.com> Looks good. There is an incorrect period at the end of line 152, can you also remove that? Thanks, Sean On 06/25/2015 06:56 AM, Artem Smotrakov wrote: > Hello, > > Please review this fix for 9. > > A string which contains a number of principals can be passed to > constructor of DelegationPermission. The class parses this string, and > extracts principals. But hashCode() method in DelegationPermission uses > Permission.getName() to calculate a hash. Permission.getName() method > returns the original string which was passed to constructor. As a > result, semantically equal instances of DelegationPermission may return > different hash codes. > > Changes: > - updated hashCode() method > - re-factored equals() and implies() method > - removed some unused and commented code in DelegationPermission class > - added a test > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129575 > Webrev: > http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.01/ > > Artem From artem.smotrakov at oracle.com Thu Jun 25 11:33:12 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 25 Jun 2015 14:33:12 +0300 Subject: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes In-Reply-To: <558BE2A5.2000800@oracle.com> References: <558BDE74.8080002@oracle.com> <558BE2A5.2000800@oracle.com> Message-ID: <558BE6F8.9020209@oracle.com> Sure, http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.02/ Artem On 06/25/2015 02:14 PM, Sean Mullan wrote: > Looks good. There is an incorrect period at the end of line 152, can > you also remove that? > > Thanks, > Sean > > On 06/25/2015 06:56 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review this fix for 9. >> >> A string which contains a number of principals can be passed to >> constructor of DelegationPermission. The class parses this string, and >> extracts principals. But hashCode() method in DelegationPermission uses >> Permission.getName() to calculate a hash. Permission.getName() method >> returns the original string which was passed to constructor. As a >> result, semantically equal instances of DelegationPermission may return >> different hash codes. >> >> Changes: >> - updated hashCode() method >> - re-factored equals() and implies() method >> - removed some unused and commented code in DelegationPermission class >> - added a test >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129575 >> Webrev: >> http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.01/ >> >> Artem From zoltan.majo at oracle.com Thu Jun 25 11:49:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 25 Jun 2015 13:49:17 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics Message-ID: <558BEABD.7090907@oracle.com> Hi, please review the patch for JDK-8076112. Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 Problem: There is need to indicate Java methods that are potentially intrinsified by JVM. Solution: Mark intrinsified methods with the jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that are omitted by VM-level intrinsics to the library code. Add a new diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the VM performs the following checks when a class C is loaded: - all intrinsics defined by the VM for class C are present in the loaded class file and are marked; - an intrinsic is defined by the VM for all marked methods of C. If a mismatch is detected, the following is done: - a fastdebug VM prints a warning and then exits; - a product VM prints a warning and unmarked are not intrinsified. Webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ Testing: - JPRT run with the 'hotspot' testset, all tests pass; - all JTREG hotspot tests, all tests pass that pass with a VM version that does not include the patch; all tests were run with -XX:+CheckIntrinsics. Thank you and best regards, Zoltan From weijun.wang at oracle.com Thu Jun 25 12:16:37 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jun 2015 20:16:37 +0800 Subject: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes In-Reply-To: <558BE6F8.9020209@oracle.com> References: <558BDE74.8080002@oracle.com> <558BE2A5.2000800@oracle.com> <558BE6F8.9020209@oracle.com> Message-ID: <558BF125.8000608@oracle.com> Good. Do you need me pushing it for you? --Max On 06/25/2015 07:33 PM, Artem Smotrakov wrote: > Sure, http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.02/ > > Artem > > On 06/25/2015 02:14 PM, Sean Mullan wrote: >> Looks good. There is an incorrect period at the end of line 152, can >> you also remove that? >> >> Thanks, >> Sean >> >> On 06/25/2015 06:56 AM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review this fix for 9. >>> >>> A string which contains a number of principals can be passed to >>> constructor of DelegationPermission. The class parses this string, and >>> extracts principals. But hashCode() method in DelegationPermission uses >>> Permission.getName() to calculate a hash. Permission.getName() method >>> returns the original string which was passed to constructor. As a >>> result, semantically equal instances of DelegationPermission may return >>> different hash codes. >>> >>> Changes: >>> - updated hashCode() method >>> - re-factored equals() and implies() method >>> - removed some unused and commented code in DelegationPermission class >>> - added a test >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8129575 >>> Webrev: >>> http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.01/ >>> >>> Artem > From artem.smotrakov at oracle.com Thu Jun 25 12:20:53 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 25 Jun 2015 15:20:53 +0300 Subject: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes In-Reply-To: <558BF125.8000608@oracle.com> References: <558BDE74.8080002@oracle.com> <558BE2A5.2000800@oracle.com> <558BE6F8.9020209@oracle.com> <558BF125.8000608@oracle.com> Message-ID: <558BF225.3040104@oracle.com> Hi Max, Yes, please push it in to the repository. Artem On 06/25/2015 03:16 PM, Weijun Wang wrote: > Good. > > Do you need me pushing it for you? > > --Max > > On 06/25/2015 07:33 PM, Artem Smotrakov wrote: >> Sure, >> http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.02/ >> >> Artem >> >> On 06/25/2015 02:14 PM, Sean Mullan wrote: >>> Looks good. There is an incorrect period at the end of line 152, can >>> you also remove that? >>> >>> Thanks, >>> Sean >>> >>> On 06/25/2015 06:56 AM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review this fix for 9. >>>> >>>> A string which contains a number of principals can be passed to >>>> constructor of DelegationPermission. The class parses this string, and >>>> extracts principals. But hashCode() method in DelegationPermission >>>> uses >>>> Permission.getName() to calculate a hash. Permission.getName() method >>>> returns the original string which was passed to constructor. As a >>>> result, semantically equal instances of DelegationPermission may >>>> return >>>> different hash codes. >>>> >>>> Changes: >>>> - updated hashCode() method >>>> - re-factored equals() and implies() method >>>> - removed some unused and commented code in DelegationPermission class >>>> - added a test >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8129575 >>>> Webrev: >>>> http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.01/ >>>> >>>> Artem >> From Alan.Bateman at oracle.com Fri Jun 26 08:39:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jun 2015 09:39:30 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558BEABD.7090907@oracle.com> References: <558BEABD.7090907@oracle.com> Message-ID: <558D0FC2.5060903@oracle.com> On 25/06/2015 12:49, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8076112. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 > > Problem: There is need to indicate Java methods that are potentially > intrinsified by JVM. > > Solution: Mark intrinsified methods with the > jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that are > omitted by VM-level intrinsics to the library code. Add a new > diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the > VM performs the following checks when a class C is loaded: > - all intrinsics defined by the VM for class C are present in the > loaded class file and are marked; > - an intrinsic is defined by the VM for all marked methods of C. > > If a mismatch is detected, the following is done: > - a fastdebug VM prints a warning and then exits; > - a product VM prints a warning and unmarked are not intrinsified. > > Webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ I skimmed through the webrev and don't see any significant issues. One thing to double check is that you are are keeping things locally consistent. One example is the convention in many areas to use implFoo rather than fooImpl. Also in some areas then native methods then you'll see foo0 called from foo. I'm just mentioning it because it requires coordination to rename these methods. You might also want to do a quick pass over to ensure other consistency. I see a few places where 8 spec indent is used, that could be just tabs of course. -Alan From zoltan.majo at oracle.com Fri Jun 26 15:43:12 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 26 Jun 2015 17:43:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D0FC2.5060903@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> Message-ID: <558D7310.60807@oracle.com> Hi Alan, thank you for the review! Please see my answers/comments below. On 06/26/2015 10:39 AM, Alan Bateman wrote: > On 25/06/2015 12:49, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8076112. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 >> >> Problem: There is need to indicate Java methods that are potentially >> intrinsified by JVM. >> >> Solution: Mark intrinsified methods with the >> jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that >> are omitted by VM-level intrinsics to the library code. Add a new >> diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the >> VM performs the following checks when a class C is loaded: >> - all intrinsics defined by the VM for class C are present in the >> loaded class file and are marked; >> - an intrinsic is defined by the VM for all marked methods of C. >> >> If a mismatch is detected, the following is done: >> - a fastdebug VM prints a warning and then exits; >> - a product VM prints a warning and unmarked are not intrinsified. >> >> Webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ > > I skimmed through the webrev and don't see any significant issues. > > One thing to double check is that you are are keeping things locally > consistent. One example is the convention in many areas to use implFoo > rather than fooImpl. Also in some areas then native methods then > you'll see foo0 called from foo. I'm just mentioning it because it > requires coordination to rename these methods. I changed the naming of most intrinsified methods from fooImpl to implFoo. In four cases the wrapper of the intrinsified method is already called implFoo. So I decided to use the convention for native methods in those cases and renamed the intrinsic to implFoo0. The four methods are: sun/security/provider/SHA.implCompress0 sun/security/provider/SHA2.implCompress0 sun/security/provider/SHA5.implCompress0 sun/security/provider/implCompressMultiBlock0 > You might also want to do a quick pass over to ensure other > consistency. I see a few places where 8 spec indent is used, that > could be just tabs of course. I updated the indentation as well. Here is the updated webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ Thank you and best regards, Zoltan > > -Alan > > > > From aph at redhat.com Fri Jun 26 16:25:38 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jun 2015 17:25:38 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <5583D414.5050502@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> Message-ID: <558D7D02.6070303@redhat.com> On 06/19/2015 09:34 AM, Andrew Haley wrote: > On 18/06/15 20:28, Vladimir Kozlov wrote: > >> Yes, it is a lot of handwriting but we need it to work on all OSs. > > Sure, I get that. I knew there would be a few goes around with this, > but it's worth the pain for the performance improvement. I made some changes, as requested. Everything is now private static final. The libcall now only calls the runtime code: all allocation is done in Java code. I tested on Solaris using Solaris Studio 12.3 tools, and it's fine. There's one thing I'm not sure about. I now longer allocate scratch memory on the heap. That was only needed for extremely large integers, larger than anyone needs for crypto. Now, if the size of an integer exceeds 16384 bits I do not use the intrinsic, and this allows it to use stack-allocated memory for its scratch space. The main thing I was worried about is that the time spent in Montgomery multiplication. The runtime of the algorithm is O(N^2); if you don't limit the size, the time is unbounded, with no safepoint delay. This would mean that anyone who passed an absurdly large integer to BigInteger.modPow() would see the virtual machine apparently lock up and garbage collection would not run. I note that the multiplyToLen() intrinsic has the same problem. http://cr.openjdk.java.net/~aph/8046943-hs-3/ http://cr.openjdk.java.net/~aph/8046943-jdk-3/ Andrew. From jamil.j.nimeh at oracle.com Fri Jun 26 16:58:03 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 26 Jun 2015 09:58:03 -0700 Subject: RFR: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558B846B.7020803@oracle.com> References: <558361E0.2060409@oracle.com> <558B846B.7020803@oracle.com> Message-ID: <558D849B.4020703@oracle.com> On 06/24/2015 09:32 PM, Xuelei Fan wrote: > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java > ====================================================================== > > A key/trust manager would better to be immutable. > > private final ThreadLocal clientValidator ... > private final ThreadLocal serverValidator ... > > ThreadLocal does not work here for some circumstance. In AIO > programming, multiple connections may share the same thread. Better to > keep key/trust manager and validator immutable. > > I think, using the status as a validate() method parameter, rather than > update the validator status should work. Sorry for taking a bit to respond. I had to look a little deeper into Validator and PKIXValidator, but I understand now where you're going with this. It does seem like a good way to keep things sane both in the multi-threaded and single-thread AIO schemes. I'll get this coded up and issue a new webrev with all the comments up to now. > > Xuelei > > > On 6/19/2015 8:27 AM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have been >> coded and run outside the jtreg framework, but for some reason >> things hang in jtreg. I've included some of the supporting classes >> that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon as >> I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> From james.cheng at oracle.com Fri Jun 26 17:23:08 2015 From: james.cheng at oracle.com (james cheng) Date: Fri, 26 Jun 2015 10:23:08 -0700 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D7310.60807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> Message-ID: <558D8A7C.8020807@oracle.com> Hi Zolt?n, I am not a reviewer. Just saw some typos in code comments: > Here is the updated webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ in SHA*.java, 'implCompressImpl', "as parameter the method" > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ in vmSymbols.hpp.html, 649 // ... e.g.,, 650&651 [ one of the closing parentheses seems superfluous] 673 // ... approriate ... Thanks, -James From artem.smotrakov at oracle.com Fri Jun 26 17:57:19 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 26 Jun 2015 20:57:19 +0300 Subject: [9] RFR: 8074784: Additional tests for XML DSig API In-Reply-To: <55804D6A.9070004@oracle.com> References: <55521D03.5000800@oracle.com> <555CE5EF.5030409@oracle.com> <555CEBA5.30403@oracle.com> <55804D6A.9070004@oracle.com> Message-ID: <558D927F.9060302@oracle.com> Hi Sean, I added new test cases to GenerationTests, please take a look: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.01/ Artem On 06/16/2015 07:23 PM, Sean Mullan wrote: > On 05/20/2015 04:16 PM, Artem Smotrakov wrote: >> Hi Sean, >> >> Yes, at first, I thought about updating the existing tests in >> test/javax/xml/crypto/dsig directory. But then I noticed that both >> GenerationTests and ValidationTests has ~30 test cases. And new >> Detached.java test contains >30 test cases. If one of test cases fails, >> JTREG will show that full test failed. As a result, it may hide failures >> of other test cases (an engineer should look at logs carefully). > > You could always change that to continue on error and run all tests > before reporting a failure. That was just originally the way the test > was created, it isn't set in stone. > >> Also it >> may be better to split tests if possible when some tools for automated >> failures analysis is used (for example, Java SQE uses such a tool). >> >> That was the main reason why I added a separate test. Not sure if >> performance may be an issue, I have not done any measurement. > > Yes, but there is still a lot of common infrastructure in this test > and ValidationTests that could be combined. You have made use of > lambdas and streams to create a nice way to structure and run the > different variants of tests. But a detached signature is really just > another variant, and I think your test could be easily adapted to also > test enveloped and enveloping signatures, as well as the other cases > in ValidationTests. So, it would be nice to combine these tests. I > would be ok with filing a follow-on issue to do that, though. > > I noticed a few typos: > > 151: s/fot/for > 332: s/transfrom/transform/ > 418: s/validaition/validation/ > > I also would recommend reordering the imports in alphabetical order. > > Looks fine otherwise. > > Thanks, > Sean > >> >> Artem >> >> On 05/20/2015 10:52 PM, Sean Mullan wrote: >>> Hi Artem, >>> >>> Is there a reason this needs to be a separate test? It seems like it >>> would be better to fold it into the existing GenerationTests and >>> ValidationTests in the test/javax/xml/crypto/dsig directory, so you >>> could reuse common code. >>> >>> Thanks, >>> Sean >>> >>> On 05/12/2015 11:32 AM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review a new test for generating and validation of detached XML >>>> digital signatures. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074784 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.00/ >>>> >>>> Artem >> From jason.uh at oracle.com Fri Jun 26 22:25:47 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 26 Jun 2015 15:25:47 -0700 Subject: [9] RFR: Remove sun.security.util.ObjectIdentifier.equals(ObjectIdentifier) method Message-ID: <558DD16B.70202@oracle.com> Please review this fix, which removes the overloaded sun.security.util.ObjectIdentifier.equals(ObjectIdentifier) method. webrev: http://cr.openjdk.java.net/~juh/8022444/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8022444 Thanks, Jason From mandy.chung at oracle.com Sat Jun 27 01:14:38 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Jun 2015 18:14:38 -0700 Subject: Review Request: 8130007: Update security tests to use Security.getProvider to get security provider Message-ID: <846E6A61-A2CD-48D6-A715-32D174FE10F5@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8130007/webrev.00/ This patch removes the use of internal API and use Security.getProvider where appropriate. Valerie and I both contributes to this patch. Mandy From aph at redhat.com Sat Jun 27 08:05:34 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 27 Jun 2015 09:05:34 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558BEABD.7090907@oracle.com> References: <558BEABD.7090907@oracle.com> Message-ID: <558E594E.7080906@redhat.com> On 25/06/15 12:49, Zolt?n Maj? wrote: > Problem: There is need to indicate Java methods that are potentially > intrinsified by JVM. It's a great idea but is it a good name? HotSpot is not the only Java VM. Do we expect people from to come along and add J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? Andrew. From weijun.wang at oracle.com Sat Jun 27 09:25:25 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 27 Jun 2015 17:25:25 +0800 Subject: RFR 8069253: javax/net/ssl/TLS/TestJSSE.java failed on Mac Message-ID: <558E6C05.3030606@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8069253/webrev.00/ This is about an intermittent test failure that shows Caused by: java.lang.ArrayIndexOutOfBoundsException: 1 at java.util.ArrayList.add(ArrayList.java:461) at CipherTestUtils.addFailure(CipherTestUtils.java:314) Looks like the EXCEPTIONS is accessed by multiple threads at the same time. Thanks Max From jamil.j.nimeh at oracle.com Sat Jun 27 15:06:31 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 27 Jun 2015 08:06:31 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558361E0.2060409@oracle.com> References: <558361E0.2060409@oracle.com> Message-ID: <558EBBF7.3010805@oracle.com> Hello all, I've posted an updated webrev based on comments I've received so far: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 Thanks, --Jamil On 06/18/2015 05:27 PM, Jamil Nimeh wrote: > Hello all, > > I have a first cut at the OCSP stapling webrev posted for your review: > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ > > A couple items to note: > > * I'm in the process of updating the JEP with some more details. I > should be done with these changes by tonight (PDT). > * Missing are some of the TLS end-to-end tests. These tests have > been coded and run outside the jtreg framework, but for some > reason things hang in jtreg. I've included some of the supporting > classes that these tests will use (CertificateBuilder.java and > SimpleOCSPResponder.java) so folks could review those if they're > interested. I will update the webrev and notify the list as soon > as I've got the tests working in jtreg. > > Thanks to everyone who has helped along the way. > > --Jamil > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jun 28 19:21:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Jun 2015 20:21:12 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D7310.60807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> Message-ID: <55904928.9050909@oracle.com> On 26/06/2015 16:43, Zolt?n Maj? wrote: > > I updated the indentation as well. > > Here is the updated webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ > > Thank you and best regards, > Thanks, looks like my comments are addressed so looks good to me. -Alan From xuelei.fan at oracle.com Mon Jun 29 01:07:22 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jun 2015 09:07:22 +0800 Subject: RFR 8069253: javax/net/ssl/TLS/TestJSSE.java failed on Mac In-Reply-To: <558E6C05.3030606@oracle.com> References: <558E6C05.3030606@oracle.com> Message-ID: <55909A4A.8030808@oracle.com> Looks fine to me. Thanks, Xuelei On 6/27/2015 5:25 PM, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8069253/webrev.00/ > > This is about an intermittent test failure that shows > > Caused by: java.lang.ArrayIndexOutOfBoundsException: 1 > at java.util.ArrayList.add(ArrayList.java:461) > at CipherTestUtils.addFailure(CipherTestUtils.java:314) > > Looks like the EXCEPTIONS is accessed by multiple threads at the same time. > > Thanks > Max From weijun.wang at oracle.com Mon Jun 29 07:55:25 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jun 2015 15:55:25 +0800 Subject: RFR 8058849: test/sun/security/krb5/config/dns.sh needs to re-examined or replaced Message-ID: <5590F9ED.80200@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8058849/webrev.00 The overridden NamingManager needs to return a Context object whose getAttributes() method returns hard coded data. Since Context includes a lot of interface methods, choosing a non-abstract child and only overriding its getAttributes() method will make the code much shorter. Before the fix, com.sun.jndi.dns.DnsContext is chosen but unfortunately it does not belong to java.naming module anymore. We now choose InitialDirContext instead. Thanks Max From Alan.Bateman at oracle.com Mon Jun 29 08:02:51 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Jun 2015 09:02:51 +0100 Subject: RFR 8058849: test/sun/security/krb5/config/dns.sh needs to re-examined or replaced In-Reply-To: <5590F9ED.80200@oracle.com> References: <5590F9ED.80200@oracle.com> Message-ID: <5590FBAB.4080201@oracle.com> On 29/06/2015 08:55, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8058849/webrev.00 > > The overridden NamingManager needs to return a Context object whose > getAttributes() method returns hard coded data. Since Context includes > a lot of interface methods, choosing a non-abstract child and only > overriding its getAttributes() method will make the code much shorter. > Before the fix, com.sun.jndi.dns.DnsContext is chosen but > unfortunately it does not belong to java.naming module anymore. We now > choose InitialDirContext instead. So it's not that the DNS provider is in own module, it is that it no longer defined to the boot loader. In any case, the change looks okay to me. Trivially, I think I would use specific imports rather than changing it a wildcard. -Alan. From weijun.wang at oracle.com Mon Jun 29 08:09:47 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jun 2015 16:09:47 +0800 Subject: RFR 8058849: test/sun/security/krb5/config/dns.sh needs to re-examined or replaced In-Reply-To: <5590FBAB.4080201@oracle.com> References: <5590F9ED.80200@oracle.com> <5590FBAB.4080201@oracle.com> Message-ID: <5590FD4B.4010008@oracle.com> On 06/29/2015 04:02 PM, Alan Bateman wrote: > > In any case, the change looks okay to me. Trivially, I think I would use > specific imports rather than changing it a wildcard. IntelliJ IDEA automatically does this for me: 1. I am typing InitialDirCo and it hints InitialDirContext, I accept it 2. An import for InitialDirContext is automatically added 3. And it notices there are >=5 classes from that same package and automatically shrink them to a single wildcard import I can turn it off. --Max > > -Alan. From vladimir.kozlov at oracle.com Mon Jun 29 08:37:44 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Jun 2015 01:37:44 -0700 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <558D7D02.6070303@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> Message-ID: <559103D8.1010302@oracle.com> Hi, Andrew Did you file RFE for this change? 8046943 is JEP. typo? "less" -> "more". + * number of ints in the number is less than this value we do not + * use the intrinsic. + */ + private static final int MONTGOMERY_INTRINSIC_THRESHOLD = 512; trailing spaces: src/java.base/share/classes/java/math/BigInteger.java:273: Trailing whitespace src/java.base/share/classes/java/math/BigInteger.java:2770: Trailing whitespace I ran changes through JPRT and linux/solaris passed - thanks. Next step - Windows: C:\jprt\T\P1\s\hotspot\src\cpu\x86\vm\sharedRuntime_x86_64.cpp(26) : fatal error C1083: Cannot open include file: 'alloca.h': No such file or directory I am fine with JDK changes. Would be nice to have a test for this change. Do existing tests cover this code? I agree that we should limit size when to invoke multiplyToLen intrinsic too. File bug I will assign it. Thanks, Vladimir On 6/26/15 9:25 AM, Andrew Haley wrote: > On 06/19/2015 09:34 AM, Andrew Haley wrote: >> On 18/06/15 20:28, Vladimir Kozlov wrote: >> >>> Yes, it is a lot of handwriting but we need it to work on all OSs. >> >> Sure, I get that. I knew there would be a few goes around with this, >> but it's worth the pain for the performance improvement. > > I made some changes, as requested. > > Everything is now private static final. > > The libcall now only calls the runtime code: all allocation is done > in Java code. > > I tested on Solaris using Solaris Studio 12.3 tools, and it's fine. > > There's one thing I'm not sure about. I now longer allocate scratch > memory on the heap. That was only needed for extremely large > integers, larger than anyone needs for crypto. Now, if the size of an > integer exceeds 16384 bits I do not use the intrinsic, and this allows > it to use stack-allocated memory for its scratch space. > > The main thing I was worried about is that the time spent in > Montgomery multiplication. The runtime of the algorithm is O(N^2); if > you don't limit the size, the time is unbounded, with no safepoint > delay. This would mean that anyone who passed an absurdly large > integer to BigInteger.modPow() would see the virtual machine > apparently lock up and garbage collection would not run. I note that > the multiplyToLen() intrinsic has the same problem. > > http://cr.openjdk.java.net/~aph/8046943-hs-3/ > http://cr.openjdk.java.net/~aph/8046943-jdk-3/ > > Andrew. > From zoltan.majo at oracle.com Mon Jun 29 09:24:16 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:24:16 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D8A7C.8020807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> <558D8A7C.8020807@oracle.com> Message-ID: <55910EC0.609@oracle.com> Hi James, thank you for your feedback! I've implemented the changes you suggested, here is the updated webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.07/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.07/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.07/ Best regards, Zoltan On 06/26/2015 07:23 PM, james cheng wrote: > Hi Zolt?n, > > I am not a reviewer. Just saw some typos in code comments: > >> Here is the updated webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ > > in SHA*.java, 'implCompressImpl', "as parameter the method" > >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ > > in vmSymbols.hpp.html, > 649 // ... e.g.,, > 650&651 [ one of the closing parentheses seems > superfluous] > 673 // ... approriate ... > > Thanks, > -James From zoltan.majo at oracle.com Mon Jun 29 09:24:51 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:24:51 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <55904928.9050909@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> <55904928.9050909@oracle.com> Message-ID: <55910EE3.3060800@oracle.com> On 06/28/2015 09:21 PM, Alan Bateman wrote: > > > On 26/06/2015 16:43, Zolt?n Maj? wrote: >> >> I updated the indentation as well. >> >> Here is the updated webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ >> >> Thank you and best regards, >> > Thanks, looks like my comments are addressed so looks good to me. Thank you, Alan! Best regards, Zoltan > > -Alan > From aph at redhat.com Mon Jun 29 09:32:47 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 10:32:47 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <559103D8.1010302@oracle.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> Message-ID: <559110BF.4090804@redhat.com> On 29/06/15 09:37, Vladimir Kozlov wrote: > Hi, Andrew > > Did you file RFE for this change? 8046943 is JEP. No; I will do so. > typo? "less" -> "more". > > + * number of ints in the number is less than this value we do not > + * use the intrinsic. > + */ > + private static final int MONTGOMERY_INTRINSIC_THRESHOLD = 512; > > trailing spaces: > src/java.base/share/classes/java/math/BigInteger.java:273: Trailing whitespace > src/java.base/share/classes/java/math/BigInteger.java:2770: Trailing whitespace > > I ran changes through JPRT and linux/solaris passed - thanks. > Next step - Windows: > > C:\jprt\T\P1\s\hotspot\src\cpu\x86\vm\sharedRuntime_x86_64.cpp(26) : fatal error C1083: Cannot open include file: > 'alloca.h': No such file or directory Hmm, okay. This is going to be fun. :-) AFAIK OpenJDK builds with Visual Studio. The VS equivalent of alloca() is called _alloca() and its header file is . I'm going to try to do this untested. I think that autoconf will #include malloc.h on Windows automagically, so all that I have to do is create a #define for alloca() on Windows. > I am fine with JDK changes. > > Would be nice to have a test for this change. Do existing tests > cover this code? They do. jdk/test/com/oracle/security/ucrypto/TestRSA looks like a pretty thorough test. If you make any mistake in the arithmetic RSA decryption simply will not work: the result is corrupt. The risks, then, are mistakes such as accidental side-effects. I don't know any way to test for that. The other possible think I could test for is unusual key sizes. I'll have a look. > I agree that we should limit size when to invoke multiplyToLen > intrinsic too. File bug I will assign it. OK. Andrew. From zoltan.majo at oracle.com Mon Jun 29 09:41:37 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:41:37 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558E594E.7080906@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> Message-ID: <559112D1.5000903@oracle.com> Hi Andrew, On 06/27/2015 10:05 AM, Andrew Haley wrote: > On 25/06/15 12:49, Zolt?n Maj? wrote: >> Problem: There is need to indicate Java methods that are potentially >> intrinsified by JVM. > It's a great idea but is it a good name? HotSpot is not the only Java > VM. Do we expect people from to come along and add > J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? thank you bringing up this issue. The name HotSpotIntrinsicCandidate resulted from a private discussion with Joe Darcy, Brian Goetz, and John Rose. The reason this name was picked is to make clear that a marked method's interaction with the VM (specifically with the HotSpot VM implementation) needs special attention. Best regards, Zoltan > > Andrew. From aph at redhat.com Mon Jun 29 09:45:31 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 10:45:31 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559112D1.5000903@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> Message-ID: <559113BB.1020106@redhat.com> Hi, On 29/06/15 10:41, Zolt?n Maj? wrote: > > On 06/27/2015 10:05 AM, Andrew Haley wrote: >> On 25/06/15 12:49, Zolt?n Maj? wrote: >>> Problem: There is need to indicate Java methods that are potentially >>> intrinsified by JVM. >> It's a great idea but is it a good name? HotSpot is not the only Java >> VM. Do we expect people from to come along and add >> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? > > thank you bringing up this issue. > > The name HotSpotIntrinsicCandidate resulted from a private discussion > with Joe Darcy, Brian Goetz, and John Rose. The reason this name was > picked is to make clear that a marked method's interaction with the VM > (specifically with the HotSpot VM implementation) needs special attention. OK, cool. So has any thought been given to the other VMs? Do you expect that, say, J9 will use the HotSpotIntrinsicCandidate annotattion, or do you expect we will have similar annotations for each VM which uses OpenJDK libraries? Or is the need for this annotation totally HotSpot-specific? Andrew. From zoltan.majo at oracle.com Mon Jun 29 10:41:12 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 12:41:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559113BB.1020106@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> Message-ID: <559120C8.5070208@oracle.com> Hi, On 06/29/2015 11:45 AM, Andrew Haley wrote: > Hi, > > On 29/06/15 10:41, Zolt?n Maj? wrote: >> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>> Problem: There is need to indicate Java methods that are potentially >>>> intrinsified by JVM. >>> It's a great idea but is it a good name? HotSpot is not the only Java >>> VM. Do we expect people from to come along and add >>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >> thank you bringing up this issue. >> >> The name HotSpotIntrinsicCandidate resulted from a private discussion >> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >> picked is to make clear that a marked method's interaction with the VM >> (specifically with the HotSpot VM implementation) needs special attention. > OK, cool. So has any thought been given to the other VMs? Do you > expect that, say, J9 will use the HotSpotIntrinsicCandidate > annotattion, or do you expect we will have similar annotations for > each VM which uses OpenJDK libraries? Or is the need for this > annotation totally HotSpot-specific? the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. Thank you and best regards, Zoltan > > Andrew. From aph at redhat.com Mon Jun 29 13:01:55 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:01:55 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: <559141C3.7000909@redhat.com> On 06/29/2015 01:38 PM, Doug Simon wrote: > I seems just plain wrong for an intrinsic to not implement the same > semantics as the intrinsified method. I would expect an intrinsic to > perform all necessary runtime checks and only have the compiler omit > them if it can prove they are unnecessary. If all intrinsics obeyed > this contract, then there?s no need for the > @HotSpotIntrinsicCandidate annotation from a semantics > perspective. And in terms of the keeping HotSpot in sync with the > JDK, the responsibility should fall entirely on HotSpot to check > that its intrinsics correspond to existing methods. Don't you think you're being rather idealistic? The other side of the argument is that it's much easier to write and maintain the arg-checking code if it's written in Java, and it also has the advantage that it benefits from profile data to guide the JIT. Andrew. From david.lloyd at redhat.com Mon Jun 29 13:19:38 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 29 Jun 2015 08:19:38 -0500 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <559110BF.4090804@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> Message-ID: <559145EA.4010903@redhat.com> On 06/29/2015 04:32 AM, Andrew Haley wrote: > On 29/06/15 09:37, Vladimir Kozlov wrote: >> Hi, Andrew >> >> Did you file RFE for this change? 8046943 is JEP. > > No; I will do so. > >> typo? "less" -> "more". >> >> + * number of ints in the number is less than this value we do not >> + * use the intrinsic. >> + */ >> + private static final int MONTGOMERY_INTRINSIC_THRESHOLD = 512; >> >> trailing spaces: >> src/java.base/share/classes/java/math/BigInteger.java:273: Trailing whitespace >> src/java.base/share/classes/java/math/BigInteger.java:2770: Trailing whitespace >> >> I ran changes through JPRT and linux/solaris passed - thanks. >> Next step - Windows: >> >> C:\jprt\T\P1\s\hotspot\src\cpu\x86\vm\sharedRuntime_x86_64.cpp(26) : fatal error C1083: Cannot open include file: >> 'alloca.h': No such file or directory > > Hmm, okay. This is going to be fun. :-) > > AFAIK OpenJDK builds with Visual Studio. The VS equivalent of > alloca() is called _alloca() and its header file is . I'm > going to try to do this untested. I think that autoconf will #include > malloc.h on Windows automagically, so all that I have to do is create > a #define for alloca() on Windows. Out of curiosity, instead of e.g.: unsigned long *scratch = (unsigned long *)alloca(total_allocation); Could you not just use e.g.: unsigned long scratch[longwords * 4]; and avoid alloca altogether? -- - DML From aph at redhat.com Mon Jun 29 13:24:46 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:24:46 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <559145EA.4010903@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> <559145EA.4010903@redhat.com> Message-ID: <5591471E.7080208@redhat.com> On 06/29/2015 02:19 PM, David M. Lloyd wrote: > Out of curiosity, instead of e.g.: > > unsigned long *scratch = (unsigned long *)alloca(total_allocation); > > Could you not just use e.g.: > > unsigned long scratch[longwords * 4]; > > and avoid alloca altogether? No. Variable-length are now in Standard C but not C++. https://groups.google.com/forum/#!topic/comp.std.c++/K_4lgA1JYeg I imagine that C++ will eventually support them, but not today. Andrew. From aph at redhat.com Mon Jun 29 13:24:56 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:24:56 +0100 Subject: RFR: 8046943: RSA Acceleration In-Reply-To: <559145EA.4010903@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> <559145EA.4010903@redhat.com> Message-ID: <55914728.5060409@redhat.com> On 06/29/2015 02:19 PM, David M. Lloyd wrote: > Out of curiosity, instead of e.g.: > > unsigned long *scratch = (unsigned long *)alloca(total_allocation); > > Could you not just use e.g.: > > unsigned long scratch[longwords * 4]; > > and avoid alloca altogether? No. Variable-length arrays are now in Standard C but not C++. https://groups.google.com/forum/#!topic/comp.std.c++/K_4lgA1JYeg I imagine that C++ will eventually support them, but not today. Andrew. From sean.mullan at oracle.com Mon Jun 29 15:07:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Jun 2015 11:07:35 -0400 Subject: Review Request: 8130007: Update security tests to use Security.getProvider to get security provider In-Reply-To: <846E6A61-A2CD-48D6-A715-32D174FE10F5@oracle.com> References: <846E6A61-A2CD-48D6-A715-32D174FE10F5@oracle.com> Message-ID: <55915F37.90008@oracle.com> Looks good. --Sean On 06/26/2015 09:14 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8130007/webrev.00/ > > This patch removes the use of internal API and use Security.getProvider where appropriate. Valerie and I both contributes to this patch. > > Mandy > From sean.mullan at oracle.com Mon Jun 29 15:57:45 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Jun 2015 11:57:45 -0400 Subject: [9] RFR: Remove sun.security.util.ObjectIdentifier.equals(ObjectIdentifier) method In-Reply-To: <558DD16B.70202@oracle.com> References: <558DD16B.70202@oracle.com> Message-ID: <55916AF9.4070603@oracle.com> Looks good to me. --Sean On 06/26/2015 06:25 PM, Jason Uh wrote: > Please review this fix, which removes the overloaded > sun.security.util.ObjectIdentifier.equals(ObjectIdentifier) method. > > webrev: http://cr.openjdk.java.net/~juh/8022444/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8022444 > > Thanks, > Jason From doug.simon at oracle.com Mon Jun 29 12:38:12 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 14:38:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559120C8.5070208@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: > On Jun 29, 2015, at 12:41 PM, Zolt?n Maj? wrote: > > Hi, > > > On 06/29/2015 11:45 AM, Andrew Haley wrote: >> Hi, >> >> On 29/06/15 10:41, Zolt?n Maj? wrote: >>> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>>> Problem: There is need to indicate Java methods that are potentially >>>>> intrinsified by JVM. >>>> It's a great idea but is it a good name? HotSpot is not the only Java >>>> VM. Do we expect people from to come along and add >>>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >>> thank you bringing up this issue. >>> >>> The name HotSpotIntrinsicCandidate resulted from a private discussion >>> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >>> picked is to make clear that a marked method's interaction with the VM >>> (specifically with the HotSpot VM implementation) needs special attention. >> OK, cool. So has any thought been given to the other VMs? Do you >> expect that, say, J9 will use the HotSpotIntrinsicCandidate >> annotattion, or do you expect we will have similar annotations for >> each VM which uses OpenJDK libraries? Or is the need for this >> annotation totally HotSpot-specific? > > the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: > > (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. I seems just plain wrong for an intrinsic to not implement the same semantics as the intrinsified method. I would expect an intrinsic to perform all necessary runtime checks and only have the compiler omit them if it can prove they are unnecessary. If all intrinsics obeyed this contract, then there?s no need for the @HotSpotIntrinsicCandidate annotation from a semantics perspective. And in terms of the keeping HotSpot in sync with the JDK, the responsibility should fall entirely on HotSpot to check that its intrinsics correspond to existing methods. > (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. > > Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. > > So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. That is true which is a great reason to avoid an annotation altogether if possible. -Doug From doug.simon at oracle.com Mon Jun 29 17:48:46 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 19:48:46 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559141C3.7000909@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> Message-ID: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> > On Jun 29, 2015, at 3:01 PM, Andrew Haley wrote: > > On 06/29/2015 01:38 PM, Doug Simon wrote: > >> I seems just plain wrong for an intrinsic to not implement the same >> semantics as the intrinsified method. I would expect an intrinsic to >> perform all necessary runtime checks and only have the compiler omit >> them if it can prove they are unnecessary. If all intrinsics obeyed >> this contract, then there?s no need for the >> @HotSpotIntrinsicCandidate annotation from a semantics >> perspective. And in terms of the keeping HotSpot in sync with the >> JDK, the responsibility should fall entirely on HotSpot to check >> that its intrinsics correspond to existing methods. > > Don't you think you're being rather idealistic? The other side of the > argument is that it's much easier to write and maintain the > arg-checking code if it's written in Java, and it also has the > advantage that it benefits from profile data to guide the JIT. As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? I understand that writing the checking logic in Java is desirable. Indeed, it?s possible: http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java#l95 Adding these checks did not impact the score for the SPECjvm2008 crypto.aes benchmark on Graal. I?m not sure if this performance non-impact holds for all existing intrinsics but unless one can guarantee an intrinsified method will only be executed after the necessary checks have been performed, one is asking for trouble. Maybe hiding the intrinsifiable methods from reflection is sufficient? -Doug From sibabrata.sahoo at oracle.com Mon Jun 29 18:14:20 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 29 Jun 2015 11:14:20 -0700 (PDT) Subject: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property Message-ID: <67c798e8-939f-4ea2-b3e9-cc66cf41bea8@default> Hello, Please review this fix for 9. The test uses JAAS authentication over Kerberos. The kerberos5 principal name can be specified in the configuration entry by using the option principal. The principal can also be set using the system property sun.security.krb5.principal. This property is checked during login verification by Krb5LoginModule. If this property is not set, then the principal name from the configuration is used. In the case where the principal property is not set and the principal entry also does not exist in the configuration file, then user is prompted for the name depending on the underlying kerberos5 configuration, else the login failure occurs. Changes: - Added a new test. - Moved the startKDC() method from UnboundSSLUtils.java to KDC.java. - Updated the method reference accordingly in depending tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8075301 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Easmotrak/siba/8075301/webrev.00/"http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.00/ Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Mon Jun 29 20:47:41 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Jun 2015 13:47:41 -0700 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: > > As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? The answer is simple: We mark the dangerous method private. I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways. At that point having a surprising intrinsic is the least of our problems. > I understand that writing the checking logic in Java is desirable. Indeed, that is the key compromise here. Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle. You need Maxine/Graal snippets or real Java code to get it right. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jun 30 02:14:42 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Jun 2015 10:14:42 +0800 Subject: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property In-Reply-To: <67c798e8-939f-4ea2-b3e9-cc66cf41bea8@default> References: <67c798e8-939f-4ea2-b3e9-cc66cf41bea8@default> Message-ID: <5591FB92.1040807@oracle.com> Hi Siba There is one case not covered: 1. sun.security.krb5.principal not set 2. an existing principal set in jaas.conf In your jaas.conf.principal, a non-existing 1USER principal is used. In fact, why not add both accounts into the KDC and then check if the login user is what you expected? Historically, all krb5 tests that uses KDC.java is inside the auto sub-directory. Now that there are so many tests inside, I would still like creating sub-directories inside it instead of outside auto. Also, do you intent to add more tests using KrbOption? The current usage of it looks unnecessary. I mean, why not simply public static void main(String[] args) throws Exception { runTest(true, "jaas.conf.principal", "krb5.conf", "USER at TEST.REALM"); runTest(false, "jaas.conf.principal", "krb5.conf", null); runTest(true, "jaas.conf.noPrincipal", "krb5.conf", "USER at TEST.REALM"); runTest(false, "jaas.conf.noPrincipal", "krb5.conf", null); } KDC.java: Please make startKDC() public as it's designed to call from outside. Thanks Max On 06/30/2015 02:14 AM, Sibabrata Sahoo wrote: > Hello, > > Please review this fix for 9. > > The test uses JAAS authentication over Kerberos. The kerberos5 principal > name can be specified in the configuration entry by using the option > principal. The principal can also be set using the system property > sun.security.krb5.principal. This property is checked during login > verification by Krb5LoginModule. If this property is not set, then the > principal name from the configuration is used. In the case where the > principal property is not set and the principal entry also does not > exist in the configuration file, then user is prompted for the name > depending on the underlying kerberos5 configuration, else the login > failure occurs. > > Changes: > > -Added a new test. > > -Moved the startKDC() method from UnboundSSLUtils.java to KDC.java. > > -Updated the method reference accordingly in depending tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075301 > > Webrev: > > http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.00/ > > > Thanks, > > Siba > From xuelei.fan at oracle.com Tue Jun 30 05:29:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Jun 2015 13:29:09 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558EBBF7.3010805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> Message-ID: <55922925.5000806@oracle.com> src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ================================================================== minor comment: 1603 if (!staplingActive) { 1604 fatalSE(Alerts.alert_unexpected_message, 1605 "Unexpected CertificateStatus message"); This block may be redundant. If staplingActive is not true, I think certificateStatus() is unlikely get called. ----------------- minor comment: checkServerCerts(deferredCerts); session.setPeerCertificates(deferredCerts); The above two method are always called together. Is it a little bit friendly to merge them together? private void checkServerCerts(X509Certificate[] certs) ... { ... session.setPeerCertificates(certs); } src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java ====================================================================== You may want to remove the block of addResponses() implementation. src/java.base/share/classes/sun/security/validator/PKIXValidator.java ===================================================================== minor comment: Is it more instinctive if changing the parameter name from responseList to ocspResponses, and the method name from addResponses() to addOcspResponses()? Same for SimpleValidator.java and Validator.java. ---------------- line 393-404. For performance friendly, it is nice to construct the map if and only if the map get used. if (pkixParams.isRevocationEnabled()) { // make the map try { ... // use the map } } ----------- 430 revChecker.setOcspResponses(responseMap); User specified OCSP responses are overridden, which should be respected. The behavior is not what the user expected. src/java.base/share/classes/sun/security/validator/Validator.java ===================================================================== 207 public final String getType() { Looks like this method does not get used. Is it redundant? Xuelei On 6/27/2015 11:06 PM, Jamil Nimeh wrote: > Hello all, I've posted an updated webrev based on comments I've received > so far: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 > > Thanks, > --Jamil > > On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have >> been coded and run outside the jtreg framework, but for some >> reason things hang in jtreg. I've included some of the supporting >> classes that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon >> as I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> > From zoltan.majo at oracle.com Tue Jun 30 08:24:34 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 30 Jun 2015 10:24:34 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <55925242.4070909@oracle.com> On 06/29/2015 10:47 PM, John Rose wrote: > On Jun 29, 2015, at 10:48 AM, Doug Simon > wrote: >> >> As I understand it, part of this change is to split intrinsification >> into one method that does the checks that then calls a second method >> which the VM may intrinsify on the assumption all checks have been >> performed by the first method. What?s to prevent a direct call to the >> latter via reflection that by-passes the first method? > > The answer is simple: We mark the dangerous method private. > > I assume you are thinking about setAccessible, but if that's allowed > there's nothing to prevent people from taking whole system down in a > hundred different ways. At that point having a surprising intrinsic > is the least of our problems. > >> I understand that writing the checking logic in Java is desirable. > > Indeed, that is the key compromise here. Coding the required checks > in assembly code or compiler IR is (as we all know) a losing battle. > You need Maxine/Graal snippets or real Java code to get it right. Thank you, Doug, for bringing up these issues. Thank you, John, for the clarifications. Best regards, Zoltan > > ? John From xuelei.fan at oracle.com Tue Jun 30 09:46:53 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Jun 2015 17:46:53 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558EBBF7.3010805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> Message-ID: <5592658D.5090004@oracle.com> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java ================================================================== 676 private List encodedResponses = new ArrayList<>(4); 4 may be not the best estimate. Maybe better to make the initialization in the constructor. --------------- line 713/714, 730/731 throws SSLHandshakeException for extension constructor in server side. That's unlikely to happen, I think. I was wondering, if CertificateStatus cannot be constructed, the server may not want to send the message, rather than terminate the connection immediately. ------------- 674 private int encodedResponseLen; s/encodedResponseLen/encodedResponsesLen Suggest to add -------------- 820 if (respBytes != null) { 821 s.putBytes24(respBytes); 822 } else { 823 s.putBytes24(new byte[0]); 824 } HandshakeOutStream.putBytes24() accepts null parameter. ------------- line 827/828, unlikely to happen. I would suggest you add a comment or remove the lines. Xuelei On 6/27/2015 11:06 PM, Jamil Nimeh wrote: > Hello all, I've posted an updated webrev based on comments I've received > so far: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 > > Thanks, > --Jamil > > On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have >> been coded and run outside the jtreg framework, but for some >> reason things hang in jtreg. I've included some of the supporting >> classes that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon >> as I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> > From sibabrata.sahoo at oracle.com Tue Jun 30 10:20:40 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 30 Jun 2015 03:20:40 -0700 (PDT) Subject: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property In-Reply-To: <5591FB92.1040807@oracle.com> References: <67c798e8-939f-4ea2-b3e9-cc66cf41bea8@default> <5591FB92.1040807@oracle.com> Message-ID: <2b938c65-c3c4-44df-91de-9e61102cd038@default> Hi Max, Here is the updated webrev link. http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.02/ Changes: - More test cases added and due to that there are changes in policy file. [createLoginContext.]. - Combined the jaas configuration to a single file name "jaas.conf". - Created a sub-directory inside the auto folder and moved the new Test into it. - Removed KrbOption.java. - startKDC() is made public. - Removed @Module annotation for now. This will be addressed as part of this bug [https://bugs.openjdk.java.net/browse/JDK-8130112] Thanks, Siba -----Original Message----- From: Weijun Wang Sent: Tuesday, June 30, 2015 7:45 AM To: Sibabrata Sahoo; Security Libs OpenJDK Subject: Re: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property Hi Siba There is one case not covered: 1. sun.security.krb5.principal not set 2. an existing principal set in jaas.conf In your jaas.conf.principal, a non-existing 1USER principal is used. In fact, why not add both accounts into the KDC and then check if the login user is what you expected? Historically, all krb5 tests that uses KDC.java is inside the auto sub-directory. Now that there are so many tests inside, I would still like creating sub-directories inside it instead of outside auto. Also, do you intent to add more tests using KrbOption? The current usage of it looks unnecessary. I mean, why not simply public static void main(String[] args) throws Exception { runTest(true, "jaas.conf.principal", "krb5.conf", "USER at TEST.REALM"); runTest(false, "jaas.conf.principal", "krb5.conf", null); runTest(true, "jaas.conf.noPrincipal", "krb5.conf", "USER at TEST.REALM"); runTest(false, "jaas.conf.noPrincipal", "krb5.conf", null); } KDC.java: Please make startKDC() public as it's designed to call from outside. Thanks Max On 06/30/2015 02:14 AM, Sibabrata Sahoo wrote: > Hello, > > Please review this fix for 9. > > The test uses JAAS authentication over Kerberos. The kerberos5 > principal name can be specified in the configuration entry by using > the option principal. The principal can also be set using the system > property sun.security.krb5.principal. This property is checked during > login verification by Krb5LoginModule. If this property is not set, > then the principal name from the configuration is used. In the case > where the principal property is not set and the principal entry also > does not exist in the configuration file, then user is prompted for > the name depending on the underlying kerberos5 configuration, else the > login failure occurs. > > Changes: > > -Added a new test. > > -Moved the startKDC() method from UnboundSSLUtils.java to KDC.java. > > -Updated the method reference accordingly in depending tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075301 > > Webrev: > > http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.00/ > > > Thanks, > > Siba > From weijun.wang at oracle.com Tue Jun 30 10:28:44 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Jun 2015 18:28:44 +0800 Subject: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property In-Reply-To: <2b938c65-c3c4-44df-91de-9e61102cd038@default> References: <67c798e8-939f-4ea2-b3e9-cc66cf41bea8@default> <5591FB92.1040807@oracle.com> <2b938c65-c3c4-44df-91de-9e61102cd038@default> Message-ID: <55926F5C.7000005@oracle.com> Hi Siba The code change looks fine. If you need someone to sponsor the bug and push the changeset, just tell me your openjdk user name (or email if you haven't one yet) and I'll do that for you. Please make sure the changeset passes jcheck first. Thanks Max On 06/30/2015 06:20 PM, Sibabrata Sahoo wrote: > Hi Max, > > Here is the updated webrev link. > http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.02/ > > Changes: > - More test cases added and due to that there are changes in policy file. [createLoginContext.]. > - Combined the jaas configuration to a single file name "jaas.conf". > - Created a sub-directory inside the auto folder and moved the new Test into it. > - Removed KrbOption.java. > - startKDC() is made public. > - Removed @Module annotation for now. This will be addressed as part of this bug [https://bugs.openjdk.java.net/browse/JDK-8130112] > > Thanks, > Siba > > > > -----Original Message----- > From: Weijun Wang > Sent: Tuesday, June 30, 2015 7:45 AM > To: Sibabrata Sahoo; Security Libs OpenJDK > Subject: Re: [9] RFR: 8075301: Tests for sun.security.krb5.principal system property > > Hi Siba > > There is one case not covered: > > 1. sun.security.krb5.principal not set > 2. an existing principal set in jaas.conf > > In your jaas.conf.principal, a non-existing 1USER principal is used. In fact, why not add both accounts into the KDC and then check if the login user is what you expected? > > Historically, all krb5 tests that uses KDC.java is inside the auto sub-directory. Now that there are so many tests inside, I would still like creating sub-directories inside it instead of outside auto. > > Also, do you intent to add more tests using KrbOption? The current usage of it looks unnecessary. I mean, why not simply > > public static void main(String[] args) throws Exception { > runTest(true, "jaas.conf.principal", > "krb5.conf", "USER at TEST.REALM"); > runTest(false, "jaas.conf.principal", > "krb5.conf", null); > runTest(true, "jaas.conf.noPrincipal", > "krb5.conf", "USER at TEST.REALM"); > runTest(false, "jaas.conf.noPrincipal", > "krb5.conf", null); > } > > KDC.java: Please make startKDC() public as it's designed to call from outside. > > Thanks > Max > > On 06/30/2015 02:14 AM, Sibabrata Sahoo wrote: >> Hello, >> >> Please review this fix for 9. >> >> The test uses JAAS authentication over Kerberos. The kerberos5 >> principal name can be specified in the configuration entry by using >> the option principal. The principal can also be set using the system >> property sun.security.krb5.principal. This property is checked during >> login verification by Krb5LoginModule. If this property is not set, >> then the principal name from the configuration is used. In the case >> where the principal property is not set and the principal entry also >> does not exist in the configuration file, then user is prompted for >> the name depending on the underlying kerberos5 configuration, else the >> login failure occurs. >> >> Changes: >> >> -Added a new test. >> >> -Moved the startKDC() method from UnboundSSLUtils.java to KDC.java. >> >> -Updated the method reference accordingly in depending tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075301 >> >> Webrev: >> >> http://cr.openjdk.java.net/~asmotrak/siba/8075301/webrev.00/ >> >> >> Thanks, >> >> Siba >> From vincent.x.ryan at oracle.com Tue Jun 30 17:34:53 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 30 Jun 2015 18:34:53 +0100 Subject: [9] review request for 8130151: Exclude sun/security/provider/SecureRandom/StrongSecureRandom.java from testruns on MacOSX 10.10 Message-ID: <1199E054-CD38-4A7C-AAD0-75F62E0FC2B8@oracle.com> Please approve this temporary addition to the ProblemList to exclude a single test on Mac OS X 10.10 only. It is related to the issue being tracked by https://bugs.openjdk.java.net/browse/JDK-8051770 Bug: https://bugs.openjdk.java.net/browse/JDK-8130151 Webrev: http://cr.openjdk.java.net/~vinnie/8130151/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Jun 30 17:49:30 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Jun 2015 18:49:30 +0100 Subject: RFR: 8130150: RSA Acceleration In-Reply-To: <559110BF.4090804@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> Message-ID: <5592D6AA.8020509@redhat.com> On 06/29/2015 10:32 AM, Andrew Haley wrote: > On 29/06/15 09:37, Vladimir Kozlov wrote: >> Hi, Andrew >> >> Did you file RFE for this change? 8046943 is JEP. > > No; I will do so. Done. >> typo? "less" -> "more". >> >> + * number of ints in the number is less than this value we do not >> + * use the intrinsic. >> + */ >> + private static final int MONTGOMERY_INTRINSIC_THRESHOLD = 512; >> >> trailing spaces: >> src/java.base/share/classes/java/math/BigInteger.java:273: Trailing whitespace >> src/java.base/share/classes/java/math/BigInteger.java:2770: Trailing whitespace >> >> I ran changes through JPRT and linux/solaris passed - thanks. >> Next step - Windows: In the end I had to punt on Windows. It's ifdef'd out for someone who works on Windows to fix. >> I am fine with JDK changes. >> >> Would be nice to have a test for this change. Do existing tests >> cover this code? > > They do. They don't. The RSA tests don't run for long enough to test the intrinsics. I wrote a new test for Montgomery multiplication. >> I agree that we should limit size when to invoke multiplyToLen >> intrinsic too. File bug I will assign it. > > OK. JDK-8130154 New webrevs: http://cr.openjdk.java.net/~aph/8130150-jdk http://cr.openjdk.java.net/~aph/8130150-hs/ Andrew. From sean.mullan at oracle.com Tue Jun 30 18:35:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Jun 2015 14:35:06 -0400 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558EBBF7.3010805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> Message-ID: <5592E15A.4080406@oracle.com> Hi Jamil, On 06/27/2015 11:06 AM, Jamil Nimeh wrote: > Hello all, I've posted an updated webrev based on comments I've received > so far: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 I didn't have time to review the tests yet but was able to review most of the code in the other files, except for StatusResponseManager which I believe has been reviewed already. Here are my comments ... General comments: - the text after an @param or @throws tag generally starts with a lower-case letter, ex: "the ...". I noticed you started many of these with a capital letter. Also some of the {@link}s to common classes like String and List are probably unnecessary esp. for javadoc of internal methods. - I'm not sure if this is the case, but you can generally avoid cloning or making copies of parameters if the usage is internal and they don't cross the supported API boundary. There may be some unnecessary clones of the encoded OCSP response bytes. - For new classes and methods, don't make them public unless they are needed outside of the package. Make them private or package-private, if called by other classes in the same package. I'm not sure if this is the case, but just a general comment/thing to check. * ExtendedSSLSession 120: "Obtains" sounds like invoking this method causes a network request to get it. Suggest "Returns" instead. * ServerHandshaker 59: can you add what time unit this is to the comment? * X509TrustManagerImpl addResponses looks like it isn't called by anything and can be removed. --Sean > > Thanks, > --Jamil > > On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have >> been coded and run outside the jtreg framework, but for some >> reason things hang in jtreg. I've included some of the supporting >> classes that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon >> as I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> > From jamil.j.nimeh at oracle.com Tue Jun 30 22:39:22 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 30 Jun 2015 15:39:22 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <5592658D.5090004@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> Message-ID: <55931A9A.9080003@oracle.com> Hi Xuelei, I'm working on your comments now. Thanks for all the useful feedback. I'm working on the comments in your other emails, too. On 06/30/2015 02:46 AM, Xuelei Fan wrote: > src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java > ================================================================== > > 676 private List encodedResponses = new ArrayList<>(4); > > 4 may be not the best estimate. Maybe better to make the initialization > in the constructor. Fair enough. I've moved it into the constructors. It's based on the chain length in the version where the chain is provided, and it uses the default constructor in the case where you're bringing it in from a HandshakeInStream (since you don't know the number of objects up-front). > > --------------- > line 713/714, 730/731 throws SSLHandshakeException for extension > constructor in server side. That's unlikely to happen, I think. I was > wondering, if CertificateStatus cannot be constructed, the server may > not want to send the message, rather than terminate the connection > immediately. I think you're right. While the exception is unlikely, I'd like to have the HandshakeMessage throw the exception if something bad happens. I do however, agree that we shouldn't make it a fatal error. I'll catch the exception in ServerHandshaker, log it, and just not send the message as you suggested since that is legal. OK? > > ------------- > 674 private int encodedResponseLen; > s/encodedResponseLen/encodedResponsesLen > > Suggest to add > > -------------- > 820 if (respBytes != null) { > 821 s.putBytes24(respBytes); > 822 } else { > 823 s.putBytes24(new byte[0]); > 824 } > > HandshakeOutStream.putBytes24() accepts null parameter. Yeah, that is a better way to do it and not have the unnecessary object creation. > > ------------- > line 827/828, unlikely to happen. I would suggest you add a comment or > remove the lines. I'll comment it. > > Xuelei > > On 6/27/2015 11:06 PM, Jamil Nimeh wrote: >> Hello all, I've posted an updated webrev based on comments I've received >> so far: >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 >> >> Thanks, >> --Jamil >> >> On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I have a first cut at the OCSP stapling webrev posted for your review: >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >>> >>> A couple items to note: >>> >>> * I'm in the process of updating the JEP with some more details. I >>> should be done with these changes by tonight (PDT). >>> * Missing are some of the TLS end-to-end tests. These tests have >>> been coded and run outside the jtreg framework, but for some >>> reason things hang in jtreg. I've included some of the supporting >>> classes that these tests will use (CertificateBuilder.java and >>> SimpleOCSPResponder.java) so folks could review those if they're >>> interested. I will update the webrev and notify the list as soon >>> as I've got the tests working in jtreg. >>> >>> Thanks to everyone who has helped along the way. >>> >>> --Jamil >>> >>> From jamil.j.nimeh at oracle.com Tue Jun 30 23:38:42 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 30 Jun 2015 16:38:42 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55922925.5000806@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55922925.5000806@oracle.com> Message-ID: <55932882.50805@oracle.com> On 06/29/2015 10:29 PM, Xuelei Fan wrote: > src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > ================================================================== > minor comment: > > 1603 if (!staplingActive) { > 1604 fatalSE(Alerts.alert_unexpected_message, > 1605 "Unexpected CertificateStatus message"); > > This block may be redundant. If staplingActive is not true, I think > certificateStatus() is unlikely get called. I think you're right. I think the HandshakeStateManager will yell if CertificateStatus is sent when status_request isn't set by both endpoints. I'll remove this check. > > ----------------- > minor comment: > > checkServerCerts(deferredCerts); > session.setPeerCertificates(deferredCerts); > > The above two method are always called together. Is it a little bit > friendly to merge them together? > private void checkServerCerts(X509Certificate[] certs) ... { > ... > session.setPeerCertificates(certs); > } Done. > > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java > ====================================================================== > You may want to remove the block of addResponses() implementation. Gone! > > src/java.base/share/classes/sun/security/validator/PKIXValidator.java > ===================================================================== > minor comment: > > Is it more instinctive if changing the parameter name from responseList > to ocspResponses, and the method name from addResponses() to > addOcspResponses()? > > Same for SimpleValidator.java and Validator.java. I've tried to not use "ocsp" in the names, only because OCSP is just one type of stapled response for certificate revocation status. Granted, it is the only one used today. I didn't want to use a term that denoted that the only kind of data coming through CertificateStatus is OCSP data, since in the future it may be something different. I know there are places where I didn't adhere to my own rule, but I really tried to where I could. > > ---------------- > line 393-404. > > For performance friendly, it is nice to construct the map if and only if > the map get used. > > if (pkixParams.isRevocationEnabled()) { > // make the map > > try { > ... // use the map > } > } > > ----------- > 430 revChecker.setOcspResponses(responseMap); > User specified OCSP responses are overridden, which should be respected. > The behavior is not what the user expected. Good catch. I'll rework the Map instantiation and fix this. > > src/java.base/share/classes/sun/security/validator/Validator.java > ===================================================================== > 207 public final String getType() { > > Looks like this method does not get used. Is it redundant? It's gone now. I was using it when I did the ThreadLocal solution and forgot to rip it out when we moved the logic into PKIXValidator. > > > Xuelei > > On 6/27/2015 11:06 PM, Jamil Nimeh wrote: >> Hello all, I've posted an updated webrev based on comments I've received >> so far: >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 >> >> Thanks, >> --Jamil >> >> On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I have a first cut at the OCSP stapling webrev posted for your review: >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >>> >>> A couple items to note: >>> >>> * I'm in the process of updating the JEP with some more details. I >>> should be done with these changes by tonight (PDT). >>> * Missing are some of the TLS end-to-end tests. These tests have >>> been coded and run outside the jtreg framework, but for some >>> reason things hang in jtreg. I've included some of the supporting >>> classes that these tests will use (CertificateBuilder.java and >>> SimpleOCSPResponder.java) so folks could review those if they're >>> interested. I will update the webrev and notify the list as soon >>> as I've got the tests working in jtreg. >>> >>> Thanks to everyone who has helped along the way. >>> >>> --Jamil >>> >>>