Open Stack

[shortening, there is a small 40K limit on kata-dev]

> On 6 Jan 2021, at 19:44, Laszlo Ersek <lersek at 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