[crac] RFR: Reseed secure random on checkpoint restore [v3]

[Alexey Bakhtin]

On Thu, 13 Jan 2022 16:30:08 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Set JDKResource priorities for SecureRandom
>>  - Merge branch 'crac' of https://github.com/openjdk/crac into SecureRandom
>>  - Add separate JDKResorce for seeder
>>  - Reseed secure random on checkpoint restore
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 261:
> 
>> 259:         @Override
>> 260:         public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
>> 261:             objLock.lock();
> 
> Do we assume a special state of seeder? A comment is really needed. This lock is not acquired anywhere else, i.e. it does not guard access to the static `seeder` field. The field can be referenced by a SecureRandom object that was created after Priority.SECURE_RANDOM was handled (the new SecureRandom was not notified about checkpoint -- there is no problem unless the new SecureRandom catches some state). If seeder has built-in protection and will block the new SecureRandom, the lock is not necessary. If not, seeder needs to be guarded. In the latter case, it should probably be a ReadWriteLock as in #9.

Thank you. I've added verification if PRNG object is already locked during checkpoint/restore. In this case, CheckpointException will be thrown. In other cases the object will be locked until checkpoint/restore is completed

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

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