Hello Laszlo,
Happy New Year!
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
1) Is it OK to pass an OVMF firmware to the -boot option of qemu? What about SecureBoot in that case?
2) Are there any expected behavioral differences between booting with the -bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
3) Knowing that in the Kata case, we don't care about anything persisting across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
Thanks!
-- Cheers, Christophe de Dinechin (IRC c3d)
Hi Christophe!
On 01/06/21 16:11, Christophe de Dinechin wrote:
Hello Laszlo,
Happy New Year!
Same to you :)
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
Is it OK to pass an OVMF firmware to the -boot option of qemu? What about SecureBoot in that case?
Are there any expected behavioral differences between booting with the -bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
Knowing that in the Kata case, we don't care about anything persisting across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
"-bios" should never be used with OVMF. If you don't need non-volatile UEFI variables to persist from one boot of the domain to the next, that's fine; in that case, please use a throw-away regular file for the variable store pflash chip. this file should be instantiated from "OVMF_VARS.fd", if you don't want the Secure Boot operational mode enabled right off the bat; otherwise, please copy (create) the domain's varstore from "OVMF_VARS.secboot.fd", before launching QEMU.
We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".)
The particulars of a SEV failure, when using "-bios", aren't even worth investigating -- please try to reproduce the issue first with two pflash chips.
Thanks! Laszlo
On 6 Jan 2021, at 18:07, Laszlo Ersek lersek@redhat.com wrote:
Hi Christophe!
On 01/06/21 16:11, Christophe de Dinechin wrote:
Hello Laszlo,
Happy New Year!
Same to you :)
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
- Is it OK to pass an OVMF firmware to the -boot option of qemu?
What about SecureBoot in that case?
- Are there any expected behavioral differences between booting with the
-bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
- Knowing that in the Kata case, we don't care about anything persisting
across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
"-bios" should never be used with OVMF. If you don't need non-volatile UEFI variables to persist from one boot of the domain to the next, that's fine; in that case, please use a throw-away regular file for the variable store pflash chip. this file should be instantiated from "OVMF_VARS.fd", if you don't want the Secure Boot operational mode enabled right off the bat; otherwise, please copy (create) the domain's varstore from "OVMF_VARS.secboot.fd", before launching QEMU.
OK. Need to figure out how we package that image for Kata.
We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".)
If that's not supposed to work, is there some relatively simple way to warn? Right now, while all the doc I saw about
The particulars of a SEV failure, when using "-bios", aren't even worth investigating -- please try to reproduce the issue first with two pflash chips.
Actually, I'm more interested in the correct way to fix it for Kata.
So I gather that the right approach is - Create a copy of the right OVMF_VARS file - Change the command line to have the correct two -drive options
Will do that.
Thanks a lot, Christophe
On 01/06/21 18:35, Christophe de Dinechin wrote:
On 6 Jan 2021, at 18:07, Laszlo Ersek lersek@redhat.com wrote:
Hi Christophe!
On 01/06/21 16:11, Christophe de Dinechin wrote:
Hello Laszlo,
Happy New Year!
Same to you :)
I may need to pick your brain a little regarding an issue someone testing AMD SEV ran into with Kata.
Basically, here are the questions I have:
- Is it OK to pass an OVMF firmware to the -boot option of qemu?
What about SecureBoot in that case?
- Are there any expected behavioral differences between booting with the
-bios option and using a -drive if=pflash option? In particular, anything that could prevent SEV from activating in the guest kernel?
- Knowing that in the Kata case, we don't care about anything persisting
across reboots, is there any problem passing only the OVMF_CODE.fd image readonly using the -drive option, without having an OVMF_VARS.fd? Asking to see if we need to create an OVMF_VARS.fd for each container.
If you need a bit of context: https://github.com/kata-containers/kata-containers/issues/1231 and http://lists.katacontainers.io/pipermail/kata-dev/2021-January/001638.html
"-bios" should never be used with OVMF. If you don't need non-volatile UEFI variables to persist from one boot of the domain to the next, that's fine; in that case, please use a throw-away regular file for the variable store pflash chip. this file should be instantiated from "OVMF_VARS.fd", if you don't want the Secure Boot operational mode enabled right off the bat; otherwise, please copy (create) the domain's varstore from "OVMF_VARS.secboot.fd", before launching QEMU.
OK. Need to figure out how we package that image for Kata.
We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".)
If that's not supposed to work, is there some relatively simple way to warn?
The correct solution would be to remove even the vestigial "-bios" support from OVMF, and then, if you used "-bios" rather than pflash, it would not boot at all.
Which makes me realize... you must not be using the proper OVMF executable in the first place! Because, the one that contains the SMM driver stack, for protecting Secure Boot, indeed does *not* contain the (vestigial) "-bios" support.
So, if you manage to reach the guest kernel in any way (regardless of SEV recognition) after launching OVMF with "-bios", that's evidence that your OVMF executable (OVMF_CODE.fd) is wrong. (As long as you care about Secure Boot at all, that is.)
Right now, while all the doc I saw about
The particulars of a SEV failure, when using "-bios", aren't even worth investigating -- please try to reproduce the issue first with two pflash chips.
Actually, I'm more interested in the correct way to fix it for Kata.
So I gather that the right approach is
- Create a copy of the right OVMF_VARS file
- Change the command line to have the correct two -drive options
Yes.
In addition: make sure you use an OVMF executable that was built with the proper flags (specifically: -D SMM_REQUIRE -D SECURE_BOOT_ENABLE). Assuming you want Secure Boot.
... Hm. I guess this ended up more confusing than it should be. OK, let me summarize:
Case#1: You don't care about Secure Boot. Then:
- it's fine to build OVMF without the flags -D SMM_REQUIRE -D SECURE_BOOT_ENABLE
- it's fine to build the X64 OVMF executable
- "-bios" should still not be used; use two pflash chips instead.
(The proper way for that is no longer "-drive" BTW, but blockdevs, and the "pflash0" and "pflash1" machine type properties.)
Case#2: You do care about Secure Boot. Then:
- Build OVMF with the flags -D SMM_REQUIRE -D SECURE_BOOT_ENABLE
This ensures that the Secure Boot *feature* is included in the firmware binary, and that it is protected with SMM emulation (implemented in QEMU and KVM).
- The OVMF executable that you build should be the IA32X64 one (not X64)
- Use two pflash chips as explained above
- On the QEMU command line, the following additional flags are required:
-machine q35 \ -machine smm=on \ -global driver=cfi.pflash01,property=secure,value=on \
- If you want the domain to have the Secure Boot *operating mode* disabled, then create the file that backs the varstore pflash chip by copying "OVMF_VARS.fd". The latter is a logically empty variable store template.
Otherwise, if you want the Secure Boot *operating mode* enabled in the domain, then copy the domain's varstore file from the varstore template called "OVMF_VARS.secboot.fd". The latter has various Microsoft certificates enrolled, and the SB mode enabled.
So, for starters, you need to know where your firmware executable (OVMF_CODE.fd) comes from -- that will tell you whether it even contains the SMM+SB *features*. If the answer is positive, you can consider the SB *operational mode*, which can be influenced by picking the right one of the variable store templates, as the origin for the domain's actual variable store file.
Thanks Laszlo
[shortening, there is a small 40K limit on kata-dev]
On 6 Jan 2021, at 19:44, Laszlo Ersek lersek@redhat.com wrote:
On 01/06/21 18:35, Christophe de Dinechin wrote:
We have never tested SEV with "-bios" (well, because "-bios" is wrong to use with OVMF in the first place, regardless of SEV); and yes there have been SEV-related changes, specific to the flash driver in OVMF. (QEMU too received SEV-related changes around the parts responsible for loading OVMF, in "hw/i386/pc_sysfw.c".)
If that's not supposed to work, is there some relatively simple way to warn?
The correct solution would be to remove even the vestigial "-bios" support from OVMF, and then, if you used "-bios" rather than pflash, it would not boot at all.
Which makes me realize... you must not be using the proper OVMF executable in the first place! Because, the one that contains the SMM driver stack, for protecting Secure Boot, indeed does *not* contain the (vestigial) "-bios" support.
So, if you manage to reach the guest kernel in any way (regardless of SEV recognition) after launching OVMF with "-bios", that's evidence that your OVMF executable (OVMF_CODE.fd) is wrong. (As long as you care about Secure Boot at all, that is.)
Interesting. I'm using /usr/share/OVMF/OVMF_CODE.fd on Fedora 33.
dnf whatprovides tells me:
edk2-ovmf-20200801stable-1.fc33.noarch : Open Virtual Machine Firmware Repo : fedora Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : @System Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : copr:copr.fedorainfracloud.org:group_virtmaint-sig:virt-preview Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
edk2-ovmf-20200801stable-3.fc33.noarch : Open Virtual Machine Firmware Repo : updates Matched from: Filename : /usr/share/OVMF/OVMF_CODE.fd
Do we need to track this? Is this a bug?
Actually, I'm more interested in the correct way to fix it for Kata.
So I gather that the right approach is
- Create a copy of the right OVMF_VARS file
- Change the command line to have the correct two -drive options
Yes.
In addition: make sure you use an OVMF executable that was built with the proper flags (specifically: -D SMM_REQUIRE -D SECURE_BOOT_ENABLE). Assuming you want Secure Boot.
... Hm. I guess this ended up more confusing than it should be. OK, let me summarize:
This is actually extremely helpful, as it helps me understand better how the pieces of the puzzle fit together. I'll probably need to read it a few more times after a couple of aspirins, though ;-)
Case#1: You don't care about Secure Boot. Then:
- it's fine to build OVMF without the flags
-D SMM_REQUIRE -D SECURE_BOOT_ENABLE
it's fine to build the X64 OVMF executable
"-bios" should still not be used; use two pflash chips instead.
(The proper way for that is no longer "-drive" BTW, but blockdevs, and the "pflash0" and "pflash1" machine type properties.)
According to Michal, libvirt is not doing that yet.
Is there a doc / BZ / patch that could help me figure out the exact command-line syntax?
I have to take compatibility into account: kata runtime cannot restrict itself to the latest qemu.
Case#2: You do care about Secure Boot. Then:
- Build OVMF with the flags
-D SMM_REQUIRE -D SECURE_BOOT_ENABLE
This ensures that the Secure Boot *feature* is included in the firmware binary, and that it is protected with SMM emulation (implemented in QEMU and KVM).
The OVMF executable that you build should be the IA32X64 one (not X64)
Use two pflash chips as explained above
On the QEMU command line, the following additional flags are required:
-machine q35 \ -machine smm=on \ -global driver=cfi.pflash01,property=secure,value=on \
- If you want the domain to have the Secure Boot *operating mode*
disabled, then create the file that backs the varstore pflash chip by copying "OVMF_VARS.fd". The latter is a logically empty variable store template.
Otherwise, if you want the Secure Boot *operating mode* enabled in the domain, then copy the domain's varstore file from the varstore template called "OVMF_VARS.secboot.fd". The latter has various Microsoft certificates enrolled, and the SB mode enabled.
OK.
I would add:
Case #3: I don't want to build OVMF myself but rely on the distro's package.
Also, I don't know if SEV requires SecureBoot. I imagine it probably does, but I'm not sure. I sent another message involving Connor Kuehl, I'd like to build a mental map of the whole attestation process in the case of SEV.
So, for starters, you need to know where your firmware executable (OVMF_CODE.fd) comes from -- that will tell you whether it even contains the SMM+SB *features*. If the answer is positive, you can consider the SB *operational mode*, which can be influenced by picking the right one of the variable store templates, as the origin for the domain's actual variable store file.
Is there an easy way to know which flags the OVMF_CODE.fd was built with?
Thanks a lot for all your help Christophe
(Adding James, David, Daniel)
On 01/07/21 09:30, Christophe de Dinechin wrote:
On 6 Jan 2021, at 19:44, Laszlo Ersek lersek@redhat.com wrote:
So, if you manage to reach the guest kernel in any way (regardless of SEV recognition) after launching OVMF with "-bios", that's evidence that your OVMF executable (OVMF_CODE.fd) is wrong. (As long as you care about Secure Boot at all, that is.)
Interesting. I'm using /usr/share/OVMF/OVMF_CODE.fd on Fedora 33.
That's great; Fedora 33 provides both kinds of firmware binaries. For example:
edk2-20200801stable-3.fc33 https://koji.fedoraproject.org/koji/buildinfo?buildID=1655417
-->
edk2-ovmf-20200801stable-3.fc33.noarch.rpm https://koji.fedoraproject.org/koji/rpminfo?rpmID=24208294
See the files:
- OVMF_CODE.fd -> firmware binary built without the SMM+SB features - OVMF_CODE.secboot.fd -> firmware binary built with the SMM+SB features - OVMF_VARS.fd -> logically empty variable store template - OVMF_VARS.secboot.fd -> variable store template with MS certificates enrolled, and the SB operational mode enabled
The package also contains the firmware descriptor files
/usr/share/qemu/firmware/40-edk2-ovmf-x64-sb-enrolled.json /usr/share/qemu/firmware/50-edk2-ovmf-x64-sb.json /usr/share/qemu/firmware/60-edk2-ovmf-x64.json
corresponding to the three use cases:
- SB+SMM features present in executable, SB operational mode enabled in varstore template
- SB+SMM features present in executable, SB operational mode disabled in varstore template
- SB+SMM features absent, SB operational mode disabled in varstore template
Is there a doc / BZ / patch that could help me figure out the exact command-line syntax?
I have to take compatibility into account: kata runtime cannot restrict itself to the latest qemu.
Yes, there is comprehensive documentation. Please refer to the file
docs/interop/firmware.json
in the QEMU source tree. That file defines the *schema* to which the above three metadata (descriptor) files conform. Given a descriptor file, you can construct the corresponding QEMU command line, if you interpret it accordingly to the schema.
Specifically, if you check the @FirmwareMappingFlash description, it explains the "-drive" related difference between QEMU 4.0+, and QEMU versions before that.
(I didn't want to point you to this schema document at once, because reading through it will certainly require some time on your end. I figured I'd give you the end-result command line.)
Case #3: I don't want to build OVMF myself but rely on the distro's package.
Definitely -- that's the best case, but then:
- your distro *must* provide a firmware *use case* descriptor file for each use case that it intends to support,
- you need tooling that understand those descriptors, and implements the QEMU command lines accordingly, based on the schema that I linked above.
To my knowledge, thus far libvirtd is the only such tool. Dan made sure we'd design the schema such that it is not tied to libvirt in any way -- other management applications are welcome to implement it --, it's just that thus far (to my understanding), only libvirtd has actual code for this.
Also, I don't know if SEV requires SecureBoot. I imagine it probably does, but I'm not sure. I sent another message involving Connor Kuehl, I'd like to build a mental map of the whole attestation process in the case of SEV.
Originally, Secure Boot is a privilege boundary *within* the guest, namely between: (a) the platform firmware (OVMF), and (b) 3rd party UEFI drivers (such as option ROMs for PCI devices), and also the guest OS.
Basically the distrust exists between the platform firmware, and everything that is *not* the platform firmware -- all in the guest.
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification". Now, where do PCI device option ROMs come from? Usually, for emulated devices, from the host side (from the hypervisor). So, under the SEV threat model, where you distrust *the host* too, you can use Secure Boot in the guest to prevent this kind of code injection from the host -- you won't just run any UEFI driver from the PCI ROM BAR of a device, unless it is signed properly.
And there comes the additional challenge -- the contents of the variable store file is also maintained on the host side. If you don't trust the host, then you can't trust the key material that's stored in the varstore file and used for SB verification. This problem should be covered in the remote attestation scenario though, where the guest owner uses a unified firmware image -- the executable and the varstore are fused into a single pflash chip --, and both of those logical halves are attested to in a single measurement.
I guess it's possible that this "unified image" is actually the use case that you are after.
Now, Fedora does not provide a unified image -- a unified image is certainly totally useless for the traditional use case, where you want each domain to have its own private varstore, but you want a system-wide firmware executable for *all* domains on the system, one that you can centrally upgrade with "yum". Still, if you'd like to test that setup with Kata, simply concatenate OVMF_VARS and OVMF_CODE (in this order), and use a single (read-write mapped) pflash chip with the resultant file.
(BTW, this unified image is not expressible per the "docs/interop/firmware.json" schema, as -- again -- it is an extremely bad fit for the traditional virt host setup.)
... Anyway, another note regarding SB: note that direct kernel boot via fw-cfg does not undergo SB verification *at all*, so that should never be permitted in a SEV scenario. James Bottomley's remotely attested OVMF platform indeed removes the fw-cfg kernel boot path altogether from OVMF.
So, for starters, you need to know where your firmware executable (OVMF_CODE.fd) comes from -- that will tell you whether it even contains the SMM+SB *features*. If the answer is positive, you can consider the SB *operational mode*, which can be influenced by picking the right one of the variable store templates, as the origin for the domain's actual variable store file.
Is there an easy way to know which flags the OVMF_CODE.fd was built with?
Yes: just diff the following files on Fedora:
/usr/share/qemu/firmware/40-edk2-ovmf-x64-sb-enrolled.json /usr/share/qemu/firmware/50-edk2-ovmf-x64-sb.json /usr/share/qemu/firmware/60-edk2-ovmf-x64.json
pair-wise against each other, and then look up the differences in
docs/interop/firmware.json
in the QEMU tree.
Thanks, Laszlo
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide. The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
James
* James Bottomley (jejb@linux.ibm.com) wrote:
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide. The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security
It's not clear to me why we don't attest the vars-fd, purely to stop someone providing one with a plain OVMF.
and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
Yep that it a bit harder to do it safely; in some ways you're trading off host-guest security against guest security there. (SEV-SNP might be able to provide another way to secure the vars but that's a bit of a way off)
Dave
James
On 01/07/21 18:33, Dr. David Alan Gilbert wrote:
in some ways you're trading off host-guest security against guest security there.
This is a great way to put it IMO; the question is whether SB -- normally, a barrier between guest components -- buys the guest owner any actual security in this use case. If the guest owner controls both the guest firmware and the guest OS completely, there likely is no threat that the guest OS might somehow undermine the guest firmware (e.g., get hacked and install a permanent UEFI rootkit on the UEFI system partition, or whatever).
TBH the *intersections* of these security technologies / threat models are a bit mind-boggling, to me anyway.
Laszlo
* Laszlo Ersek (lersek@redhat.com) wrote:
On 01/07/21 18:33, Dr. David Alan Gilbert wrote:
in some ways you're trading off host-guest security against guest security there.
This is a great way to put it IMO; the question is whether SB -- normally, a barrier between guest components -- buys the guest owner any actual security in this use case. If the guest owner controls both the guest firmware and the guest OS completely, there likely is no threat that the guest OS might somehow undermine the guest firmware (e.g., get hacked and install a permanent UEFI rootkit on the UEFI system partition, or whatever).
It doesn't help if the guest gets compromised by something it's doing; you can imagine a guest-owner who runs a VM that processes externally provided data; they want protection against the cloud-vendor (hence SEV), but they know there's a chance that while processing externally provided data they could get compromised; SB would give them some protection.
TBH the *intersections* of these security technologies / threat models are a bit mind-boggling, to me anyway.
Heck yes, well and truly boggled.
Dave
Laszlo
On Thu, 2021-01-07 at 17:33 +0000, Dr. David Alan Gilbert wrote:
- James Bottomley (jejb@linux.ibm.com) wrote:
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide. The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security
It's not clear to me why we don't attest the vars-fd, purely to stop someone providing one with a plain OVMF.
It currently doesn't work that way in QEMU: only the first flash drive is provisioned into the actual VM. The second and subsequent pflash drives are attached via a firmware config, so they get pulled in as needed (this is how the variable driver works with SMM). In current SEV attestation only happens for the memory provisioned in the initial guest image, i.e. only the first pflash drive.
If the question is could we change the way pflash works for drives after 0, the answer is yes with quite a lot of hacking, but it's quite a big change and you still have the problem of if you make it read/write as the variable store traditionally is, how does the guest owner know what the attestation should look like because there are a lot of NV config changes that occur as the system boots.
and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
Yep that it a bit harder to do it safely; in some ways you're trading off host-guest security against guest security there. (SEV-SNP might be able to provide another way to secure the vars but that's a bit of a way off)
Right, that's why my first posit was we can get all this to work without any persistent variable store, which currently seems to be working out in practice.
James
On 01/07/21 19:07, James Bottomley wrote:
On Thu, 2021-01-07 at 17:33 +0000, Dr. David Alan Gilbert wrote:
- James Bottomley (jejb@linux.ibm.com) wrote:
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide. The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security
It's not clear to me why we don't attest the vars-fd, purely to stop someone providing one with a plain OVMF.
It currently doesn't work that way in QEMU: only the first flash drive is provisioned into the actual VM. The second and subsequent pflash drives are attached via a firmware config, so they get pulled in as needed (this is how the variable driver works with SMM). In current SEV attestation only happens for the memory provisioned in the initial guest image, i.e. only the first pflash drive.
If the question is could we change the way pflash works for drives after 0, the answer is yes with quite a lot of hacking, but it's quite a big change and you still have the problem of if you make it read/write as the variable store traditionally is, how does the guest owner know what the attestation should look like because there are a lot of NV config changes that occur as the system boots.
There's no need for this -- the unified image "OVMF.fd" is just the concatenation of "OVMF_VARS.fd" and "OVMF_CODE.fd" (in this order), and if you provide the guest with just one (r/w) pflash chip that holds the unified "OVMF.fd", the guest is none the wiser. OVMF is expressly unaware of this difference, the guest address space looks exactly the same. In this case, the first (and only) pflash drive covers everything needed, so it can undergo measurement too.
The primary reason for the split image is that you can have, on a traditional virt host, a centrally managed / upgraded OVMF_CODE.fd, while each domain keep its own private variable store file (originally instantiated from a particular OVMF_VARS.fd template). You can run "yum upgrade", the firmware binary gets updated (picked up by domains at their next launch from shutdown state), while each domain's varstore is left intact.
But the remote-attested platform is totally different, so it may be fine to pack both halves into a single pflash chip -- that's how pflash was initially enabled for OVMF in the first place.
Now, how the varstore is protected from tampering by the guest OS -- i.e., from direct (virtual) hardware access by the guest OS, as opposed to going through variable services in the guest firmware --, that's a different question. That's what SMM is used for.
and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
Yep that it a bit harder to do it safely; in some ways you're trading off host-guest security against guest security there. (SEV-SNP might be able to provide another way to secure the vars but that's a bit of a way off)
Right, that's why my first posit was we can get all this to work without any persistent variable store, which currently seems to be working out in practice.
I agree that variables need not survive from one launch of the platform to the next; however, the guest-phys address space corresponding to the variable store should still be covered by *some* pflash device. In other words, the regular file on the host computer that underlies the variable store flash may perfectly well be temporary / transitory, but said regular file, and the corresponding dedicated pflash chip -- or dedicated *segment* of the *one* pflash chip) should definitely *exist*.
In a nutshell, there is no circumstance under which booting OVMF with *just* "OVMF_CODE.fd" is right.
- "-bios" is always wrong, - a single-pflash config with just "OVMF_CODE.fd" is also wrong.
- A single-pflash config with "OVMF.fd" is right (just impossible to upgrade in a traditional virt host setup), - and a two pflash setup, with OVMF_CODE.fd (unit#0) and copy-of-OVMF_VARS.fd (unit#1), is also right.
Thanks Laszlo
On 01/07/21 18:26, James Bottomley wrote:
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
(If the guest owner provides a unified firmware image, including the executable and "static" (= pre-set) variable store, that's not a problem for the Kata use case per se, IIUC; Kata doesn't care about varstore longevity / permanence anyway. But, this is less important, let's continue below.)
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide.
Well, "OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c" still contains a call to EfiBootManagerDispatchDeferredImages(), at which point any option ROMs placed by QEMU in the PCI devices' ROM BARs will be executed.
If we don't want that *ever*, in the remote attested boot platform, then we should likely remove this call. (Cf. commit 0f9395d7c5cc ("ArmPkg: Dispatch deferred images after EndOfDxe", 2019-12-05).)
This "image deferral" is outlined in commit 8be37a5cee70 ("MdeModulePkg/SecurityStubDxe: Defer 3rd party image before EndOfDxe", 2016-11-10). The point of the feature is that, even if a 3rd party UEFI driver is properly signed, it should not be launched immediately when found in a PCI option ROM, that is, before "End of DXE" is reached. "End of DXE" is more or less when the platform locks itself down (= more or less when SMRAM gets closed and locked, for example), after everything has been dispatched from the firmware volume(s) -- so even "trusted" 3rd party drivers are not allowed to launch before that point.
If we don't permit 3rd party UEFI binaries at all (incl. UEFI drivers in option ROMs) on the remote attested firmware platform, then the EfiBootManagerDispatchDeferredImages() call should be removed from this platform's BDS Library instance. In that case, a warning will be emitted to the firmware log during boot (about some deferred images left un-dispatched), but there should not be any ill effects.
And then I do agree that SB may be considered an unnecessary complication.
Thanks for following up! Laszlo
The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
James
participants (4)
-
Christophe de Dinechin
-
Dr. David Alan Gilbert
-
James Bottomley
-
Laszlo Ersek