privileged entropy sources in QEMU/KVM guests

[Laszlo Ersek]

Hi,

related TianoCore BZ:

  https://bugzilla.tianocore.org/show_bug.cgi?id=1871

(I'm starting this thread separately because at least some of the topics
are specific to QEMU, and I didn't want to litter the BZ with a
discussion that may not be interesting to all participants CC'd on the
BZ. I am keeping people CC'd on this initial posting; please speak up if
you'd like to be dropped from the email thread.)

QEMU provides guests with the virtio-rng device, and the OVMF and
ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that
device. But, that doesn't seem enough for all edk2 use cases.

Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its
absence may affect some other use cases.


(1) For UEFI HTTPS boot, TLS would likely benefit from good quality
entropy. If the VM config includes virtio-rng (hence the guest firmware
has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.

However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
UEFI HTTPS boot be disabled completely (or prevented / rejected
somehow), blaming lack of good entropy? Or should TLS silently fall back
to "mixing some counters [such as TSC] together and applying a
deterministic cryptographic transformation"?

IOW, knowing that the TLS setup may not be based on good quality
entropy, should we allow related firmware services to "degrade silently"
(not functionally, but potentially in security), or should we deny the
services altogether?


(2) It looks like the SMM driver implementing the privileged part of the
UEFI variable runtime service could need access to good quality entropy,
while running in SMM; in the future.

This looks problematic on QEMU. Entropy is a valuable resource, and
whatever resource SMM drivers depend on, should not be possible for e.g.
a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
Therefore, it's not *only* the case that SMM drivers must not consume
EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
outside of SMM/SMRAM), but also that SMM drivers must not depend on the
same piece of *hardware* that feeds EFI_RNG_PROTOCOL.

Furthermore, assuming we dedicate a hardware entropy device specifically
to SMM drivers, such a device cannot be PCI(e). It would have to be a
platform device at a fixed location (IO port or MMIO) that is only
accessible to such guest code that executes in SMM. IOW, device access
would have to be restricted similarly to pflash. (In fact the variable
SMM driver will need, AIUI, the entropy for encrypting various variable
contents, which are then written into pflash.)

Alternatively, CPU instructions could exist that return entropy, and are
executable only inside SMM. It seems that e.g. RDRAND can be trapped in
guests ("A VMEXIT due to RDRAND will have exit reason 57 (decimal)").
Then KVM / QEMU could provide any particular implementation we wanted --
for example an exception could be injected unless RDRAND had been
executed from within SMM. Unfortunately, such an arbitrary restriction
(of RDRAND to SMM) would diverge from the Intel SDM, and would likely
break other (non-SMM) guest code.

Does a platform device that is dynamically detectable and usable in SMM
only seem like an acceptable design for QEMU?

Thanks,
Laszlo