Re: JEP Review Request: Improve Security Manager Performance
On 04/25/2014 09:36 AM, Sean Mullan wrote: Please review a draft of a proposed research JEP to improve the performance of the Security Manager: I have another idea that might be worth looking into. One problem with security manager performance is that many times a class will perform privileged actions in the static initializer block. This is because static class initialization runs with whatever security context is active when that class happens to be initialized - it's essentially random as far as most developers are concerned, and even the experts cannot always correctly predict how initialization happens (see: last several years of java.util.logging class init debacle). This causes performance (and usability) problems because: • Static init blocks can, for most practical purposes, never rely on their caller, so they must always perform privileged actions within doPrivileged • This also results in another class to load and initialize • Often, there is more than one data item needed from the privileged block, requiring either multiple doPrivileged calls (slow) or using hackery like returning an Object[] array out of the block I would suggest that one or more of the following be done to mitigate this problem: • Always have static initialization blocks be privileged (this does require users to be cognizant of this fact when writing static blocks) • Allow static initialization blocks to partake in the aforementioned annotation-driven privileged method idea • Introduce a new permission checking mechanism which examines only a specific relevant caller's protection domain (perhaps determined by filter expression, possibly using the stack examination scheme that Mandy Chung has been working on) • Introduce a programmatic "elevation" mechanism that increases the privileges of the currently executing method for the remainder of its execution without requiring a call-in to doPrivileged or instantiation of a privileged action object -- - DML
RFR 6997010: Consolidate java.security files into one file with modifications
Please review the code change at http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ The fix consolidates java.security- files into one with #ifdef directives. There are several major changes: 1. Creation of file is moved from CopyFiles to GenerateData, since we are really generating something now. Said that, the source data is kept in src/share/lib/security instead of make/data. I am OK with moving it if anyone desires. 2. The new tool MakeJavaSecurity includes the function of old AddToRestrictedPkgs. MakeJavaSecurity includes a new argument to deal with the platform dependent entries. The restricted.pkgs argument is also changed from a list of entries to a file name, so that we can also support the same #ifdef mechanism inside restricted.pkgs. 3. The new consolidated java.security supports #ifdef and #ifndef. It is not necessary to support #else or (and|or) of multiple #ifdef's now. 4. *IMPORTANT*: In order to easily maintain platform-related entries, every line (including the last line) in package.access and package.definition MUST end with ',\' now. A blank line MUST exist after the last line. This avoid ugly lines like #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2 #endif The MakeJavaSecurity tool will strip the trailing ",\" from the last line to make the file exactly the same as before, although personally I don't think it's really necessary since the following empty line will terminate the entry automatically. Thanks Max
Re: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission
Well, I see your point. However, I am a little concerned that the security check isn't being performed in the old buggy impl. Is there any customer running into this, e.g. rely on the old behavior with security manager enabled? Valerie On 7/22/2014 2:45 PM, Seán Coffey wrote: A recent fix was introduced to preserve the behaviour of an old buggy implementation of smartcardio Card.disconnect : https://bugs.openjdk.java.net/browse/JDK-8049250 The old behaviour is not fully restored with this flag if a security manager lacking sufficient permissions is present. This could disrupt legacy applications which may wish to rely on the old behaviour. Some internal testing has also highlighted this. To enhance the 8049250 fix, I'm proposing we delay the boolean flip operation until post the security check. http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ Bug report is not public due to internal links and servers being present in description. I'd like to get this into JDK 9 and 8u20. regards, Sean.
RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission
A recent fix was introduced to preserve the behaviour of an old buggy implementation of smartcardio Card.disconnect : https://bugs.openjdk.java.net/browse/JDK-8049250 The old behaviour is not fully restored with this flag if a security manager lacking sufficient permissions is present. This could disrupt legacy applications which may wish to rely on the old behaviour. Some internal testing has also highlighted this. To enhance the 8049250 fix, I'm proposing we delay the boolean flip operation until post the security check. http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/ Bug report is not public due to internal links and servers being present in description. I'd like to get this into JDK 9 and 8u20. regards, Sean.
Re: RFR: 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux
Looks fine to me. --Sean On 07/22/2014 01:44 PM, Rob McKenna wrote: Hi folks, When repeatedly gathering small amounts of random data the SUN provider is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto / pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to avoid the overhead of calling into the native level repeatedly for small amounts of random data and allows ucrypto / pkcs11 to perform as well as SUN for this particular corner case. Testcase attached to the bug. http://cr.openjdk.java.net/~robm/8044659/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8044659 -Rob
RFR: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode
This is a fix for a test that was on the problem list. The fix is simple, I just changed the test to run in othervm mode, it was failing due to a classloader issue running in agentvm mode. Was able to get a clean jprt run on all systems. http://cr.openjdk.java.net/~mullan/webrevs/7147060/webrev.00/ Thanks, Sean
RFR: 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux
Hi folks, When repeatedly gathering small amounts of random data the SUN provider is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto / pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to avoid the overhead of calling into the native level repeatedly for small amounts of random data and allows ucrypto / pkcs11 to perform as well as SUN for this particular corner case. Testcase attached to the bug. http://cr.openjdk.java.net/~robm/8044659/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8044659 -Rob
Re: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider
Looks good. --Sean On 07/21/2014 06:33 PM, Valerie Peng wrote: Done, webrev updated at http://cr.openjdk.java.net/~valeriep/8035166/webrev.01/ Thanks, Valerie On 7/21/2014 11:18 AM, Sean Mullan wrote: Can you also change the following comment in sun/security/ssl/SupportedEllipticCurvesExtension.java: // See sun.security.ec.NamedCurve for the OIDs to // See sun.security.util.NamedCurve for the OIDs Rest looks good to me. Please add a noreg label though. --Sean On 07/18/2014 01:13 PM, Valerie Peng wrote: Vinnie, Could you please help reviewing this change? My current approach is to minimize code changes/refactoring - move the ECParameters, NamedCurve, CurveDB classes to sun.security.util package and then change the depending classes to use sun.security.util.XXX rather than sun.security.ec.XXX. Besides moving the 3 classes, I also changed some methods to public to be accessible from sun.security.ec package. webrev: http://cr.openjdk.java.net/~valeriep/8035166/webrev.00/ Thanks, Valerie
RFR: 8042982: Unexpected RuntimeExceptions being thrown by SSLEngine
Hi folks, A simple change to use SSLHandshakeException instead of RuntimeException in getAgreedSecret in DHCrypt and ECDHCrypt. This will prevent these RuntimeExceptions from propagating to the application and allow application programmers to handle them as SSLHandshakeExceptions. http://cr.openjdk.java.net/~robm/8042982/webrev.01/ -Rob
Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
On 07/22/2014 09:52 AM, Jason Uh wrote: Hi Max, Could you please review this fix? http://cr.openjdk.java.net/~juh/8007706/webrev.00/ With the fix, the rules will be: 1. A DNSName must begin with a letter or a digit 2. After the first character, valid characters in DNSName components are letters, digits, hyphens, and underscores The underscore bit violates the requirements of RFC 5280. Perhaps the RFC is wrong, but I think more justification is needed. The part which accepts leading digits is fine. Technically, there is a difference between domain names (sequences of dotted case-insensitive label blobs) and host names (labels must consist of letters and digits and hyphens, and start with a letter or digit). RFC 5280 says "domain name", but the references make it clear that "host names" are meant instead. It's not even clear if IA5String can encode backslashes, which would be needed to cover the entire range of valid domain names. -- Florian Weimer / Red Hat Product Security
[9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
Hi Max, Could you please review this fix? http://cr.openjdk.java.net/~juh/8007706/webrev.00/ With the fix, the rules will be: 1. A DNSName must begin with a letter or a digit 2. After the first character, valid characters in DNSName components are letters, digits, hyphens, and underscores A couple minor formatting changes included. Thanks, Jason
