From akozlov at openjdk.java.net  Wed Dec  8 19:41:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 8 Dec 2021 19:41:49 GMT
Subject: [crac] RFR: Disable recursive checkpoint
In-Reply-To: <RcS9S4akRqNX11fOoW170n_IoOlw3MUw8E0azNG6Xrs=.7ecc66f7-37bf-4b3a-9440-2e83b174f86c@github.com>
References: <A1jjn8EyRIxGExqTqv6y9oZaN1w9qk8PMHz0Hh6vWDI=.9d7a0e22-bf65-49d5-ab64-7df63a1760d9@github.com>
 <RcS9S4akRqNX11fOoW170n_IoOlw3MUw8E0azNG6Xrs=.7ecc66f7-37bf-4b3a-9440-2e83b174f86c@github.com>
Message-ID: <LNTcCKUMfxAaldH6w-orcSKlUfMdrXlAexF0uOd4vt4=.78362425-3751-4c6e-a2e1-5c09bc220c82@github.com>

On Wed, 8 Dec 2021 14:27:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> .jcheck/conf in the source branch is missing the `census` section with the domain field.

Thanks for the message! I added the section in https://github.com/openjdk/crac/commit/2dc038442ad108390ce1cf5be2a37e0a4dc5a8d7, is it fine now?

-------------

PR: https://git.openjdk.java.net/crac/pull/6

From abakhtin at openjdk.java.net  Mon Dec 20 15:44:12 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 20 Dec 2021 15:44:12 GMT
Subject: [crac] RFR: JDKResource priorities
Message-ID: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>

Added priority enumeration for the JDK resources
It will allow better handling the order of checkpoint notifications for dependent resources

-------------

Commit messages:
 - JDKResource priorities

Changes: https://git.openjdk.java.net/crac/pull/8/files
 Webrev: https://webrevs.openjdk.java.net/?repo=crac&pr=8&range=00
  Stats: 32 lines in 6 files changed: 22 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/crac/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/8/head:pull/8

PR: https://git.openjdk.java.net/crac/pull/8

From abakhtin at openjdk.java.net  Mon Dec 20 15:48:15 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 20 Dec 2021 15:48:15 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
Message-ID: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>

Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
Two jtreg tests added: 
- verify if no deadlocks introduced by checkpoint/restore
- verify if SHA1PRNG is reseeded if created with default embedded seed generator

-------------

Commit messages:
 - Reseed secure random on checkpoint restore

Changes: https://git.openjdk.java.net/crac/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=crac&pr=7&range=00
  Stats: 431 lines in 5 files changed: 381 ins; 11 del; 39 mod
  Patch: https://git.openjdk.java.net/crac/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/7/head:pull/7

PR: https://git.openjdk.java.net/crac/pull/7

From duke at openjdk.java.net  Mon Dec 20 15:48:16 2021
From: duke at openjdk.java.net (Dan Heidinga)
Date: Mon, 20 Dec 2021 15:48:16 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
Message-ID: <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>

On Fri, 17 Dec 2021 13:38:18 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
> Two jtreg tests added: 
> - verify if no deadlocks introduced by checkpoint/restore
> - verify if SHA1PRNG is reseeded if created with default embedded seed generator

src/java.base/share/classes/sun/security/provider/SecureRandom.java line 176:

> 174:             state = digest.digest(seed);
> 175:             remCount = 0;
> 176:             clearStateOnCheckpoint = false;

I'm not clear on why we need this boolean.  Why does the code say not to clear this Random on a checkpoint if someone has called `engineSetSeed`?

src/java.base/share/classes/sun/security/provider/SecureRandom.java line 244:

> 242:         if (isSeedGenerator)
> 243:             return -12;
> 244:         return -11;

How are priorities determined?  I see other implementors of this method mostly setting their priority to 0.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Mon Dec 20 15:48:17 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 20 Dec 2021 15:48:17 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>
Message-ID: <2xd9rC0aP2mzEy4Vg8jdgisuSXlZ3JV8fnsW3Ab1elk=.e8727733-412f-453b-a056-fe322fe3609a@github.com>

On Fri, 17 Dec 2021 14:07:38 GMT, Dan Heidinga <duke at openjdk.java.net> wrote:

>> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
>> Two jtreg tests added: 
>> - verify if no deadlocks introduced by checkpoint/restore
>> - verify if SHA1PRNG is reseeded if created with default embedded seed generator
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 176:
> 
>> 174:             state = digest.digest(seed);
>> 175:             remCount = 0;
>> 176:             clearStateOnCheckpoint = false;
> 
> I'm not clear on why we need this boolean.  Why does the code say not to clear this Random on a checkpoint if someone has called `engineSetSeed`?

By default, SHA1PRNG implementation depends on the initial seed and is not reseeded internally. The random sequence is a function of initial seed. So, an application could expect a particular sequence on depends on the seed provided. This is a reason we can not reseed secure random if the application provides its own seed. In case of application does not provide seed, the seed is auto-assigned by implementation. It means the application is not depends on particular random sequence. It means we can re-seed such secure randoms during checkpoint/restore.
Secure Randoms, seeded by the application should be handled by this application layer because of only application knows How to handle it.
So, we'll re-seed secure randoms only in case of we sure it does not change application logic

> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 244:
> 
>> 242:         if (isSeedGenerator)
>> 243:             return -12;
>> 244:         return -11;
> 
> How are priorities determined?  I see other implementors of this method mostly setting their priority to 0.

Hi @DanHeidinga 
Default global CRaC Context implementation uses resource priorities to define the order of checkpoint notifications (beforeCheckpoint). Resource priorities are automatically assigned incrementally upon resource registration in the context. The lowest priority is 0. Order of checkpoint notification is the reverse order of registration.
There are JDKContext and JDKResource internal implementations. These classes allow assigning priorities to specific resources. The order of checkpoint notifications for JDKResources is from higher to lower priorities.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From duke at openjdk.java.net  Mon Dec 20 15:48:18 2021
From: duke at openjdk.java.net (Dan Heidinga)
Date: Mon, 20 Dec 2021 15:48:18 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <2xd9rC0aP2mzEy4Vg8jdgisuSXlZ3JV8fnsW3Ab1elk=.e8727733-412f-453b-a056-fe322fe3609a@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>
 <2xd9rC0aP2mzEy4Vg8jdgisuSXlZ3JV8fnsW3Ab1elk=.e8727733-412f-453b-a056-fe322fe3609a@github.com>
Message-ID: <6kbsB7u-Nbvt0naQ5QSjsdVdtq4wzmsTqnlSD3llIFM=.c4403571-e188-4f9c-8bea-d2d4fc60cdae@github.com>

On Fri, 17 Dec 2021 15:17:43 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 176:
>> 
>>> 174:             state = digest.digest(seed);
>>> 175:             remCount = 0;
>>> 176:             clearStateOnCheckpoint = false;
>> 
>> I'm not clear on why we need this boolean.  Why does the code say not to clear this Random on a checkpoint if someone has called `engineSetSeed`?
>
> By default, SHA1PRNG implementation depends on the initial seed and is not reseeded internally. The random sequence is a function of initial seed. So, an application could expect a particular sequence on depends on the seed provided. This is a reason we can not reseed secure random if the application provides its own seed. In case of application does not provide seed, the seed is auto-assigned by implementation. It means the application is not depends on particular random sequence. It means we can re-seed such secure randoms during checkpoint/restore.
> Secure Randoms, seeded by the application should be handled by this application layer because of only application knows How to handle it.
> So, we'll re-seed secure randoms only in case of we sure it does not change application logic

That makes a lot of sense - thanks for clarifying!

>> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 244:
>> 
>>> 242:         if (isSeedGenerator)
>>> 243:             return -12;
>>> 244:         return -11;
>> 
>> How are priorities determined?  I see other implementors of this method mostly setting their priority to 0.
>
> Hi @DanHeidinga 
> Default global CRaC Context implementation uses resource priorities to define the order of checkpoint notifications (beforeCheckpoint). Resource priorities are automatically assigned incrementally upon resource registration in the context. The lowest priority is 0. Order of checkpoint notification is the reverse order of registration.
> There are JDKContext and JDKResource internal implementations. These classes allow assigning priorities to specific resources. The order of checkpoint notifications for JDKResources is from higher to lower priorities.

Given that explanation, how were `-12` & `-11` chosen here?  Randomly as low enough to ensure these are changed late?

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Mon Dec 20 15:48:18 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 20 Dec 2021 15:48:18 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <6kbsB7u-Nbvt0naQ5QSjsdVdtq4wzmsTqnlSD3llIFM=.c4403571-e188-4f9c-8bea-d2d4fc60cdae@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>
 <2xd9rC0aP2mzEy4Vg8jdgisuSXlZ3JV8fnsW3Ab1elk=.e8727733-412f-453b-a056-fe322fe3609a@github.com>
 <6kbsB7u-Nbvt0naQ5QSjsdVdtq4wzmsTqnlSD3llIFM=.c4403571-e188-4f9c-8bea-d2d4fc60cdae@github.com>
Message-ID: <NvOltxODne4Dqcea9fvxJCGppXGzaMXBDe68Sf8ikMM=.121a8b3c-21e6-4553-a9c8-b6312dc7d64d@github.com>

On Fri, 17 Dec 2021 19:55:13 GMT, Dan Heidinga <duke at openjdk.java.net> wrote:

>> Hi @DanHeidinga 
>> Default global CRaC Context implementation uses resource priorities to define the order of checkpoint notifications (beforeCheckpoint). Resource priorities are automatically assigned incrementally upon resource registration in the context. The lowest priority is 0. Order of checkpoint notification is the reverse order of registration.
>> There are JDKContext and JDKResource internal implementations. These classes allow assigning priorities to specific resources. The order of checkpoint notifications for JDKResources is from higher to lower priorities.
>
> Given that explanation, how were `-12` & `-11` chosen here?  Randomly as low enough to ensure these are changed late?

Yes and No :) I left some space for the future JDK resources that depend on the secure randoms (use secure random inside own beforeCheckpoint method)
Maybe these priorities should be collected in a single class, e.g. defined in the JDKresource interface

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Mon Dec 20 15:48:18 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 20 Dec 2021 15:48:18 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <NvOltxODne4Dqcea9fvxJCGppXGzaMXBDe68Sf8ikMM=.121a8b3c-21e6-4553-a9c8-b6312dc7d64d@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <1Iadt8946GRqztVU8APML7IvNWQuiTb_ulhiUOcd4dM=.e70d5ae8-3ad9-4f2d-9dc4-e062252a5756@github.com>
 <2xd9rC0aP2mzEy4Vg8jdgisuSXlZ3JV8fnsW3Ab1elk=.e8727733-412f-453b-a056-fe322fe3609a@github.com>
 <6kbsB7u-Nbvt0naQ5QSjsdVdtq4wzmsTqnlSD3llIFM=.c4403571-e188-4f9c-8bea-d2d4fc60cdae@github.com>
 <NvOltxODne4Dqcea9fvxJCGppXGzaMXBDe68Sf8ikMM=.121a8b3c-21e6-4553-a9c8-b6312dc7d64d@github.com>
Message-ID: <6hUaURBp1pU1rcGvMw8tFAmjWuGXxAvTQi6JXYvbVio=.492e7e97-3100-4ba8-b4db-b2825855b393@github.com>

On Fri, 17 Dec 2021 21:06:21 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Given that explanation, how were `-12` & `-11` chosen here?  Randomly as low enough to ensure these are changed late?
>
> Yes and No :) I left some space for the future JDK resources that depend on the secure randoms (use secure random inside own beforeCheckpoint method)
> Maybe these priorities should be collected in a single class, e.g. defined in the JDKresource interface

Added pull request to collect JDKResorce priorities in the single enumeration: https://github.com/openjdk/crac/pull/8
Current PR will be updated as soon as JDKResource priorities is accepted and integrated

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From akozlov at openjdk.java.net  Wed Dec 22 10:15:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 22 Dec 2021 10:15:44 GMT
Subject: [crac] RFR: JDKResource priorities
In-Reply-To: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
References: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
Message-ID: <UHvp2wVnBQ2TyGRqUmWW6nkRhu1lREkJCbPwLqswjIg=.be7c5c1d-424a-44e9-bc70-a16e56ff36a5@github.com>

On Mon, 20 Dec 2021 15:39:03 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Added priority enumeration for the JDK resources
> It will allow better handling the order of checkpoint notifications for dependent resources

Marked as reviewed by akozlov (Lead).

src/java.base/share/classes/jdk/internal/crac/JDKResource.java line 36:

> 34:      * Most resources should use NORMAL.
> 35:      * Other priorities define sequence of
> 36:      * checkpoint notification for dependent resources

It's worth adding explicitly how the order in the enum and priorities are related. E.g. priorities are specified in the decreasing order. If a priority A is specified before a priority B, a resource with A will be handled sooner.

"Order" would be a better term for this in the first place originally, my fault.

src/java.base/share/classes/jdk/internal/crac/JDKResource.java line 43:

> 41:          * sun.nio.ch.EPollSelectorImpl resource
> 42:          */
> 43:         EPOLLSELECTOR,

This uncovers the future mess we'll have with manually setting the order, similar to the mutex order in the Hotspot. However, I like this central place to control them. This approach is by no means worse than the existing code but highlights a point of growth.

-------------

PR: https://git.openjdk.java.net/crac/pull/8

From abakhtin at openjdk.java.net  Thu Dec 23 11:48:12 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 23 Dec 2021 11:48:12 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
Message-ID: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>

NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
Also, the internal buffer should be cleared at the checkpoint.

-------------

Commit messages:
 - Reseed NativePRNG on checkpoint restore

Changes: https://git.openjdk.java.net/crac/pull/9/files
 Webrev: https://webrevs.openjdk.java.net/?repo=crac&pr=9&range=00
  Stats: 244 lines in 3 files changed: 242 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/crac/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/9/head:pull/9

PR: https://git.openjdk.java.net/crac/pull/9

From akozlov at openjdk.java.net  Thu Dec 23 14:10:45 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 23 Dec 2021 14:10:45 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
Message-ID: <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>

On Fri, 17 Dec 2021 13:38:18 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
> Two jtreg tests added: 
> - verify if no deadlocks introduced by checkpoint/restore
> - verify if SHA1PRNG is reseeded if created with default embedded seed generator

Changes requested by akozlov (Lead).

src/java.base/share/classes/sun/security/provider/SecureRandom.java line 267:

> 265:             SeedGenerator.generateSeed(b);
> 266:             seeder.engineSetSeed(b);
> 267:             seeder.clearStateOnCheckpoint = true;

This highlights that the `seeder` differs from any other SecureRandom. I would prefer `seeder` to be an object of a subclass of `SecureRandom`. This will also save us a field `isSeedGenerator` that is false for all except one object in the system.

src/java.base/share/classes/sun/security/provider/SecureRandom.java line 278:

> 276:     @Override
> 277:     public void engineNextBytes(byte[] result) {
> 278:         objLock.lock();

A minor drawback, the keyword in the method declaration makes the synchronization more explicit. An alternative is to retain the synchronization the on object monitor by e.g.


private boolean blocked = false;

public synchronized void engineNextBytes {
   while (blocked) {
     this.wait()
   }
   ...
}

public synchronized void beforeCheckpoint {
  blocked = true
  ...
}
public synchronized void afterRestore {
  ...
  blocked = false;
  this.notifyAll();
}


However, a dedicated ReentrantLock makes the implementation a bit shorter. So, up to you.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Thu Dec 23 16:12:34 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 23 Dec 2021 16:12:34 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
Message-ID: <fJbzPHBiYdaKxjY2wm5yyYYGQ9DcZAnLD-WE47Qbb_A=.52ae716c-3a71-472f-a3a4-268bd4c74b80@github.com>

On Thu, 23 Dec 2021 13:45:54 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
>> Two jtreg tests added: 
>> - verify if no deadlocks introduced by checkpoint/restore
>> - verify if SHA1PRNG is reseeded if created with default embedded seed generator
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 267:
> 
>> 265:             SeedGenerator.generateSeed(b);
>> 266:             seeder.engineSetSeed(b);
>> 267:             seeder.clearStateOnCheckpoint = true;
> 
> This highlights that the `seeder` differs from any other SecureRandom. I would prefer `seeder` to be an object of a subclass of `SecureRandom`. This will also save us a field `isSeedGenerator` that is false for all except one object in the system.

Unfortunately sun.security.provider.SecureRandom class is final. I think it was done intentionally for security reasons.
isSeedGenerator can be easily replaced by comparison with SeederHolder.seeder but it'll eat time during restore.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Thu Dec 23 17:29:43 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 23 Dec 2021 17:29:43 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
Message-ID: <yuD0sNQEfLtl3I1T4rkJ2qRH2eWdQefau2OQqlAEsKE=.1417d055-7e60-47ab-8142-00c8740fcc25@github.com>

On Thu, 23 Dec 2021 14:07:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
>> Two jtreg tests added: 
>> - verify if no deadlocks introduced by checkpoint/restore
>> - verify if SHA1PRNG is reseeded if created with default embedded seed generator
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 278:
> 
>> 276:     @Override
>> 277:     public void engineNextBytes(byte[] result) {
>> 278:         objLock.lock();
> 
> A minor drawback, the keyword in the method declaration makes the synchronization more explicit. An alternative is to retain the synchronization the on object monitor by e.g.
> 
> 
> private boolean blocked = false;
> 
> public synchronized void engineNextBytes {
>    while (blocked) {
>      this.wait()
>    }
>    ...
> }
> 
> public synchronized void beforeCheckpoint {
>   blocked = true
>   ...
> }
> public synchronized void afterRestore {
>   ...
>   blocked = false;
>   this.notifyAll();
> }
> 
> 
> However, a dedicated ReentrantLock makes the implementation a bit shorter. So, up to you.

Yes, it makes sense. But using Lock object in the beforeCheckpoint() -> afterRestore() methods looks more natural.
Also, in your case, we'll have to check for interruptedException and modify engineSetSeed() accordingly.
If there are no more objections, I would use objLock for synchronization.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Thu Dec 23 21:39:15 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 23 Dec 2021 21:39:15 GMT
Subject: [crac] RFR: JDKResource priorities [v2]
In-Reply-To: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
References: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
Message-ID: <gPVq-f9pwKYkJKoAc_0a0-I7TN9CrR3-tP6jRN-KwoY=.f0e790ef-76d3-4880-9111-5ef3c0d17ee9@github.com>

> Added priority enumeration for the JDK resources
> It will allow better handling the order of checkpoint notifications for dependent resources

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Added JDKResource.Priority descriptio

-------------

Changes:
  - all: https://git.openjdk.java.net/crac/pull/8/files
  - new: https://git.openjdk.java.net/crac/pull/8/files/58f23f67..0a50fb1f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=crac&pr=8&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=crac&pr=8&range=00-01

  Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/crac/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/8/head:pull/8

PR: https://git.openjdk.java.net/crac/pull/8

From duke at openjdk.java.net  Fri Dec 24 06:40:43 2021
From: duke at openjdk.java.net (Michael Bien)
Date: Fri, 24 Dec 2021 06:40:43 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
Message-ID: <NMw-FzqGCfdfUIqtH6xZPQ7FC22RfmWLVxyUupOZ5wU=.34328222-5519-443c-b4a6-9d0d2bb6338e@github.com>

On Thu, 23 Dec 2021 11:30:13 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
> Also, the internal buffer should be cleared at the checkpoint.

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 595:

> 593:             for(int i=0; i<nextBuffer.length; i++) {
> 594:                 nextBuffer[i] = 0;
> 595:             }

could use Arrays.fill

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From akozlov at openjdk.java.net  Fri Dec 24 08:52:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 24 Dec 2021 08:52:44 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore
In-Reply-To: <fJbzPHBiYdaKxjY2wm5yyYYGQ9DcZAnLD-WE47Qbb_A=.52ae716c-3a71-472f-a3a4-268bd4c74b80@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
 <fJbzPHBiYdaKxjY2wm5yyYYGQ9DcZAnLD-WE47Qbb_A=.52ae716c-3a71-472f-a3a4-268bd4c74b80@github.com>
Message-ID: <ZQyp67mTaJSlAZ4myl7i5TNN0M8wYhOh5VI05z2aaIs=.ad276932-e573-489a-8055-98fea637b542@github.com>

On Thu, 23 Dec 2021 16:09:01 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 267:
>> 
>>> 265:             SeedGenerator.generateSeed(b);
>>> 266:             seeder.engineSetSeed(b);
>>> 267:             seeder.clearStateOnCheckpoint = true;
>> 
>> This highlights that the `seeder` differs from any other SecureRandom. I would prefer `seeder` to be an object of a subclass of `SecureRandom`. This will also save us a field `isSeedGenerator` that is false for all except one object in the system.
>
> Unfortunately sun.security.provider.SecureRandom class is final. I think it was done intentionally for security reasons.
> isSeedGenerator can be easily replaced by comparison with SeederHolder.seeder but it'll eat time during restore.

Another option is to make `SeederHolder` to be the `Resource` that cleans `seeder` on checkpoint and creates one on restore. I think `seeder.clearStateOnCheckpoint = true` won't be needed, as the next checkpoint will clear-up the seeder again.

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Fri Dec 24 09:11:50 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 09:11:50 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <NMw-FzqGCfdfUIqtH6xZPQ7FC22RfmWLVxyUupOZ5wU=.34328222-5519-443c-b4a6-9d0d2bb6338e@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
 <NMw-FzqGCfdfUIqtH6xZPQ7FC22RfmWLVxyUupOZ5wU=.34328222-5519-443c-b4a6-9d0d2bb6338e@github.com>
Message-ID: <i6jNN7t8aVJW3QUSVwyiuGTjBgG66lT2iqbTPwcku3Q=.15749fe9-e8b8-4a3b-a348-93a61d9bc65e@github.com>

On Fri, 24 Dec 2021 06:37:17 GMT, Michael Bien <duke at openjdk.java.net> wrote:

>> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
>> Also, the internal buffer should be cleared at the checkpoint.
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 595:
> 
>> 593:             for(int i=0; i<nextBuffer.length; i++) {
>> 594:                 nextBuffer[i] = 0;
>> 595:             }
> 
> could use Arrays.fill

Yes. Thank you. I will update

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 12:14:07 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 12:14:07 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore [v2]
In-Reply-To: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
Message-ID: <mw5sNpZm55KWxHSWH8YK3T0Y7LCoVGjMT8b0yFc3Sqo=.eae83d37-38ec-4284-83d1-e646255ffd9f@github.com>

> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
> Two jtreg tests added: 
> - verify if no deadlocks introduced by checkpoint/restore
> - verify if SHA1PRNG is reseeded if created with default embedded seed generator

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Add separate JDKResorce for seeder

-------------

Changes:
  - all: https://git.openjdk.java.net/crac/pull/7/files
  - new: https://git.openjdk.java.net/crac/pull/7/files/dc636105..e26d0b81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=crac&pr=7&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=crac&pr=7&range=00-01

  Stats: 65 lines in 1 file changed: 36 ins; 25 del; 4 mod
  Patch: https://git.openjdk.java.net/crac/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/7/head:pull/7

PR: https://git.openjdk.java.net/crac/pull/7

From abakhtin at openjdk.java.net  Fri Dec 24 12:14:07 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 12:14:07 GMT
Subject: [crac] RFR: Reseed secure random on checkpoint restore [v2]
In-Reply-To: <ZQyp67mTaJSlAZ4myl7i5TNN0M8wYhOh5VI05z2aaIs=.ad276932-e573-489a-8055-98fea637b542@github.com>
References: <H-Lm0DbOVw7i4pJoVMOa-IRTAyWZrcIlyIt9UFVHjxY=.03bbdffd-d4b1-42f7-80dc-de1659129bdb@github.com>
 <DmIlt0gq463CnwqIknWixiXduDWwqYaQ6NRaiT_57fQ=.efef9463-a2be-4d86-aec2-a25ed42fc417@github.com>
 <fJbzPHBiYdaKxjY2wm5yyYYGQ9DcZAnLD-WE47Qbb_A=.52ae716c-3a71-472f-a3a4-268bd4c74b80@github.com>
 <ZQyp67mTaJSlAZ4myl7i5TNN0M8wYhOh5VI05z2aaIs=.ad276932-e573-489a-8055-98fea637b542@github.com>
Message-ID: <JvKFpmcTzQGb9W-LTgiiY88hD3T1cLkFTD0XNf69ZXY=.223867c0-8c5e-43d0-a858-6f71fb5be3b6@github.com>

On Fri, 24 Dec 2021 08:49:28 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Another option is to make `SeederHolder` to be the `Resource` that cleans `seeder` on checkpoint and creates one on restore. I think `seeder.clearStateOnCheckpoint = true` won't be needed, as the next checkpoint will clear-up the seeder again.

You are right. Thank you. Reimplemented as you suggested

-------------

PR: https://git.openjdk.java.net/crac/pull/7

From akozlov at openjdk.java.net  Fri Dec 24 12:59:47 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 24 Dec 2021 12:59:47 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
Message-ID: <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>

On Thu, 23 Dec 2021 11:30:13 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
> Also, the internal buffer should be cleared at the checkpoint.

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 391:

> 389: 
> 390:         // lock for checkpoint/restore
> 391:         private final ReentrantLock crLock = new ReentrantLock();

The comment should specify it protects both mixRandom and the buffer of the truly random values read from OS.

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 589:

> 587:         @Override
> 588:         public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
> 589:             crLock.lock();

The new lock is very related to `LOCK_GET_BYTES`, however, this code does not acquire `LOCK_GET_BYTES`. Now all `synchronized (LOCK_GET_BYTES)` blocks are executed under `crLock`. But I would prefer at least `assert crLock.isHeldByCurrentThread()` near those synchronized blocks, or any other way to ensure / document locks relation. Or use the LOCK_GET_BYTES, considering the other problem with premature buffer and mixRandom initialzation.

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 595:

> 593:             for(int i=0; i<nextBuffer.length; i++) {
> 594:                 nextBuffer[i] = 0;
> 595:             }

I assume this clean-up serves two purposes: 1) to clear the state that was already used to generate other values, so to prevent guessing them; 2) to force next request for random values will force filling of the buffer with real random data and fresh initialization of mixRandom. 

For 2, what if another `beforeCheckpoint` inadvertently calls `NativePRNG.engineNextBytes`? `crLock` (reentrant) will not prevent reading random values from OS and setting an instance for `mixRandom` before the checkpoint, but they will live later forever on restore. So I assume a similar clean-up is required in `afterRestore` (we may happen to store some state for NativePRNG, but this state won't be related to the previous state before the checkpoint and the one created later after restore).

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 14:41:41 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 14:41:41 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
 <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
Message-ID: <WwWuRyzG1IlAl6Oecm_OvUvV1fGFYLXw0HkKagUDSuk=.e373b182-d701-4bae-88c2-bfb980934607@github.com>

On Fri, 24 Dec 2021 11:24:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
>> Also, the internal buffer should be cleared at the checkpoint.
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 595:
> 
>> 593:             for(int i=0; i<nextBuffer.length; i++) {
>> 594:                 nextBuffer[i] = 0;
>> 595:             }
> 
> I assume this clean-up serves two purposes: 1) to clear the state that was already used to generate other values, so to prevent guessing them; 2) to force next request for random values will force filling of the buffer with real random data and fresh initialization of mixRandom. 
> 
> For 2, what if another `beforeCheckpoint` inadvertently calls `NativePRNG.engineNextBytes`? `crLock` (reentrant) will not prevent reading random values from OS and setting an instance for `mixRandom` before the checkpoint, but they will live later forever on restore. So I assume a similar clean-up is required in `afterRestore` (we may happen to store some state for NativePRNG, but this state won't be related to the previous state before the checkpoint and the one created later after restore).

For 2. I think it is just a matter of JDKResource.Priority. The use case you described is about dependent resources (see https://github.com/openjdk/crac/pull/8). In this case, the priority of the NativePRNG should be adjusted in the JDKResource.Priority.
Also, I would suggest adding a debug option that enables detection of the incorrect usage of the JDKResource A inside beforeCheckpoint of JDKResource B (priority A > priority B)

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 16:15:07 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 16:15:07 GMT
Subject: [crac] RFR: JDKResource priorities [v3]
In-Reply-To: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
References: <5BBQwRf02HUlyGIHpv28NMFt_Vpaf4S53zofrdrlTAM=.f1016910-052b-40cc-b91a-0cb644075923@github.com>
Message-ID: <DyKxySjAyKnAQ5XuE_vsDXe4Fmv6WyHkbsdJQv0FGjY=.b9859eee-50c4-4b01-ad3f-46259aff3a8f@github.com>

> Added priority enumeration for the JDK resources
> It will allow better handling the order of checkpoint notifications for dependent resources

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Changed priority order in the enum

-------------

Changes:
  - all: https://git.openjdk.java.net/crac/pull/8/files
  - new: https://git.openjdk.java.net/crac/pull/8/files/0a50fb1f..f1140138

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=crac&pr=8&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=crac&pr=8&range=01-02

  Stats: 14 lines in 2 files changed: 2 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/crac/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/8/head:pull/8

PR: https://git.openjdk.java.net/crac/pull/8

From abakhtin at openjdk.java.net  Fri Dec 24 18:43:27 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 18:43:27 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
 <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
Message-ID: <i7iUkQs7Rk9FXtZOsACkc3kM4TseyDVKcALeZIUt1hc=.733f5387-05d4-4e19-a505-24cc509d8396@github.com>

On Fri, 24 Dec 2021 12:45:20 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
>> Also, the internal buffer should be cleared at the checkpoint.
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 589:
> 
>> 587:         @Override
>> 588:         public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
>> 589:             crLock.lock();
> 
> The new lock is very related to `LOCK_GET_BYTES`, however, this code does not acquire `LOCK_GET_BYTES`. Now all `synchronized (LOCK_GET_BYTES)` blocks are executed under `crLock`. But I would prefer at least `assert crLock.isHeldByCurrentThread()` near those synchronized blocks, or any other way to ensure / document locks relation. Or use the LOCK_GET_BYTES, considering the other problem with premature buffer and mixRandom initialzation.

I do not see any issues between `crLock` and `LOCK_GET_BYTES.` `beforeCheckpoint` does not acquire any additional locks, so it should not cause deadlocks.
It is normal if different threads try to acquire `crLock.` In this case, one of them waits for the completion of another. E.g. `beforeCheckpoint` waits for completion `implNextBytes()` and vice versa. So, `assert crLock.isHeldByCurrentThread()` is not required.
In case of `implNextBytes` called from the `beforeCheckpoint` and `crLock` already acquired by `RandomIO.beforeCheckpoint` will have improper priorities of dependent JDKResources. It should be properly adjusted in the JDKResource.Priority (see #8)

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 21:03:37 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 21:03:37 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore
In-Reply-To: <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
 <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
Message-ID: <pU1t8HhAneCrVR6CHkuaCzIZ5wVH5vb6jNuObj_XqHY=.d6f1229e-d749-464c-8bea-09a6b215b3ed@github.com>

On Fri, 24 Dec 2021 12:45:20 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
>> Also, the internal buffer should be cleared at the checkpoint.
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 589:
> 
>> 587:         @Override
>> 588:         public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
>> 589:             crLock.lock();
> 
> The new lock is very related to `LOCK_GET_BYTES`, however, this code does not acquire `LOCK_GET_BYTES`. Now all `synchronized (LOCK_GET_BYTES)` blocks are executed under `crLock`. But I would prefer at least `assert crLock.isHeldByCurrentThread()` near those synchronized blocks, or any other way to ensure / document locks relation. Or use the LOCK_GET_BYTES, considering the other problem with premature buffer and mixRandom initialzation.

I do not see any issues between `crLock` and `LOCK_GET_BYTES.` `beforeCheckpoint` does not acquire any additional locks, so it should not cause deadlocks.
It is normal if different threads try to acquire `crLock.` In this case, one of them waits for the completion of another. E.g. `beforeCheckpoint` waits for completion `implNextBytes()` and vice versa. So, assert `crLock.isHeldByCurrentThread()` is not required.
In case of `implNextBytes` called from the `beforeCheckpoint` and `crLock` already acquired by `RandomIO.beforeCheckpoint` will have improper priorities of dependent `JDKResources.` It should be properly adjusted in the `JDKResource.Priority` (see #8)
The only problem is performance. `INSTANCE` is a single object. So, locking the whole  `implNextBytes` method will affect performance dramatically. I think It can be fixed by `ReentrantReadWriteLock`. Will update implementation

-------------

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 21:35:22 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 21:35:22 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore [v2]
In-Reply-To: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
Message-ID: <dO8O6uXSdISkBocnsw30mMWdRVnQ7HknCgjCpCyrgIM=.4847588d-f7a1-48bd-9408-5775eea03bdf@github.com>

> NativePRNG should be re-seeded during checkpoint/restore because it uses SHA1PRNG secure random for additional seed. It is seeded at initialization, so it is not re-seeded automatically during checkpoint/restore
> Also, the internal buffer should be cleared at the checkpoint.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Use ReentrantReadWriteLock

-------------

Changes:
  - all: https://git.openjdk.java.net/crac/pull/9/files
  - new: https://git.openjdk.java.net/crac/pull/9/files/894576ee..196edc75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=crac&pr=9&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=crac&pr=9&range=00-01

  Stats: 13 lines in 2 files changed: 1 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/crac/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/crac pull/9/head:pull/9

PR: https://git.openjdk.java.net/crac/pull/9

From abakhtin at openjdk.java.net  Fri Dec 24 21:35:23 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 24 Dec 2021 21:35:23 GMT
Subject: [crac] RFR: Reseed NativePRNG on checkpoint restore [v2]
In-Reply-To: <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
References: <l4mVluS4IvZCsFDd0pVCAfTDUaF24C8WBp_wFqDuSoM=.a92606f9-785a-467b-a929-21364124241f@github.com>
 <px9CqmIFacMViedudiC8LEz5MPieIGOZxlzVV-34dsE=.6c566b0a-af1c-417d-8e54-d1bd92b2e12f@github.com>
Message-ID: <tXEjy5fXBDhys9bgN34e6pk5CjN54lXCSyR9MbbeUDA=.3829a1dd-df32-4917-ba65-21222155be2c@github.com>

On Fri, 24 Dec 2021 11:30:45 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ReentrantReadWriteLock
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 391:
> 
>> 389: 
>> 390:         // lock for checkpoint/restore
>> 391:         private final ReentrantLock crLock = new ReentrantLock();
> 
> The comment should specify it protects both mixRandom and the buffer of the truly random values read from OS.

Will do

-------------

PR: https://git.openjdk.java.net/crac/pull/9