Some questions regarding firmware handling in the qemu driver
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#L5... 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? 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. 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? Regards, Jim
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#L5...
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.
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. -- Andrea Bolognani / Red Hat / Virtualization
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#L5...
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. 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.
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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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#L5...
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
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#L5...
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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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#L5...
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
Hi,
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.
Unlikely. The firmware needs some way to store state (i.e. uefi variables) somewhere where the guest OS can't tamper with it. On x86 SMM mode provides that. Flash can be configured to be writable in SMM mode only, so the guest OS can't change things directly but has to route all update requests through the firmware. The arm architecture has a concept called TrustZone which can as far I know can provide simliar guarantees. Checking upstream edk2 git log finds me this... commit 6b46d77243e02d23ce922803998e01277fe9f399 Author: Supreeth Venkatesh <supreeth.venkatesh@arm.com> Date: Fri Jul 13 23:05:27 2018 +0800 StandaloneMmPkg/Core: Implementation of Standalone MM Core Module. Management Mode (MM) is a generic term used to describe a secure execution environment provided by the CPU and related silicon that is entered when the CPU detects a MMI. For x86 systems, this can be implemented with System Management Mode (SMM). For ARM systems, this can be implemented with TrustZone (TZ). [ ... snip ... ] ... but not much beyond that. So I don't think edk2 has support implemented, and I'm also not sure where we stand with qemu. I suspect it'll be quite a bit of work to get everything going. take care, Gerd
On Tue, Jun 14, 2022 at 03:12:29PM +0200, Gerd Hoffmann wrote:
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.
Unlikely. The firmware needs some way to store state (i.e. uefi variables) somewhere where the guest OS can't tamper with it.
On x86 SMM mode provides that. Flash can be configured to be writable in SMM mode only, so the guest OS can't change things directly but has to route all update requests through the firmware.
The arm architecture has a concept called TrustZone which can as far I know can provide simliar guarantees. Checking upstream edk2 git log finds me this...
commit 6b46d77243e02d23ce922803998e01277fe9f399 Author: Supreeth Venkatesh <supreeth.venkatesh@arm.com> Date: Fri Jul 13 23:05:27 2018 +0800
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure execution environment provided by the CPU and related silicon that is entered when the CPU detects a MMI. For x86 systems, this can be implemented with System Management Mode (SMM). For ARM systems, this can be implemented with TrustZone (TZ). [ ... snip ... ]
... but not much beyond that. So I don't think edk2 has support implemented, and I'm also not sure where we stand with qemu.
I suspect it'll be quite a bit of work to get everything going.
Thanks for the additional information, Gerd! It looks like the only sensible course of action is to keep the current checks in place, effectively preventing the use of secure boot on aarch64, until Someone™ implements TZ support across the stack. -- Andrea Bolognani / Red Hat / Virtualization
On 6/8/22 10:20, 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#L5...
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.
The answer to your first question is yes, although with an unfriendly assert in ovmf ASSERT [ArmCpuDxe] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202202/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1)) I don't know the answer to your second question. I think we agree it is achieved with SMM on x86, but as Daniel mentioned it is arch-specific. I see ARM has the notion of a Management Mode [1], but not sure if that provides all the functionality of SMM. The ARM Server Base Security Guide [2] also notes requirements for UEFI Secure Boot (page 17), although I wonder if any server manufacturers provide that. Regards, Jim [1] https://documentation-service.arm.com/static/5ed11e40ca06a95ce53f905c?token= [2] https://documentation-service.arm.com/static/5fb7e9e5ca04df4095c1d669?token=
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.
BTW, by chance I found an interesting info about aarch64 secureboot from Debian https://wiki.debian.org/SecureBoot "Debian no longer supports UEFI Secure Boot on arm64 systems, as of May 2021. Shim and other EFI programs have always been difficult to build on arm64, compared to x86 platforms. Binutils for amd64 and i386 includes explicit support for creating programs in the PE/COFF binary format that EFI uses, but this has never been added for arm64. In the past, shim developers added some local hacks into the shim package to generate a mostly-compliant PE/COFF EFI binary without this toolchain support, and that seemed to be sufficient for use. Everything seemed to work. However, during the development and testing phase of shim 15.3 and 15.4, we found found significant issues with this approach. New security features needed in shim (SBAT) showed up severe problems with the lack of proper toolchain support. See https://github.com/rhboot/shim/issues/366 for more details. The old hacks around binutils are no longer sustainable. " Having said that I find Fedora does still buld shim 15.4 for aarch64. We only exclude 32-bit, and I think RHEL does the same. Whether anyone's tested SecureBoot on aarch64 in Fedora/RHEL though, I'm not so sure. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hi,
Having said that I find Fedora does still buld shim 15.4 for aarch64. We only exclude 32-bit, and I think RHEL does the same. Whether anyone's tested SecureBoot on aarch64 in Fedora/RHEL though, I'm not so sure.
Well, at least the fedora shim builds are not signed with anything, and grub doesn't look much better: $ pesigcheck -v -i grubaa64.efi [ ... ] Signature has impossible time constraint: 1639158862 <= 1373397163 Peer's Certificate has expired. [ ... ] $ date --date @1373397163 Tue Jul 9 21:12:43 CEST 2013 ^^^^ I think we can take that as clear indication that nobody ever tested secure boot with fedora on aarch64 ;) take care, Gerd
Hi,
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.
Well, 'less secure' is an *ahem* interesting way to frame it. It's not secure at all. The guest OS can go ahead modify uefi variables in flash directly, and the firmware can't stop it. It's possible to use a build without SMM support for niche use cases, for example for test setups verifying the secure boot certificate checking, where broken security isn't much of a problem. That actually was useful before x86 got SMM support, now there is little reason to do that. take care, Gerd
On 6/14/22 07:35, Gerd Hoffmann wrote:
Hi,
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.
Well, 'less secure' is an *ahem* interesting way to frame it. It's not secure at all. The guest OS can go ahead modify uefi variables in flash directly, and the firmware can't stop it.
Understood. Thanks for the clarification and thanks for sharing your knowledge throughout this thread! Regards, Jim
participants (5)
-
Andrea Bolognani -
Claudio Fontana -
Daniel P. Berrangé -
Gerd Hoffmann -
Jim Fehlig