[libvirt] [PATCH 4/5] qemu: Enable secure boot
lersek at redhat.com
Thu Aug 4 14:54:48 UTC 2016
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
>>>>> 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 at redhat.com>
>>>>> 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.
>>> 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.
>> 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:
> 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):
>> <qemu:arg value='-global'/>
>> <qemu:arg value='isa-debugcon.iobase=0x402'/>
>> <qemu:arg value='-debugcon'/>
>> <qemu:arg value='file:/tmp/GUEST_NAME.log'/>
>> 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!
More information about the libvir-list