On 01/06/21 18:35, Christophe de Dinechin wrote:
On 6 Jan 2021, at 18:07, Laszlo Ersek <lersek@redhat.com> wrote:
Hi Christophe!
On 01/06/21 16:11, Christophe de Dinechin wrote:
Hello Laszlo,
Happy New Year!
Same to you :)
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
1) Is it OK to pass an OVMF firmware to the -boot option of qemu? What about SecureBoot in that case?
2) Are there any expected behavioral differences between booting with the -bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
3) Knowing that in the Kata case, we don't care about anything persisting across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
"-bios" should never be used with OVMF. If you don't need non-volatile UEFI variables to persist from one boot of the domain to the next, that's fine; in that case, please use a throw-away regular file for the variable store pflash chip. this file should be instantiated from "OVMF_VARS.fd", if you don't want the Secure Boot operational mode enabled right off the bat; otherwise, please copy (create) the domain's varstore from "OVMF_VARS.secboot.fd", before launching QEMU.
OK. Need to figure out how we package that image for Kata.
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.)
Right now, while all the doc I saw about
The particulars of a SEV failure, when using "-bios", aren't even worth investigating -- please try to reproduce the issue first with two pflash chips.
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: 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.) 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. 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. Thanks Laszlo