Really Fixing Getrandom()
My response to Linus:<p>I&#x27;m OK with this as a starting point.  If a jitter entropy system allow us to get pass this logjam, let&#x27;s do it.  At least for the x86 architecture, it will be security through obscurity.  And if the alternative is potentially failing where the adversary can attack the CRNG, it&#x27;s my preference.  It&#x27;s certainly better than nothing, in that in that very worst case, &quot;security through obscurity&quot; is better than &quot;don&#x27;t block, because blocking is always worse than an guessable value being returned through getrandom(0)&quot;.  And so if these are the only two options, I&#x27;m certainly going to choose the former.<p>That being said, I&#x27;m still very worried that people with deep access to the implementation details of a CPU might be able to reverse engineer what a jitter entropy scheme produces.  For that reason, I&#x27;d very much like to see someone do an analysis of how well these jitter schemes work on an open, simple architecture such as an RISC-V iplementation (you know, the ones that were so simplistic and didn&#x27;t have any speculation so they weren&#x27;t vulnerable to Specture&#x2F;Meltdown).  If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA.<p>In the long term (not in time for the 5.4 merge window), I&#x27;m convinced that we should be trying as many ways of getting entropy as possible.  If we&#x27;re using UEFI, we should be trying to get it from UEFI&#x27;s secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on.<p>After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn&#x27;t problem in practice.  We need to get back to that place where in practice, we&#x27;ve harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security.<p>(The above is a lightly edited almagamation of <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;r&#x2F;20190930033706.GD4994@mit.edu" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;r&#x2F;20190930033706.GD4994@mit.edu</a> and <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;r&#x2F;20190930131639.GF4994@mit.edu" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;r&#x2F;20190930131639.GF4994@mit.edu</a>)