[crac] RFR: Reseed NativePRNG on checkpoint restore [v2]

[Anton Kozlov]

On Fri, 24 Dec 2021 14:38:33 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> 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)

Without the debug option, the image may be compromised -- so there should be no option of running without the checks. The currently employed ReentrantReadWriteLock does not block taking Read lock (access to PRNG) while holding Write lock (that is supposed to block access to the PRNG during checkpoint/restore -- but not from the same thread). It would be much more useful to throw an exception "the image is going to be wrong", or at worst to deadlock. But now the implementation does guarantee the security of the image.

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/locks/ReentrantReadWriteLock.html

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

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