On 6/8/22 10:28, Daniel P. Berrangé wrote:
On Wed, Jun 08, 2022 at 12:20:20PM -0400, Andrea Bolognani wrote:
On Tue, Jun 07, 2022 at 02:57:17PM -0600, Jim Fehlig wrote:
Hi All,
I received a bug report (private, sorry) about inability to "deploy uefi
virtual machine with secureboot enabled on aarch64 kvm host". Indeed the
qemu driver has some checks that would prohibit using secure boot with
aarch64 virt machines, e.g.
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_validate.c#L571
However it appears qemu does not restrict booting a firmware with keys
enrolled and secure boot enabled. E.g.
qemu-system-aarch64 -m 4096 -cpu host -accel kvm -smp 4 -M virt -drive if=pflash,format=raw,readonly=on,file=/usr/share/qemu/aavmf-aarch64-opensuse-code.bin
-drive
if=pflash,format=raw,file=/vm_images/jim/images/test/test-vars-store.bin ...
seems to work fine and within the guest I see db keys loaded by kernel
[ 4.782777] integrity: Loading X.509 certificate: UEFI:db
[ 4.789494] integrity: Loaded X.509 cert 'Build time autogenerated kernel
key: 44e3470bd0c5eb190e3292dfc42db061521184ee'
[ 4.789548] integrity: Loading X.509 certificate: UEFI:db
[ 4.789701] integrity: Loaded X.509 cert 'openSUSE Secure Boot Signkey:
0332fa9cbf0d88bf21924b0de82a09a54d5defc8'
[ 4.789710] integrity: Loading X.509 certificate: UEFI:db
[ 4.789841] integrity: Loaded X.509 cert 'SUSE Linux Enterprise Secure
Boot Signkey: 3fb077b6cebc6ff2522e1c148c57c777c788e3e7'
Can we consider easing the secure boot restrictions in qemuValidateDomainDefBoot?
Will such a configuration refuse to boot an unsigned guest OS? Is it
reasonably tamper-proof (see below)? If the answer to both of these
question is yes, then relaxing the check sounds reasonable.
Experimenting with the behavior on x86 raised other questions:
libvirt requires the firmware to support SMM to enable secure boot. But is
SMM a strict requirement for secure boot? IIUC, lack of SMM makes the
securely booted stack less secure since it is easier to tamper with it, but
it does not prevent securely booting the components.
I've been looking into this recently with the help of a colleague
who's way more knowledgeable about the topic than I could possibly
ever be and the short explanation is that, if you don't have SMM
enabled and the loader marked as secure, then the guest OS will be
able to modify the chain of trust stored in NVRAM, thus defeating the
purpose of enabling secure boot in the first place.
I don't think we should relax these requirements, as doing so has the
potential to lure users into a false sense of security.
Note SMM is a x86 specific concept. I agree we shouldn't remove that
rule for x86, because that makes SecureBoot as robust as a chocolate
teapot.
Ok, got it :-).
Jim started by talking about aarch64 though, and there's no SSM concept
there. In fact everything in qemuValidateDomainDefBoot is entirely
x86 specific right now wrt secure boot. So this method will definitely
need work for aarch64.
Agreed, it's just not clear to me how at this point. Without similar SMM
protection of the chain of trust, it seems pointless to support secure boot in
libvirt.
When selecting firmwares manually and marking the loader secure, VM creation
fails unless SMM is explicitly set in <features>. E.g. the following will
fail with "unsupported configuration: Secure boot requires SMM feature
enabled"
<os>
<type arch="x86_64" machine="q35">hvm</type>
<loader readonly="yes" secure="yes"
type="pflash">/usr/share/qemu/ovmf-x86_64-smm-code.bin</loader>
<nvram template="/usr/share/qemu/ovmf-x86_64-smm-vars.bin"/>
<boot dev="hd"/>
</os>
even though the descriptor file for /usr/share/qemu/ovmf-x86_64-smm-code.bin
advertises secure-boot and requires-smm. Is this just a case of trying to
mix old style explicit firmware selection vs firmware auto-select? I.e., if
selecting the firmware explicitly, the onus is on the user to also specify
any related and required config?
The manual firmware selection interface is too complex to be
reasonably useful to regular users, so I think it's fair to consider
it a development tool / legacy interface at this point. Anyone who's
not a libvirt or firmware developer should really use the
feature-based firmware selection interface instead.
I have a couple of improvements to the automatic firmware selection
feature and the corresponding documentation in mind. Hopefully I'll
get around to post patches over the next few days.
To expand on this, if you're using auto-selection it should all
"just work".
If you are not using auto-selection, then the *only* thing that
the firmware descriptors are used for is to locate a template
for the variables file. Anything else is ignored, as the user
is considered to have said they want todo things manually. This
is why the 'requires-smm' flag has no effect in Jim's example
above.
Thanks you both for clarifying the expectation with manual selection.
Regards,
Jim
