Open Stack

On Thu, 2021-01-07 at 17:33 +0000, Dr. David Alan Gilbert wrote:
> * 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.

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