[crac] RFR: Reseed secure random on checkpoint restore

[Alexey Bakhtin]

On Thu, 23 Dec 2021 14:07:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
>> Two jtreg tests added: 
>> - verify if no deadlocks introduced by checkpoint/restore
>> - verify if SHA1PRNG is reseeded if created with default embedded seed generator
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 278:
> 
>> 276:     @Override
>> 277:     public void engineNextBytes(byte[] result) {
>> 278:         objLock.lock();
> 
> A minor drawback, the keyword in the method declaration makes the synchronization more explicit. An alternative is to retain the synchronization the on object monitor by e.g.
> 
> 
> private boolean blocked = false;
> 
> public synchronized void engineNextBytes {
>    while (blocked) {
>      this.wait()
>    }
>    ...
> }
> 
> public synchronized void beforeCheckpoint {
>   blocked = true
>   ...
> }
> public synchronized void afterRestore {
>   ...
>   blocked = false;
>   this.notifyAll();
> }
> 
> 
> However, a dedicated ReentrantLock makes the implementation a bit shorter. So, up to you.

Yes, it makes sense. But using Lock object in the beforeCheckpoint() -> afterRestore() methods looks more natural.
Also, in your case, we'll have to check for interruptedException and modify engineSetSeed() accordingly.
If there are no more objections, I would use objLock for synchronization.

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

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