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