RFR 6722928: Support SSPI as a native GSS-API provider

2018-11-19 Thread Weijun Wang
Please take a review at

   https://cr.openjdk.java.net/~weijun/6722928/webrev.01/

We ported [1] the native GSS bridge to Windows in JDK 11, but user still have 
to download and install a native GSS-API library. This code change provides a 
native GSS-API library inside JDK that can be used without setting the 
"sun.security.jgss.lib" system property. It is based on Windows SSPI and now 
only supports the client side using the default credentials.

No regression tests included. A Windows Active Directory server is needed.

Thanks
Max

[1] https://bugs.openjdk.java.net/browse/JDK-8200468

Re: RFR 8213202: Possible race condition in TLS 1.3 session resumption

2018-11-19 Thread Jamil Nimeh

Hi Adam,

I think this looks good.

On 11/9/2018 11:09 AM, Adam Petcher wrote:

JBS: https://bugs.openjdk.java.net/browse/JDK-8213202
webrev: http://cr.openjdk.java.net/~apetcher/8213202/webrev.00/

This change fixes a bug that allows multiple clients thread to offer 
the same PSK to the server, even though only one thread may actually 
use the PSK to resume the session. The other threads will fail to 
connect and throw an exception. This is noreg-hard because the bug 
doesn't happen with the JDK TLS server, and we don't have a regression 
test harness that allows us to simulate some particular server 
behavior. I tested the fix by connecting multiple JDK clients to an 
openssl server.






Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

2018-11-19 Thread Bernd Eckenfels
Hello,

What is the purpose of setting some of them to 0 twice? (It’s a new array which 
should be all-0 anyway.)

+  for (int i = 1; i < 9 ; i++) {
+subkeyHtbl[2*i] = 0;
+subkeyHtbl[2*i+1] = 0;
+}

Also, is the subkeyH no longer be needed (or can be redesigned to use 
subkeyHtbl[0] and 1?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Kamath, Smita 
Gesendet: Montag, November 19, 2018 10:52 PM
An: 'Vladimir Kozlov'
Cc: Anthony Scarpino; core-libs-...@openjdk.java.net; hotspot compiler
Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hi Vladimir,

I'd like to contribute an optimization for GHASH Algorithm using AVX 
Instructions. I have tested this optimization on SKX x86_64 platform and it 
shows ~20-30% performance improvement for larger message sizes (for example 8k).

I, smita.kam...@intel.com , Shay Gueuron, 
(shay.gue...@intel.com) and Regev Shemy 
(regev.sh...@intel.com) are contributors to this 
code.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074

Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/

For testing the implementation, I have executed TestAESMain.java. I have 
executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.

Please review and let me know if you have any comments.

Thanks and Regards,
Smita



Re: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480

2018-11-19 Thread Sean Mullan

On 11/16/18 3:19 PM, Xuelei Fan wrote:

Thanks for the review, Jmail & Sean.

New webrev:
     http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/

I will update CSR when we come to an agreement.

On 11/16/2018 11:33 AM, Sean Mullan wrote:
  122  * @apiNote Both the session timeout and cache size impact 
performance
  123  *  of future connections.  It is not recommended to 
use too big
  124  *  or too small timeout or cache size limit. 
Applications should
  125  *  carefully weigh the limits and performance for 
the specific

  126  *  circumstances.

I am not really sure if the @apiNote is that useful or appropriate,

I worry about the default value actually.


Then maybe the default is what you should be discussing in this apiNote. 
Right now I don't think the apiNote adds much. To me, all you are really 
saying is that these are methods that can be used to tune performance, 
which I think should be obvious from their name and description. Maybe 
the apiNote should say something like:


"Note that the JDK Implementation uses default values for both the 
session cache size and timeout. See getSessionCacheSize and 
getSessionTimeout for more information. Applications should consider 
their performance requirements and override the defaults if necessary."


Also I think you should add a similar @implNote for getSessionTimeout 
which describes the default value (86400 seconds or 24 hours), ex:


@implNote The JDK implementation returns the session timeout as set by 
   the {@code setSessionTimeout} method, or if not set, a default 
value of 86400 seconds (24 hours).


  A new bug may be filed again 
and argue if the default value is not a proper one.  The default value 
of session timeout and cache size really depends on the real world 
circumstances.  I think we'd better make a clarification in the spec, 
and remind application tune them accordingly.


Ok, but the apiNote above says nothing about the default value.

--Sean



but it seems a bit odd to talk about the session timeout in this method. 
The performance impact is a combination of the session timeout limit and 
cache size.  I would like application consider them together if need to 
tune the values, but not individually.


If you still want to add this, I would add an @apiNote to each of the 
setSessionCacheSize and setSessionTimeout methods and just discuss 
each property separately.



I added the update spec to both setSessionCacheSize and setSessionTimeout.

Also, unless you say what "too big" or "too small" is, I would avoid 
giving this advice.



It makes sense to me.

Thanks,
Xuelei


--Sean


On 11/16/18 1:30 PM, Xuelei Fan wrote:

It's time to use the systemProperty tag as it is ready.

As we are already there, I also update the setSessionCacheSize() for 
more clarification.


Please review both CSR and webrev:
 https://bugs.openjdk.java.net/browse/JDK-8213577
 http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/

Thanks,
Xuelei

On 11/16/2018 8:19 AM, Sean Mullan wrote:

On 11/15/18 3:37 PM, Xuelei Fan wrote:

Hi Sean,

Are you OK if we do it later?  I'm waiting for the @systemProperty 
tag, proposed within JDK-5076751.  I will file a bug to use the tag 
for more cleanup.


JDK-5076751 is completed and pushed to JDK 12, so you can use the 
new tag now.


I think it would be easier to do it now, it seems pretty simple and 
that way there is no need to worry about it later.


--Sean



Thanks,
Xuelei

On 11/15/2018 11:55 AM, Sean Mullan wrote:
This is a good opportunity to document the 
javax.net.ssl.sessionCacheSize system property in the 
SSLSessionContext API (and use the new @systemProperty tag) in an 
@implNote, for example:


 /**
  * Returns the size of the cache used for storing
  * SSLSession objects grouped under this
  * SSLSessionContext.
  *
  * @implNote The JDK implementation returns the cache size as 
set by
  * the {@code setSessionCacheSize method}, or if not set, the 
value
  * of the {@systemProperty javax.net.ssl.sessionCacheSize} 
system
  * property. If neither is set, it returns a default value of 
20480.

  *
  * @return size of the session cache; zero means there is no 
size limit.

  * @see #setSessionCacheSize
  */
 public int getSessionCacheSize();

On 11/14/18 11:59 AM, Xuelei Fan wrote:

Hi,

Please review this simple update:
 http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/

The default value for the maximum number of entries in the SSL 
session cache (SSLSessionContext.getSessionCacheSize()) is 
infinite now.  In the request, the default value is updated to 
20480 for performance consideration.


For the detailed behavior update, please refer to CSR:
 https://bugs.openjdk.java.net/browse/JDK-8213577

Thanks,
Xuelei