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.
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.)
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#50228): https://edk2.groups.io/g/devel/message/50228
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
