RFR: 8304264: Debug messages always show up for NativeGSS
Only call `debug()` when `DEBUG` is set. - Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/13043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304264 Stats: 61 lines in 5 files changed: 29 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/13043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13043/head:pull/13043 PR: https://git.openjdk.org/jdk/pull/13043
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
Re: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote: > This change will move the instantiation of BadPaddingException into the > branch of the if statement where it is thrown. This will decrease the > overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated > work item for past discussions regarding this change. > > The build and tier1 tests pass locally on mac-aarch64. Well `throw` will always be slower than `return`, even if the stack trace is populated on both paths. How do we know if we are not vulnerable to Bleichenbacher's attack today? (granted, creating the exception on `throw` path only will increase the timing difference) - PR: https://git.openjdk.org/jdk/pull/12732
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in the
>> .properties files as UTF-8 during the conversion from .properties file to
>> .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
>
>> 250: try {
>> 251: writer = new BufferedWriter(
>> 252: new OutputStreamWriter(new
>> FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
>
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then
> override the default javac option for ascii when compiling _just_ these files.
>
> Or else just stay with ascii; no one should be looking at these files!
Will stick with your latter solution, as since the .properties files were
converted via native2ascii, it makes sense to write out via ascii.
-
PR: https://git.openjdk.org/jdk/pull/12726
RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. - Commit messages: - Write to ASCII - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1 - Compile class with ascii (Not ready to make system wide change) - Toggle UTF-8 for javac option in JavaCompilation.gmk - CompileProperties converts in UTF-8 - Convert .properties from ISO-8859-1 to UTF-8 Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote:
> This PR converts Unicode sequences to UTF-8 native in .properties file.
> (Excluding the Unicode space and tab sequence). The conversion was done using
> native2ascii.
>
> In addition, the build logic is adjusted to support reading in the
> .properties files as UTF-8 during the conversion from .properties file to
> .java ListResourceBundle file.
make/langtools/tools/compileproperties/CompileProperties.java line 252:
> 250: try {
> 251: writer = new BufferedWriter(
> 252: new OutputStreamWriter(new
> FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
Using ISO_8859_1 seems strange.
Since these are generated files, you could write them as UTF-8 and then
override the default javac option for ascii when compiling _just_ these files.
Or else just stay with ascii; no one should be looking at these files!
-
PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1: > 1: # This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files. - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8304264: Debug messages always show up for NativeGSS
On Wed, 15 Mar 2023 13:44:09 GMT, Weijun Wang wrote: > Only call `debug()` when `DEBUG` is set. Is this debug property documented anywhere? If not, perhaps we should add it to the Troubleshooting guide. - Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.org/jdk/pull/13043
Re: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v2]
> Can I please get reviews for this PR to add support for the rematerialization > of scalar-replaced objects that participate in allocation merges? > > The most common and frequent use of NonEscaping Phis merging object > allocations is for debugging information. The two graphs below show numbers > for Renaissance and DaCapo benchmarks - similar results are obtained for all > other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge > user? I.e., if the same node type uses a Phi N times the counter is > incremented by N: > >  > > What are the most common users of allocation merges? I.e., if the same node > type uses a Phi N times the counter is incremented by 1: > >  > > This PR adds support scalar replacing allocations participating in merges > that are used *only* as debug information in SafePointNode and its > subclasses. Although there is a performance benefit in doing scalar > replacement in this scenario only, the goal of this PR is mainly to add > infrastructure to support the rematerialization of SR objects participating > in merges. I plan to create subsequent PRs to enable scalar replacement of > merges used by other node types (CmpP, Load+AddP, primarily) subsequently. > > The approach I used is pretty straightforward. It consists basically in: 1) > Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a > new Class to support rematerialization of SR objects part of merges; 3) Patch > HotSpot to be able to serialize and deserialize debug information related to > allocation merges; 4) Patch C2 to generate unique types for SR objects > participating in allocation merges used only as debug information. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't > see regression that might be related. I also tested with several applications > and didn't see any failure. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge master - Add support for rematerializing scalar replaced objects participating in allocation merges - Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01 Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897
Re: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote: > This change will move the instantiation of BadPaddingException into the > branch of the if statement where it is thrown. This will decrease the > overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated > work item for past discussions regarding this change. > > The build and tier1 tests pass locally on mac-aarch64. suspend for now per Xuelei's request. - PR: https://git.openjdk.org/jdk/pull/12732
Integrated: 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan wrote: > * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in > one base class (SSLContextTemplate) > * Updated TLS/SSL tests to extend SSLSocketTemplate where possible. > * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To > keep this changeset to a reasonable size, updates to SSLEngine tests will be > made under JDK-8301194. This pull request has now been integrated. Changeset: 824a5e4c Author:Matthew Donovan Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/824a5e4c605d4aee55252bce5364fa01de525e1b Stats: lines in 23 files changed: 984 ins; 3158 del; 302 mod 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates Reviewed-by: rhalade - PR: https://git.openjdk.org/jdk/pull/12555
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
Re: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote: > This change will move the instantiation of BadPaddingException into the > branch of the if statement where it is thrown. This will decrease the > overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated > work item for past discussions regarding this change. > > The build and tier1 tests pass locally on mac-aarch64. I suggested using constructor with disabled stack trace as a backup option, but this will require refactoring few exception classes related to security package (i.e. currently GeneralSecurityException does not have protected constructor with enableSuppression/writableStackTrace flags) and reviewing all usages of them. - PR: https://git.openjdk.org/jdk/pull/12732
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Wed, 15 Mar 2023 14:51:49 GMT, Weijun Wang wrote: >> We would like to propose an implementation for the [JDK-8301553: Support >> Password-Based Cryptography in >> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement >> requirement. >> >> In addition to pursuing the requirement goals and guidelines of >> [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share >> the following implementation notes (grouped per altered file): >> >> * >> ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` >> (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 >> General Method for Password >> Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) >> algorithms. It has been modified with the intent of consolidating all >> parameter checks in a common file >> (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can >> be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only >> serve the purpose of avoiding duplicated code but also ensuring alignment >> and compatibility between different implementations of the same algorithms. >> No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters >> checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance >> (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a >> ```PBEKeySpec``` instance which consolidates all the data later required to >> proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` >> (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 >> Password-Based Encryption >> Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) >> algorithms, which use PBKD2 algorithms underneath for key derivation. In the >> same spirit than for the ```HmacPKCS12PBECore``` case, we decided to >> consolidate common code for parameters validation and default values in a >> single file >> (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can >> serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. >> However, instead of a single static method at the implementation level (see >> ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class >> and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). >> The reason is to persist parameters data that has to be consistent between >> calls to ```PBES2Core::engineInit``` (in its multiple overloads) and >> ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` >> instance. I n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. >> >> * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new >> file) >> * This utility file contains the PBE parameters checking routines and >> default values that are used by both ```SunJCE``` and ```SunPKCS11```. These >> routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), >> ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and >> ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid >> duplicate code and to improve compatibility between different security >> providers that implement PBE algorithms. >> >> * >> ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` >> (modified) >> * An utility function to determine if the token is NSS is now called. >> This function is in a common utility class (```P11Util```) and invoked from >> ```P11Key``` and ```P11SecretKeyFactory``` too. >> >> * >> ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` >> (modified) >> * A new type of P11 key is introduced: ```P11PBEKey```. This new type >> represents a secret key that exists inside the token. Thus, this type >> inherits from ```P11SecretKey```. At the same time, this type holds data >> used for key derivation. Thus, this type implements the >> ```javax.crypto.interfaces.PBEKey``` interface. In addition to the >> conceptual modeling, there are practical advantages of identifying a key by >> this new ```P11PBEKey``` type and holding the data used for derivation: 1) >> if the key is used in another token (different than the one where it was >> originally derived), a new derivation must take place; 2) if the key is >> passed to a non-```SunPKCS11``` security provider, its key translation >> method might use derivation data to derive again; and, 3) i
Re: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v3]
> Can I please get reviews for this PR to add support for the rematerialization > of scalar-replaced objects that participate in allocation merges? > > The most common and frequent use of NonEscaping Phis merging object > allocations is for debugging information. The two graphs below show numbers > for Renaissance and DaCapo benchmarks - similar results are obtained for all > other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge > user? I.e., if the same node type uses a Phi N times the counter is > incremented by N: > >  > > What are the most common users of allocation merges? I.e., if the same node > type uses a Phi N times the counter is incremented by 1: > >  > > This PR adds support scalar replacing allocations participating in merges > that are used *only* as debug information in SafePointNode and its > subclasses. Although there is a performance benefit in doing scalar > replacement in this scenario only, the goal of this PR is mainly to add > infrastructure to support the rematerialization of SR objects participating > in merges. I plan to create subsequent PRs to enable scalar replacement of > merges used by other node types (CmpP, Load+AddP, primarily) subsequently. > > The approach I used is pretty straightforward. It consists basically in: 1) > Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a > new Class to support rematerialization of SR objects part of merges; 3) Patch > HotSpot to be able to serialize and deserialize debug information related to > allocation merges; 4) Patch C2 to generate unique types for SR objects > participating in allocation merges used only as debug information. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't > see regression that might be related. I also tested with several applications > and didn't see any failure. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Fix some typos and do some small refactorings. - Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/ea67a304..3b492d2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01-02 Stats: 72 lines in 8 files changed: 1 ins; 7 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897
Re: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote: > This change will move the instantiation of BadPaddingException into the > branch of the if statement where it is thrown. This will decrease the > overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated > work item for past discussions regarding this change. > > The build and tier1 tests pass locally on mac-aarch64. I may be wrong here but my take on this is that there is nothing at the language level that prevents the compiler from optimizing the code and moving the allocation inside the "If". In fact, GRAAL might as well be doing this as part of Partial Escape Analysis. - PR: https://git.openjdk.org/jdk/pull/12732
Re: RFR: 8302017: Allocate BadPaddingException only if it will be thrown
On Wed, 15 Mar 2023 18:08:20 GMT, Cesar Soares Lucas wrote: > I may be wrong here but my take on this is that there is nothing at the > language level that prevents the compiler from optimizing the code and moving > the allocation inside the "If". In fact, GRAAL might as well be doing this as > part of Partial Escape Analysis. Escape analysis does not work for conditionals. Microsoft JVM team is currently working on this feature, but it is still experimental. - PR: https://git.openjdk.org/jdk/pull/12732
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156: > 154: zh=\u00A4 > 155: zh_CN=\uFFE5 > 156: zh_HK=HK$ Why are they not encoded into UTF-8 native? - PR: https://git.openjdk.org/jdk/pull/12726
Re: RFR: 8304264: Debug messages always show up for NativeGSS
On Wed, 15 Mar 2023 16:56:40 GMT, Sean Mullan wrote: > Is this debug property documented anywhere? If not, perhaps we should add it > to the Troubleshooting guide. We can add it to the "Accessing Native GSS-API" page. There is an existing "Troubleshooting" but it's inside the part about using JGSS with JAAS. Native GSS should not be used with JAAS. - PR: https://git.openjdk.org/jdk/pull/13043
Integrated: 8304264: Debug messages always show up for NativeGSS
On Wed, 15 Mar 2023 13:44:09 GMT, Weijun Wang wrote: > Only call `debug()` when `DEBUG` is set. This pull request has now been integrated. Changeset: be08a256 Author:Weijun Wang URL: https://git.openjdk.org/jdk/commit/be08a256ab8abab63ec9070342fb5ee46f00219b Stats: 61 lines in 5 files changed: 29 ins; 0 del; 32 mod 8304264: Debug messages always show up for NativeGSS Reviewed-by: mullan - PR: https://git.openjdk.org/jdk/pull/13043
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
Re: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support > Password-Based Cryptography in > SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement > requirement. > > In addition to pursuing the requirement goals and guidelines of > [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share > the following implementation notes (grouped per altered file): > > * > ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 > General Method for Password > Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) > algorithms. It has been modified with the intent of consolidating all > parameter checks in a common file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only > serve the purpose of avoiding duplicated code but also ensuring alignment and > compatibility between different implementations of the same algorithms. No > changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters > checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance > (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a > ```PBEKeySpec``` instance which consolidates all the data later required to > proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` > (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 > Password-Based Encryption > Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) > algorithms, which use PBKD2 algorithms underneath for key derivation. In the > same spirit than for the ```HmacPKCS12PBECore``` case, we decided to > consolidate common code for parameters validation and default values in a > single file > (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can > serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. > However, instead of a single static method at the implementation level (see > ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class > and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The > reason is to persist parameters data that has to be consistent between calls > to ```PBES2Core::engineInit``` (in its multiple overloads) and > ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` > instance. In particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior. > > * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new > file) > * This utility file contains the PBE parameters checking routines and > default values that are used by both ```SunJCE``` and ```SunPKCS11```. These > routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), > ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and > ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid > duplicate code and to improve compatibility between different security > providers that implement PBE algorithms. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` > (modified) > * An utility function to determine if the token is NSS is now called. > This function is in a common utility class (```P11Util```) and invoked from > ```P11Key``` and ```P11SecretKeyFactory``` too. > > * > ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` > (modified) > * A new type of P11 key is introduced: ```P11PBEKey```. This new type > represents a secret key that exists inside the token. Thus, this type > inherits from ```P11SecretKey```. At the same time, this type holds data used > for key derivation. Thus, this type implements the > ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual > modeling, there are practical advantages of identifying a key by this new > ```P11PBEKey``` type and holding the data used for derivation: 1) if the key > is used in another token (different than the one where it was originally > derived), a new derivation must take place; 2) if the key is passed to a > non-```SunPKCS11``` security provider, its key translation method might use > derivation data to derive again; and, 3) it's possible to return the > ```PBEKeySpec``` for the key (see for example >
