Open Stack

* James Bottomley (jejb at 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 at redhat.com / Manchester, UK