Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash

[Paolo Bonzini <pbonzini@redhat.com>]

On 08/03/2016 13:50, Ard Biesheuvel wrote:
> Note that, for KVM, it is unlikely that we will ever support all of
> this inside the guest. It makes *much* more sense to lock down the
> emulated flash, and implement the UEFI Runtime Services using a thin
> layer in UEFI that hooks up to interfaces exposed to the guest by
> QEMU.

Well, it makes a bit less sense if the SMM code is already there for you
to use. :)  More seriously, implementing secure boot on x86 KVM was
"just" a matter of reading the architecture manual and chipset
datasheets, and implementing what they said.  Likewise, the firmware
work can reuse a large part of the work done for bare-metal hardware.
Laszlo would kill me for saying this, :) but in terms of sheer SLOC his
platform enablement patches were dwarfed by the SMM code that Intel
contributed.  The SMM code in turn is _exactly_ the same on bare-metal
and virt.

Designing good PV interfaces is hard, designing secure PV interfaces is
harder; reading a spec is easy.  To me, the only reason to do it in PV
interfaces is that the hardware doesn't allow virtualization of EL3.

If the hardware makes you jump through extra hoops, sometimes it's
necessary, sometimes it's not.  If it's not, rationalizing it is bad.  I
cannot think of a good reason for hardware not to let you virtualize
hypervisor or secure mode, or to force the hypervisor to use two-level
page translation.

Paolo