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