Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v17]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Integrated: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 12:27:52 GMT, Alexey Bakhtin wrote: > Hi All, > > DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12 > keystores. > This issue prevents the migration of legacy applications to PKCS#12 keystore. > For example, an application has some old 3DES keys that are required for > certain legacy features. Java PKCS12 keystore does not support DES/3DES keys, > thus, application can’t migrate to PKCS#12 > This patch adds OIDs for the DES/DESede algorithms. It is the only changes > required to support DES/3DES keys in the PKCS#12 keystore. > sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys in > the PKCS#12 keystore. This pull request has now been integrated. Changeset: 7a7ce021 Author:Alexey Bakhtin Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/7a7ce021 Stats: 16 lines in 2 files changed: 5 ins; 1 del; 10 mod 8007632: DES/3DES keys support in PKCS12 keystore Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore [v3]
On Tue, 27 Oct 2020 17:59:38 GMT, Weijun Wang wrote: >> Alexey Bakhtin has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix order of OIDs > > Marked as reviewed by weijun (Reviewer). Change looks good. - PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore [v3]
On Tue, 27 Oct 2020 17:58:35 GMT, Alexey Bakhtin wrote: >> Hi All, >> >> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12 >> keystores. >> This issue prevents the migration of legacy applications to PKCS#12 >> keystore. For example, an application has some old 3DES keys that are >> required for certain legacy features. Java PKCS12 keystore does not support >> DES/3DES keys, thus, application can’t migrate to PKCS#12 >> This patch adds OIDs for the DES/DESede algorithms. It is the only changes >> required to support DES/3DES keys in the PKCS#12 keystore. >> sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys >> in the PKCS#12 keystore. > > Alexey Bakhtin has updated the pull request incrementally with one additional > commit since the last revision: > > Fix order of OIDs Marked as reviewed by weijun (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore [v3]
> Hi All, > > DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12 > keystores. > This issue prevents the migration of legacy applications to PKCS#12 keystore. > For example, an application has some old 3DES keys that are required for > certain legacy features. Java PKCS12 keystore does not support DES/3DES keys, > thus, application can’t migrate to PKCS#12 > This patch adds OIDs for the DES/DESede algorithms. It is the only changes > required to support DES/3DES keys in the PKCS#12 keystore. > sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys in > the PKCS#12 keystore. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Fix order of OIDs - Changes: - all: https://git.openjdk.java.net/jdk/pull/877/files - new: https://git.openjdk.java.net/jdk/pull/877/files/94423b3d..efbd5a4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=877=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=877=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/877/head:pull/877 PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore [v2]
> Hi All, > > DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12 > keystores. > This issue prevents the migration of legacy applications to PKCS#12 keystore. > For example, an application has some old 3DES keys that are required for > certain legacy features. Java PKCS12 keystore does not support DES/3DES keys, > thus, application can’t migrate to PKCS#12 > This patch adds OIDs for the DES/DESede algorithms. It is the only changes > required to support DES/3DES keys in the PKCS#12 keystore. > sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys in > the PKCS#12 keystore. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: DES oid is 1.3.14.3.2.7 - Changes: - all: https://git.openjdk.java.net/jdk/pull/877/files - new: https://git.openjdk.java.net/jdk/pull/877/files/09354ca6..94423b3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=877=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=877=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/877/head:pull/877 PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore [v2]
On Tue, 27 Oct 2020 17:46:35 GMT, Alexey Bakhtin wrote:
>> Hi All,
>>
>> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
>> keystores.
>> This issue prevents the migration of legacy applications to PKCS#12
>> keystore. For example, an application has some old 3DES keys that are
>> required for certain legacy features. Java PKCS12 keystore does not support
>> DES/3DES keys, thus, application can’t migrate to PKCS#12
>> This patch adds OIDs for the DES/DESede algorithms. It is the only changes
>> required to support DES/3DES keys in the PKCS#12 keystore.
>> sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys
>> in the PKCS#12 keystore.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> DES oid is 1.3.14.3.2.7
src/java.base/share/classes/sun/security/util/KnownOIDs.java line 356:
> 354: OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC", "DES"),
> 355:
> 356: DESede("1.3.14.3.2.17", "DESede"),
Please move this below before SHA-1. The items are ordered by the OIDs (within
each section group).
-
PR: https://git.openjdk.java.net/jdk/pull/877
ECC Key Usage ignored
Hi all, TL;DR: both SSL server and client ignore KeyUsage certificate extension when determining the list of available cipher suites. They shouldn't; KeyUsage is the only differentiator between ECDH and ECDSA certificates. Long version: I'm experimenting with ECC certificates on my Jetty server; when I created an ECC certificate and tested the server with nmap, I found that both ECDSA and ECDH cipher suites are enabled. I don't want ECDH ciphers, but I don't want to add explicit excludes either. Reading into NIST recommendations [1] I found that ECDSA certificates should define KeyUsage extension with value digitalSignature, vs ECDH which should use keyAgreement value. I experimented with both combinations of KeyValue, both resulted in the same set of ciphers being offered by the server. The client doesn't seem to care about KeyUsage either - it accepts connections even when the selected cipher doesn't match KeyUsage. Chrome browser doesn't support ECDH ciphers, but it does support ECDSA. When connecting to a Java server using ECDH certificate, it displays the error "ERR_SSL_KEY_USAGE_INCOMPATIBLE"; the server offers an ECDSA cipher suite, which is rejected by the browser. The issue was already reported by Bernd Eckenfels here [2], but as far as I can tell, it is not addressed yet; I was able to reproduce it using slightly modified code of this gist [3]. Certificates were generated using keytool commands: ECDSA: keytool -genkeypair -alias ec -keyalg EC -keysize 256 -sigalg SHA256withECDSA -validity 365 -dname "CN=localhost,OU=Unknown,O=Unknown,L=Unknown,S=Unknown,C=Unknown" -storetype JKS -keystore ectest.jks -storepass 123456 -ext KeyUsage:c=digitalSignature,keyCertSign ECDH: keytool -genkeypair -alias ec -keyalg EC -keysize 256 -sigalg SHA256withECDSA -validity 365 -dname "CN=localhost,OU=Unknown,O=Unknown,L=Unknown,S=Unknown,C=Unknown" -storetype JKS -keystore ectest.jks -storepass 123456 -ext KeyUsage:c=keyAgreement,keyCertSign I'm not sure if keyCertSign is required on self-signed certificates, added it just in case. Tested on OpenJDK 11.0.6. Regards, Daniel Jeliński [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-May/015902.html [3] https://gist.github.com/djelinski/b4543a3eb7ea66306044c08b41bba00f
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 16:52:03 GMT, Alexey Bakhtin wrote:
>> Yes I can see the OIDs. I was just wondering if other vendors are also using
>> the OID for DES/ECB when storing a DES key. After all, this is only a key
>> and it can can be used with all Cipher modes.
>
> Verified with BC: BouncyCastle uses DES/CBC OID for DES secret key in PKCS#12.
> So, the patch for "DES" can be simplified to
>- OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
>+ OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC", "DES"),
Good. I also just noticed that the BC provider uses 1.3.14.3.2.7 as alias for
KeyGenerator.DES.
-
PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 16:12:14 GMT, Weijun Wang wrote:
>> At least BouncyCastle uses the same OIDs:
>> http://javadox.com/org.bouncycastle/bcprov-jdk15on/1.51/org/bouncycastle/asn1/oiw/OIWObjectIdentifiers.html
>
> Yes I can see the OIDs. I was just wondering if other vendors are also using
> the OID for DES/ECB when storing a DES key. After all, this is only a key and
> it can can be used with all Cipher modes.
Verified with BC: BouncyCastle uses DES/CBC OID for DES secret key in PKCS#12.
So, the patch for "DES" can be simplified to
- OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
+ OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC", "DES"),
-
PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 14:44:09 GMT, Alexey Bakhtin wrote:
>> src/java.base/share/classes/sun/security/util/KnownOIDs.java line 355:
>>
>>> 353: // OIW secsig 1.3.14.3.*
>>> 354: OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
>>> 355: OIW_DES_ECB("1.3.14.3.2.6", "DES/ECB", "DES"),
>>
>> What OID are other vendors using?
>
> At least BouncyCastle uses the same OIDs:
> http://javadox.com/org.bouncycastle/bcprov-jdk15on/1.51/org/bouncycastle/asn1/oiw/OIWObjectIdentifiers.html
Yes I can see the OIDs. I was just wondering if other vendors are also using
the OID for DES/ECB when storing a DES key. After all, this is only a key and
it can can be used with all Cipher modes.
-
PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v16]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 14:19:00 GMT, Weijun Wang wrote:
>> Hi All,
>>
>> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
>> keystores.
>> This issue prevents the migration of legacy applications to PKCS#12
>> keystore. For example, an application has some old 3DES keys that are
>> required for certain legacy features. Java PKCS12 keystore does not support
>> DES/3DES keys, thus, application can’t migrate to PKCS#12
>> This patch adds OIDs for the DES/DESede algorithms. It is the only changes
>> required to support DES/3DES keys in the PKCS#12 keystore.
>> sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys
>> in the PKCS#12 keystore.
>
> src/java.base/share/classes/sun/security/util/KnownOIDs.java line 355:
>
>> 353: // OIW secsig 1.3.14.3.*
>> 354: OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
>> 355: OIW_DES_ECB("1.3.14.3.2.6", "DES/ECB", "DES"),
>
> What OID are other vendors using?
At least BouncyCastle uses the same OIDs:
http://javadox.com/org.bouncycastle/bcprov-jdk15on/1.51/org/bouncycastle/asn1/oiw/OIWObjectIdentifiers.html
-
PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore wrote: > This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v15]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore wrote: > This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can
Re: RFR: 8007632: DES/3DES keys support in PKCS12 keystore
On Tue, 27 Oct 2020 12:27:52 GMT, Alexey Bakhtin wrote:
> Hi All,
>
> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
> keystores.
> This issue prevents the migration of legacy applications to PKCS#12 keystore.
> For example, an application has some old 3DES keys that are required for
> certain legacy features. Java PKCS12 keystore does not support DES/3DES keys,
> thus, application can’t migrate to PKCS#12
> This patch adds OIDs for the DES/DESede algorithms. It is the only changes
> required to support DES/3DES keys in the PKCS#12 keystore.
> sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys in
> the PKCS#12 keystore.
src/java.base/share/classes/sun/security/util/KnownOIDs.java line 355:
> 353: // OIW secsig 1.3.14.3.*
> 354: OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
> 355: OIW_DES_ECB("1.3.14.3.2.6", "DES/ECB", "DES"),
What OID are other vendors using?
-
PR: https://git.openjdk.java.net/jdk/pull/877
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v14]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
RFR: 8007632: DES/3DES keys support in PKCS12 keystore
Hi All, DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12 keystores. This issue prevents the migration of legacy applications to PKCS#12 keystore. For example, an application has some old 3DES keys that are required for certain legacy features. Java PKCS12 keystore does not support DES/3DES keys, thus, application can’t migrate to PKCS#12 This patch adds OIDs for the DES/DESede algorithms. It is the only changes required to support DES/3DES keys in the PKCS#12 keystore. sun/security/pkcs12/P12SecretKey test is updated to verify new secret keys in the PKCS#12 keystore. - Commit messages: - 8007632: DES/3DES keys support in PKCS12 keystore Changes: https://git.openjdk.java.net/jdk/pull/877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=877=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8007632 Stats: 16 lines in 2 files changed: 6 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/877/head:pull/877 PR: https://git.openjdk.java.net/jdk/pull/877
