On Thu, 7 Nov 2019 at 14:44, Laszlo Ersek <ler...@redhat.com> wrote: > > On 11/07/19 13:47, Paolo Bonzini wrote: > > On 07/11/19 12:52, Daniel P. Berrangé wrote: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013 > >> > >> Is it practical to provide a jitter entropy source for EDK2 > >> too ? > > > > The hard part is not collecting jitter (though the firmware might be too > > deterministic for that), but rather turning it into a random number seed > > (mixing data from various sources, crediting entropy, etc.). > > If there is *any* entropy source that (a) we can trust to be random > enough and (b) depends only on the CPU, then we shouldn't struggle with > virtio-rng (or similar devices) at all. RDRAND would be a no-brainer, > but the "community literature" suggests it should not be trusted in itself. > > I've read the commit message linked above, and it appears too good to be > true. > > The CPU Jitter RNG provides a source of good entropy by collecting > CPU executing time jitter. [...] The RNG does not have any > dependencies on any other service in the kernel. The RNG only needs > a high-resolution time stamp. [...] > > http://www.chronox.de/jent.html > > The CPU Jitter Random Number Generator provides a non-physical true > random number generator that works equally in kernel and user land. > The only prerequisite is the availability of a high-resolution timer > that is available in modern CPUs. > > http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html > > Today’s operating systems provide non-physical true random number > generators which are based on hardware events. With the advent of > virtualization and the ever growing need of more high-quality random > numbers, these random number generators reach their limits. > Additional sources of entropy must be opened up. This document > introduces an entropy source based on CPU execution time jitter. The > design and implementation of a non-physical true random number > generator, the CPU Jitter random number generator, its statistical > properties and the maintenance and behavior of entropy is discussed > in this document. > > If this construct is legit, a core edk2 implementation (available to all > platforms, and on all edk2 arches) would be a huge win. >
"that works equally in kernel and user land" Firmware running at boot time on a single core without any serious scheduling or I/O going on is not going to produce any entropy worth mentioning, I'm afraid. And if it does, it is going to delay the boot substantially. > On the other hand, we're having this discussion because the premise of > TianoCore#1871 is that we shouldn't rely on just the CPU and a high > resolution timer... I simply cannot decide if this construct is > trustworthy. (With any solution that was based in the host's /dev/random > or /dev/urandom, the trustworthiness question would be side-stepped in > the firmware.) >