Re: Some questions regarding firmware handling in the qemu driver

On Wed, Jun 08, 2022 at 11:46:43AM -0600, Jim Fehlig wrote: > 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... >>>> >>>> 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. I think we need an ARM expert to explain the rules about SecureBoot on aarch64. Given SMM doesn't exist outside x86, it may be fine to just enable secureboot unconditionally on aarch64 and have it be genuinely secure. I simply don't know enough in this respect. With regards, Daniel