* 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
-- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK