[vfio-users] OVMF secureboot question.

[Laszlo Ersek]

On 08/11/17 12:50, Hagbard Celine wrote:
> Hi, I used to update at every new version form kraxel.org, but at one
> point I had to stop updating due to secure-boot changes. As far as I
> could see, Q35 was needed for secure-boot on newer versions due to
> i440FX not emulating SMM.
> 
> Today I did a search to see if anything had changed on the i440FX
> front, which it had not, but I fount this mail:
> https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg00942.html
> Wherein the important part for me is the following sub-quote:
> --snip
> OVMF's default upstream build works fine with
> i440fx. But, if you build OVMF with "-D SMM_REQUIRE" -- which is
> required for making "-D SECURE_BOOT_ENABLE" actually secure --,
> --snip
> 
> Does this say that there exits a build that will let me update my OVMF
> and keep i440FX with not-actually-secure secure-boot as with older
> version? If so, where can I download this build?
> 
> The reason I need this is:
> -I got software that needs to believe it runs on a secure-boot environment.
> -If I change to Q35 I get noticeable degraded performance in VM
> -Windows-licensing seriously dislikes having the chipset swapped, one
> time I almost totally lost my licence after changing chipset in Qemu.

Some time after the implementation of SMM in all of KVM, QEMU (q35
only), and OVMF, all of the OVMF builds that I have any connection to
started limiting the Secure Boot feature to builds that also enforced
SMM_REQUIRE. This is because we shouldn't distribute a fw binary any
longer that offers the Secure Boot feature without the means to enforce
its security.

If you consciously want to do this, you can build OVMF from source. Add
-D SECURE_BOOT_ENABLE to the build command line, without adding -D
SMM_REQUIRE. The resultant firmware binary will offer the Secure Boot
software interfaces, and it will run on both i440fx and Q35. However, a
malicious guest OS component will be able to circumvent any Secure Boot
settings, via direct hardware access to the varstore pflash chip, and/or
to the S3 LockBox data structure in normal RAM (if you use S3 within the
guest).

If you decide to build OVMF from source, and have used Kraxel's RPMs
thus far, a caveat: don't forget to add -D FD_SIZE_2MB as well to your
build command line. Upstream OVMF has switched to a 4MB combined flash
size, which is not compatible with preexistent varstore files that were
created for a 2MB combined flash size. (This is another example why the
"nvram" stanza in "/etc/libvirt/qemu.conf" associates firmware binaries
with their matching varstore templates.) So, if you plan to switch over
an existent domain (preserving its current varstore file), then pass -D
FD_SIZE_2MB too.

Thanks,
Laszlo