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

Anton Kozlov akozlov at openjdk.java.net
Fri Jan 21 15:00:25 UTC 2022

On Tue, 18 Jan 2022 15:46:41 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

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

The CheckpointException does not look like a perfect exception here. To avoid controversial requirements, could it be RuntimeException or another unchecked exception, like e.g. IllegalStateException?


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

More information about the crac-dev mailing list