[shortening, there is a small 40K limit on kata-dev]
On 6 Jan 2021, at 19:44, Laszlo Ersek <lersek@redhat.com> wrote:
On 01/06/21 18:35, Christophe de Dinechin wrote:
We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".)
If that's not supposed to work, is there some relatively simple way to warn?
The correct solution would be to remove even the vestigial "-bios" support from OVMF, and then, if you used "-bios" rather than pflash, it would not boot at all.
Which makes me realize... you must not be using the proper OVMF executable in the first place! Because, the one that contains the SMM driver stack, for protecting Secure Boot, indeed does *not* contain the (vestigial) "-bios" support.
So, if you manage to reach the guest kernel in any way (regardless of SEV recognition) after launching OVMF with "-bios", that's evidence that your OVMF executable (OVMF_CODE.fd) is wrong. (As long as you care about Secure Boot at all, that is.)
Interesting. I'm using /usr/share/OVMF/OVMF_CODE.fd on Fedora 33. dnf whatprovides tells me: edk2-ovmf-20200801stable-1.fc33.noarch : Open Virtual Machine Firmware Repo : fedora Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : @System Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : updates Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd Do we need to track this? Is this a bug?
Actually, I'm more interested in the correct way to fix it for Kata.
So I gather that the right approach is - Create a copy of the right OVMF_VARS file - Change the command line to have the correct two -drive options
Yes.
In addition: make sure you use an OVMF executable that was built with the proper flags (specifically: -D SMM_REQUIRE -D SECURE_BOOT_ENABLE). Assuming you want Secure Boot.
... Hm. I guess this ended up more confusing than it should be. OK, let me summarize:
This is actually extremely helpful, as it helps me understand better how the pieces of the puzzle fit together. I'll probably need to read it a few more times after a couple of aspirins, though ;-)
Case#1: You don't care about Secure Boot. Then:
- it's fine to build OVMF without the flags -D SMM_REQUIRE -D SECURE_BOOT_ENABLE
- it's fine to build the X64 OVMF executable
- "-bios" should still not be used; use two pflash chips instead.
(The proper way for that is no longer "-drive" BTW, but blockdevs, and the "pflash0" and "pflash1" machine type properties.)
According to Michal, libvirt is not doing that yet. Is there a doc / BZ / patch that could help me figure out the exact command-line syntax? I have to take compatibility into account: kata runtime cannot restrict itself to the latest qemu.
Case#2: You do care about Secure Boot. Then:
- Build OVMF with the flags -D SMM_REQUIRE -D SECURE_BOOT_ENABLE
This ensures that the Secure Boot *feature* is included in the firmware binary, and that it is protected with SMM emulation (implemented in QEMU and KVM).
- The OVMF executable that you build should be the IA32X64 one (not X64)
- Use two pflash chips as explained above
- On the QEMU command line, the following additional flags are required:
-machine q35 \ -machine smm=on \ -global driver=cfi.pflash01,property=secure,value=on \
- If you want the domain to have the Secure Boot *operating mode* disabled, then create the file that backs the varstore pflash chip by copying "OVMF_VARS.fd". The latter is a logically empty variable store template.
Otherwise, if you want the Secure Boot *operating mode* enabled in the domain, then copy the domain's varstore file from the varstore template called "OVMF_VARS.secboot.fd". The latter has various Microsoft certificates enrolled, and the SB mode enabled.
OK. I would add: Case #3: I don't want to build OVMF myself but rely on the distro's package. Also, I don't know if SEV requires SecureBoot. I imagine it probably does, but I'm not sure. I sent another message involving Connor Kuehl, I'd like to build a mental map of the whole attestation process in the case of SEV.
So, for starters, you need to know where your firmware executable (OVMF_CODE.fd) comes from -- that will tell you whether it even contains the SMM+SB *features*. If the answer is positive, you can consider the SB *operational mode*, which can be influenced by picking the right one of the variable store templates, as the origin for the domain's actual variable store file.
Is there an easy way to know which flags the OVMF_CODE.fd was built with? Thanks a lot for all your help Christophe