On Wed, Apr 21, 2021 at 11:54:24AM +0200, Laszlo Ersek wrote:
Hi Brijesh, Tom,
in QEMU's "docs/interop/firmware.json", the @FirmwareFeature enumeration
has a constant called @amd-sev. We should introduce an @amd-sev-es
constant as well, minimally for the following reason:
AMD document #56421 ("SEV-ES Guest-Hypervisor Communication Block
Standardization") revision 1.40 says in "4.6 System Management Mode
(SMM)" that "SMM will not be supported in this version of the
specification". This is reflected in OVMF, so an OVMF binary that's
supposed to run in a SEV-ES guest must be built without "-D
SMM_REQUIRE". (As a consequence, such a binary should be built also
without "-D SECURE_BOOT_ENABLE".)
At the level of "docs/interop/firmware.json", this means that management
applications should be enabled to look for the @amd-sev-es feature (and
it also means, for OS distributors, that any firmware descriptor
exposing @amd-sev-es will currently have to lack all three of:
@requires-smm, @secure-boot, @enrolled-keys).
I have three questions:
(1) According to
<https://libvirt.org/formatdomain.html#launch-security>, SEV-ES is
explicitly requested in the domain XML via setting bit#2 in the "policy"
element.
Can this setting be used by libvirt to look for such a firmware
descriptor that exposes @amd-sev-es?
Hi Laszlo and all,
Currently we use only <launchSecurity type='sev'> when selecting
firmware to make sure that it supports @amd-sev. Since we already have a
place in the VM XML where users can configure amd-sev-as we can use that
information when selecting correct firmware that should be used for the
VM.