Open Stack

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 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.

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