[crac] RFR: Reseed NativePRNG on checkpoint restore

[Alexey Bakhtin]

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