[crac] RFR: Reseed NativePRNG on checkpoint restore

Alexey Bakhtin abakhtin at openjdk.java.net
Fri Dec 24 21:03:37 UTC 2021


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)
The only problem is performance. `INSTANCE` is a single object. So, locking the whole  `implNextBytes` method will affect performance dramatically. I think It can be fixed by `ReentrantReadWriteLock`. Will update implementation

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

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


More information about the crac-dev mailing list