On 6/8/22 20:22, Daniel P. Berrangé wrote: > 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#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. > > 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 Ccing Alex from Linaro, maybe he can help us or direct the question? Ciao, Claudio
