[vfio-users] OVMF secureboot question.

[Hagbard Celine]

2017-08-11 13:28 GMT+01:00, Laszlo Ersek <lersek at redhat.com>:
> 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).

As I understand varstore pflash is the OVMF_VARS.fd file. Do it's
content change during normal operation of a Windows guest? My idea was
keeping a backup that I diff against the live version, to add a little
more security than I have today.


> 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
>

Got my new OVMF build now, thanks.