On Wed, 16 Nov 2022 23:41:32 GMT, Volodymyr Paprotski wrote:
>> Yes, please. And for the upper half of register file, just code it as a loop
>> over register range:
>>
>> for (int rxmm_num = 16; rxmm_num < 30; rxmm_num++) {
>> XMMRegister rxmm = as_XMMRegister(rxmm_num);
>> __ vpxorq(rxmm,
On Wed, 16 Nov 2022 23:16:14 GMT, Volodymyr Paprotski wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:
>>
>>> 754:
>>> 755: // Store R^8-R for later use
>>> 756: __ evmovdquq(Address(rsp, 64*0), B0, Assembler::AVX_512bit);
>>
>> Could these vector spills be eliminated?
On Thu, 17 Nov 2022 03:19:15 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Wed, 16 Nov 2022 23:39:00 GMT, Vladimir Ivanov wrote:
>> ah.. I remember thinking about doing that.. `vzeroall` isnt encoded yet and
>> I figured since I already have to do the xmm16-29, might as well do them
>> all.. should I add that instruction too?
>
> Yes, please. And for the upper half
On Wed, 16 Nov 2022 23:14:45 GMT, Volodymyr Paprotski wrote:
>> Or simply switch to `vzeroall` for `xmm0` - `xmm15`.
>
> ah.. I remember thinking about doing that.. `vzeroall` isnt encoded yet and I
> figured since I already have to do the xmm16-29, might as well do them all..
> should I add th
On Wed, 16 Nov 2022 23:08:16 GMT, Vladimir Ivanov wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 917:
>>
>>> 915: // Cleanup
>>> 916: __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);
>>> 917: __ vpxorq(xmm1, xmm1, xmm1, Assembler::AVX_512bit);
>>
>> You could use T0,
On Wed, 16 Nov 2022 23:12:28 GMT, Vladimir Ivanov wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> redo register alloc with explicit func params
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:
On Wed, 16 Nov 2022 20:52:14 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Wed, 16 Nov 2022 22:47:37 GMT, Sandhya Viswanathan
wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> redo register alloc with explicit func params
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line
On Wed, 16 Nov 2022 20:52:14 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino
wrote:
> I would like a review of an update to the GCM code. A recent report showed
> that GCM memory usage for TLS was very large. This was a result of in-place
> buffers, which TLS uses, and how the code handled the combined intrinsic
> m
On Fri, 11 Nov 2022 01:43:46 GMT, Vladimir Ivanov wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> live review with Sandhya
>
> Overall, it looks good.
@iwanowww Answered your review comments, please take a
On Sun, 13 Nov 2022 19:41:52 GMT, Andrey Turbanov wrote:
>> The `PCSCException` is thrown, but the error type is not visible due to the
>> "private-packe" access rule.
>> By changing the visibility it is possible to handle / access this exception
>> type explicitly in the catch.
>
> src/java.sm
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
src/java.smartcardi
The `PCSCException` is thrown, but the error type is not visible due to the
"private-packe" access rule.
By changing the visibility it is possible to handle / access this exception
type explicitly in the catch.
-
Commit messages:
- 8296408: Make the PCSCException public accessible
On Wed, 16 Nov 2022 21:28:37 GMT, Weijun Wang wrote:
> I was wondering if secure random generation could be sometimes fast and
> sometimes slow. I'm also not sure about how NativePRNG behaves in a
> multi-thread environment.
I see your point. But it is still part of the key generation. Measu
On Tue, 15 Nov 2022 19:44:16 GMT, Vladimir Ivanov wrote:
>> Volodymyr Paprotski has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 25 commits:
>>
>> - Vladimir's review comments
>> - Merge remote-tracking branch 'origin/master' int
On Tue, 15 Nov 2022 23:51:22 GMT, Vladimir Ivanov wrote:
>> Added a comment, hopefully less confusing.
>
> On a second thought, passing derived pointers as arguments doesn't mix well
> with safepoint awareness.
> (And this stub eventually has to become safepoint aware.)
> Deriving a pointer insi
On Tue, 15 Nov 2022 19:38:56 GMT, Volodymyr Paprotski wrote:
>>> On other hand, there are functions like poly1305_multiply8_avx512 and
>>> poly1305_process_blocks_avx512 that use a lot of temp registers. I think it
>>> makes sense to keep those as 'function-header declarations'.
>>
>> I agree
On Wed, 16 Nov 2022 20:55:45 GMT, Xue-Lei Andrew Fan wrote:
> > The generation might depend on secure randoms a lot. How about create a
> > simple `SecureRandom` that is fast and does not depend on any external
> > entropy source?
>
> The secure random generation is part of the key generation.
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
On Tue, 15 Nov 2022 19:30:23 GMT, Vladimir Ivanov wrote:
>> Volodymyr Paprotski has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 23 commits:
>>
>> - Merge remote-tracking branch 'origin/master' into avx512-poly
>> - Vladimir's re
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
On Wed, 16 Nov 2022 20:46:00 GMT, Weijun Wang wrote:
> The generation might depend on secure randoms a lot. How about create a
> simple `SecureRandom` that is fast and does not depend on any external
> entropy source?
The secure random generation is part of the key generation. It may be not t
On Wed, 16 Nov 2022 20:57:23 GMT, Xue-Lei Andrew Fan wrote:
> > Maybe you can do the same with the signature benchmark as well.
> > Unfortunately it has already been integrated.
>
> What do you mean with "the same"? secure random?
Yes, the secure random that can be provided in `initSign`.
---
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed?
>
> In the current key pair generation micro-benchmark, there is no cases for
> `EdDSA`, `XDH`, and `RSASSA-PSS`. This PR is trying to add these algorithms.
>
> BTW, here is the benchmarkin
On Wed, 9 Nov 2022 19:59:08 GMT, Weijun Wang wrote:
> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
> remember to initialize the params. This is unfortunate but since this is a
> public API,
On Wed, 16 Nov 2022 18:47:27 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
On Wed, 16 Nov 2022 18:12:21 GMT, Weijun Wang wrote:
>> test/jdk/sun/security/x509/AlgorithmId/Uninitialized.java line 35:
>>
>>> 33: import java.security.AlgorithmParameters;
>>> 34:
>>> 35: public class Uninitialized {
>>
>> Is this test necessary? It seems to be duplicating the additional t
On Wed, 16 Nov 2022 17:00:37 GMT, Mark Powers wrote:
>> I would like a review of an update to the GCM code. A recent report showed
>> that GCM memory usage for TLS was very large. This was a result of in-place
>> buffers, which TLS uses, and how the code handled the combined intrinsic
>> met
On Wed, 16 Nov 2022 18:19:30 GMT, Anthony Scarpino
wrote:
>> It's possibly worth noting that while this is merely fixing a regression for
>> x86, it's very likely a decent sized performance improvement on arm64, where
>> intrinsics for AES-GCM (depending on JVM vendor) aren't added until after
> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
> remember to initialize the params. This is unfortunate but since this is a
> public API, I hesitate to make a change.
>
> Instead, this code c
On Wed, 16 Nov 2022 14:21:48 GMT, Sean Mullan wrote:
> Did you consider changing EncryptedPrivateKeyInfo(...,AlgorithmParameters) to
> throw IllegalStateException if the parameters were not initialized? I know
> you said you were worried about changing the API, but it would be a cleaner
> opti
On Wed, 16 Nov 2022 16:18:15 GMT, James Baker wrote:
> It's possibly worth noting that while this is merely fixing a regression for
> x86, it's very likely a decent sized performance improvement on arm64, where
> intrinsics for AES-GCM (depending on JVM vendor) aren't added until after
> Java
On Wed, 16 Nov 2022 14:12:05 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> comment and exception message
>
> test/jdk/sun/security/x509/AlgorithmId/Uninitialized.java line 35:
>
>> 33: import jav
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino
wrote:
> I would like a review of an update to the GCM code. A recent report showed
> that GCM memory usage for TLS was very large. This was a result of in-place
> buffers, which TLS uses, and how the code handled the combined intrinsic
> m
Hi,
May I have this update reviewed?
In the current key pair generation micro-benchmark, there is no cases for
`EdDSA`, `XDH`, and `RSASSA-PSS`. This PR is trying to add these algorithms.
BTW, here is the benchmarking data on a Linux x86_64 platform. You can see how
much the performance diff
On Mon, 14 Nov 2022 05:11:33 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I get the micro benchmarking enhancement reviewed?
>
> Benchmark cases for RSA(SSA-PSS)/DSA are added in the PR. Here is the
> benchmarking number on a Linux X86_64 platform.
>
> Benchmark(a
On Wed, 16 Nov 2022 16:31:54 GMT, Sean Mullan wrote:
> > _Mailing list message from [Xuelei Fan](mailto:xuele...@gmail.com) on
> > [security-dev](mailto:security-...@mail.openjdk.org):_
> > > The wording in this PR specifically refers to the protocol version that
> >
> >
> > was specified. It
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino
wrote:
> I would like a review of an update to the GCM code. A recent report showed
> that GCM memory usage for TLS was very large. This was a result of in-place
> buffers, which TLS uses, and how the code handled the combined intrinsic
> m
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino
wrote:
> I would like a review of an update to the GCM code. A recent report showed
> that GCM memory usage for TLS was very large. This was a result of in-place
> buffers, which TLS uses, and how the code handled the combined intrinsic
> m
On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan wrote:
> Please review this PR to add an implementation note to
> the`SSLContext.getInstance` methods to document the behavior when a protocol
> is disabled.
> _Mailing list message from [Xuelei Fan](mailto:xuele...@gmail.com) on
> [security-dev](
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino
wrote:
> I would like a review of an update to the GCM code. A recent report showed
> that GCM memory usage for TLS was very large. This was a result of in-place
> buffers, which TLS uses, and how the code handled the combined intrinsic
> m
On Fri, 21 Oct 2022 12:29:22 GMT, Andrew Haley wrote:
>> This PR delivers ChaCha20 intrinsics that accelerate the core block function
>> that generates key stream from the key, counter and nonce. Intrinsics have
>> been written for the following platforms and instruction sets:
>>
>> - x86_64:
On Thu, 10 Nov 2022 14:51:54 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 177:
>>
>>> 175: // If still not initialized. Let the IOE be thrown.
>>> 176: }
>>> 177:
>>
>> This could be a risk change if the caller was not coded
On Tue, 15 Nov 2022 21:51:28 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 119:
>>
>>> 117: }
>>> 118:
>>> 119: MacData(AlgorithmParameters algParams, byte[] digest,
>>
>> Is this related to this issue in some way or just a ctor that is no
On Tue, 15 Nov 2022 22:02:11 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
>> 65:
>>
>>> 63: // In all other case, algid is non null and params is null.
>>> 64: private final AlgorithmId algid;
>>> 65: private final AlgorithmPa
On Wed, 16 Nov 2022 03:41:11 GMT, Weijun Wang wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public
> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
> inside, a new static method `signNew` is introduced to create a newly signed
> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
> an `X509CertImpl` is always signed and there is no read t
On Wed, 16 Nov 2022 08:07:17 GMT, Andrey Turbanov wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> a method called by test
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1324:
>
>> 1322:
On Tue, 15 Nov 2022 02:50:10 GMT, Weijun Wang wrote:
>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
>> inside, a new static method `signNew` is introduced to create a newly signed
>> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
>
53 matches
Mail list logo
