On 08/04/16 16:39, Pavel Hrdina wrote: > On Thu, Aug 04, 2016 at 03:45:39PM +0200, Laszlo Ersek wrote: >> On 08/04/16 15:14, Pavel Hrdina wrote: >>> On Wed, Jul 27, 2016 at 05:11:59PM +0200, Laszlo Ersek wrote: >>>> On 07/27/16 10:43, Michal Privoznik wrote: >>>>> In qemu, enabling this feature boils down to adding the following >>>>> onto the command line: >>>>> >>>>> -global driver=cfi.pflash01,property=secure,value=on >>>>> >>>>> However, there are some constraints resulting from the >>>>> implementation. For instance, System Management Mode (SMM) is >>>>> required to be enabled, the machine type must be q35-2.5 or >>> >>> s/q35-2.5/q35-2.4/ >>> >>>>> later, and the guest should be x86_64. While technically it is >>>>> possible to have 32 bit guests with secure boot, some non-trivial >>>>> CPU flags tuning is required (for instance lm and nx flags must >>>>> be prohibited). Given complexity of our CPU driver, this is not >>>>> trivial. Therefore I've chosen to forbid 32 bit guests for now. >>>>> If there's ever need, we can refine the check later. >>>>> >>>>> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >>>>> --- >>>>> src/qemu/qemu_command.c | 7 ++++++ >>>>> src/qemu/qemu_domain.c | 27 ++++++++++++++++++++ >>>>> .../qemuxml2argv-bios-nvram-secure.args | 29 ++++++++++++++++++++++ >>>>> tests/qemuxml2argvtest.c | 7 ++++++ >>>>> 4 files changed, 70 insertions(+) >>>>> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-bios-nvram-secure.args >>>> >>>> This patch looks almost complete to me (it causes all necessary QEMU >>>> options to appear, directly or indirectly (= via requiring SMM)). >>>> However, can you also enforce that the Q35 machtype has version 2.5 or >>>> later? Technically, "pc-q35-2.4" exists too, and it's not good enough >>>> (according to the instructions I wrote up in OvmfPkg/README earlier). I >>>> certainly never tested it. >>>> >>>> Thanks, >>>> Laszlo >>> >>> I've tested it and it seems to work also with "pc-q35-2.4". I've installed >>> Fedora 24 inside a guest and I can see "Secure boot enabled" in dmesg output. >>> Unless Laszlo has some more information about secure boot and why it shouldn't >>> work with "pc-q35-2.4" this patch can be pushed as is. >>> >>> ACK >>> >> >> The Secure Boot feature and the SMM driver stack are orthogonal >> build-time options in OVMF. You may enable both, you may enable neither, >> and you may enable only one of them as well. >> >> However, the Secure Boot feature is not actually secure without the SMM >> driver stack. Meaning, the software interfaces that relate to Secure >> Boot will be available, and -- once certificates have been enrolled -- a >> "well behaved" guest will see Secure Boot enabled. However, a malicious >> guest can directly tamper with the pflash chip that stores the >> authenticated UEFI variables. In other words, without the SMM driver >> stack, a malicious guest can subvert / circumvent Secure Boot. >> >> Therefore, for "production environments", it makes sense to refer *only* >> to the combination >> >> Secure Boot Feature + SMM Driver Stack >> >> as "secure". This is the meaning of "secure" that you can see in the >> commit messages and the new XML tags here. >> >> Therefore, whether or not your test results provide actual information, >> depends on the following question: did your OVMF build include the SMM >> Driver Stack *as well*, or only the Secure Boot feature? >> >> Because, if solely the latter was built into your OVMF binary, that >> would suffice for the >> >> Secure boot enabled >> >> message to appear in the guest dmesg. >> >> However, per se the message doesn't prove that the SMM driver stack was >> built into the binary. Consequently, the message also doesn't prove that >> pc-q35-2.4 provides everything that's needed for SMM. >> >> Where did you get your OVMF binary? > > I have two OVMF binaries, one from Fedora 24 rpm package: > > edk2-ovmf-20160418gita8c39ba-4.fc24.noarch.rpm > > and the second one I've built myself from upstream edk2 repository using > > "./build.sh -a X64 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc -D SECURE_BOOT_ENABLE -D SMM_REQUIRE" > >> ... If you want to verify the presence of the SMM driver stack, please >> add the following to your domain XML (note the QEMU namespace >> declaration in the root element): >> >> <domain >> type='kvm' >> xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0' >> > >> [...] >> >> <qemu:commandline> >> <qemu:arg value='-global'/> >> <qemu:arg value='isa-debugcon.iobase=0x402'/> >> <qemu:arg value='-debugcon'/> >> <qemu:arg value='file:/tmp/GUEST_NAME.log'/> >> </qemu:commandline> >> </domain> >> >> Then look for the following string in /tmp/GUEST_NAME.log: >> >> SMM CPU Module exit from SMRAM with EFI_SUCCESS >> >> If you see it, your OVMF binary contains the SMM driver stack, and then >> the message in the dmesg is meaningful as evidence. If you don't see it, >> then the message in the dmesg is worthless, as evidence for pc-q35-2.4. > > I'm using upstream qemu 2.6.0 and with the OVMF binary from Fedora 24 package > called "OVMF_CODE.secboot.fd" and machine type "pc-q35-2.4" I'm able to see that > line in that log file and also "Secure boot enabled" in dmesg log. > > The line "SMM CPU Module exit from SMRAM with EFI_SUCCESS" is also in that log > file with the built OVMF binary. > > So based on the testing with OVMF binary from the fedora package it should be > good enough to use also "pc-q35-2.4". Thank you for confirming! Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list