[libvirt] [Qemu-devel] libvirt/QEMU/SEV interaction

Brijesh Singh brijesh.singh at amd.com
Sun Oct 1 00:09:10 UTC 2017

On 9/29/17 4:58 PM, Laszlo Ersek wrote:
> The expansion ROMs (containing UEFI drivers) of emulated PCI devices,
> and the same of assigned physical PCI devices, constitute another
> channel through which code enters the guest from the outside (i.e., from
> the Cloud Provider). The ROM BARs from which the guest firmware reads
> the UEFI binaries are not guest RAM, they are MMIO. (For execution, the
> drivers are copied into encrypted guest RAM.)
> If the guest has Secure Boot enabled, then the oproms are verified[*]
> (and not launched if verification fails), but this is slightly different
> from what I understand under audit-by-GO. It means the GO wouldn't get a
> measurement of the oproms for one-by-one clearing, when about to
> green-light a guest startup. Instead the GO would ensure that Secure
> Boot be enabled with the right certificates (and/or executable hashes)
> enrolled off the bat, and then implicitly trust all oprom drivers
> accepted by those certs / hashes. It's another layer of indirection.
> This is likely nothing new qualitatively, but "the devil is in the
> details", so I thought it was worth raising.
> [*] For edk2 / OvmfPkg specifics, I'll mention
>   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
> The SecurityPkg default is 0x04 ("Deny execution when there is security
> violation"). However, OVMF sets it to 0x00 ("Always trust the image").
> Please see the following commit for the reasons:
>   https://github.com/tianocore/edk2/commit/1fea9ddb4e3fd
> Brijesh, for SEV guests, we likely want to flip this PCD to 0x04, in the
> AmdSevInitialize() function, in "OvmfPkg/PlatformPei/AmdSev.c". For that
> we'll also have to change the PCD from fixed-at-build to dynamic, but
> that in turn will require a change to "SecurityPkg.dec" itself
> (currently it only allows fixed-at-build or patchable, not dynamic). Do
> you want me to file a BZ in the TianoCore tracker for this, and assign
> it to you? If you don't have time for writing the patch, I'm glad to do
> it too, but then the review could be slower; both other OvmfPkg
> co-maintainers are busy with other things.)

Very good point Laszlo. Please submit the BZ and assign it me - thank
you. we will take a look at implementing the required support.


More information about the libvir-list mailing list