Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf

[James Bottomley <jejb@linux.ibm.com>]

On Thu, 2020-11-12 at 11:32 -0600, Brijesh Singh wrote:
> Hi James,
> 
> Thanks for series, I glanced at it, the changes looks okay to me. I
> have
> one questions.
> 
> How does the grub locate the disk decryption key ? Am I correct in
> assuming that the gurb is iterating through a configuration table
> entries and comparing the Secret GUID to locate the secret key. As
> per the SEV spec, its possible that a guest owner can call the secret
> injection more than once. I don't see the patch consider that case,
> should we support this or limit to one inject?  Maybe Qemu can
> enforce this property.

Well in the original patch, grub recognized the secret in the area by
the prefix "PASSWORD:".  I think that's a bit fragile, so I was
planning to rework the grub patch to do everything by guid, so the
secrets table itself would have its own guid which would be followed by
the entire table length.  Then the entries in the table would have the
format

|guid|len|data|

So every consumer first of all validates the table by the initial guid
and gets the total length then iterates over the entries to see if its
interested in any of them.  The format of |data| would be up to the
consumer.

> Do you see any need for the Linux kernel needing to access the
> secret? Since the secret blob is available through configuration
> table, I believe we can have a platform driver that can read the
> configuration table and retrieve the secret blob.

I've only been really concentrating on the grub use case.  However, as
you saw in my reply about migration, we likely also need an entry so
that the migration helper can pick up its ECDH identity.  The scheme
would definitely cover passing a secret to the kernel as well.  The one
caveat there is that the HOB that covers the secret is boot time, so
the secret would have to be extracted in the kernel EFI stub before
ExitBootServices() is called.  I suppose nothing really prevent the HOB
from becoming runtime except the security maxim that you want all
secret lifetimes to be as short as possible.

James