[crac] RFR: Reseed secure random on checkpoint restore

[Dan Heidinga]

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