[crac] RFR: Reseed NativePRNG on checkpoint restore

[Alexey Bakhtin]

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