2017-08-11 13:28 GMT+01:00, Laszlo Ersek <ler...@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. _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
