[libvirt] [PATCH 4/5] qemu: Enable secure boot

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