[crac] RFR: Reseed secure random on checkpoint restore
Dan Heidinga
duke at openjdk.java.net
Mon Dec 20 15:48:16 UTC 2021
On Fri, 17 Dec 2021 13:38:18 GMT, Alexey Bakhtin <abakhtin 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 176:
> 174: state = digest.digest(seed);
> 175: remCount = 0;
> 176: clearStateOnCheckpoint = false;
I'm not clear on why we need this boolean. Why does the code say not to clear this Random on a checkpoint if someone has called `engineSetSeed`?
src/java.base/share/classes/sun/security/provider/SecureRandom.java line 244:
> 242: if (isSeedGenerator)
> 243: return -12;
> 244: return -11;
How are priorities determined? I see other implementors of this method mostly setting their priority to 0.
-------------
PR: https://git.openjdk.java.net/crac/pull/7
More information about the crac-dev
mailing list