21.09.2019 00:51, Linus Torvalds пишет:
And we'll also have to make getrandom(0) be really _timely_. Security people would likely rather wait for minutes before they are happy with it. But because it's a boot constraint as things are now, it will not just be jitter-entropy, it will be _accelerated_ jitter-entropy in 15 seconds or whatever, and since it can't use up all of CPU time, it's realistically more like "15 second timeout, but less of actual CPU time for jitter".
I don't think that "accelerated jitter" makes sense. The jitterentropy hwrng that I sent earlier fills the entropy buffer in less than 2 seconds, even with quality=4, so there is no need to accelerate it even more.
That said, if we can all convince everybody (hah!) that jitter entropy in the kernel would be sufficient, then we can make the whole point entirely moot, and just say "we'll just change crng_wait() to do jitter entropy instead and be done with it. Then any getrandom() user will just basically wait for a (very limited) time and the system will be happy. If that is the case we wouldn't need new flags at all. But I don't think you can make everybody agree to that, which is why I suspect we'll need the new flag, and I'll just take the heat for saying "0 is now off limits, because it does this thing that a lot of people dislike".
I 100% agree with that. -- Alexander E. Patrakov
Attachment:
smime.p7s
Description: Криптографическая подпись S/MIME
