[crac] RFR: Reseed secure random on checkpoint restore

[Alexey Bakhtin]

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