Open Stack

On 01/06/21 18:35, Christophe de Dinechin wrote:
> 
> 
>> On 6 Jan 2021, at 18:07, Laszlo Ersek <lersek at 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