[crac] RFR: Reseed NativePRNG on checkpoint restore [v3]

[Alexey Bakhtin]

On Thu, 13 Jan 2022 04:47:55 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> For 2. I think it is just a matter of JDKResource.Priority. The use case you described is about dependent resources (see https://github.com/openjdk/crac/pull/8). In this case, the priority of the NativePRNG should be adjusted in the JDKResource.Priority.
>> Also, I would suggest adding a debug option that enables detection of the incorrect usage of the JDKResource A inside beforeCheckpoint of JDKResource B (priority A > priority B)
>
> Without the debug option, the image may be compromised -- so there should be no option of running without the checks. The currently employed ReentrantReadWriteLock does not block taking Read lock (access to PRNG) while holding Write lock (that is supposed to block access to the PRNG during checkpoint/restore -- but not from the same thread). It would be much more useful to throw an exception "the image is going to be wrong", or at worst to deadlock. But now the implementation does guarantee the security of the image.
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/locks/ReentrantReadWriteLock.html

Thank you. Added the code to verify if NativePRNG is used from the beforeCheckpoint/afterRestore. In such a case, CheckpointException will be thrown.

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

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