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

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

On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote:
> On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote:
> > * Brijesh Singh (brijesh.singh@amd.com) 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.
> > That's interesting, I hadn't realised that was possible - however,
> > I can't see a way to use it - for it to be useful, you would have
> > to have a way for the guest to communicate to the owner that it had
> > finished with the first injection and would like the next; but if
> > you already have a way to communicate from the guest to the owner
> > to request stuff, then you could pass a new secret by that comms
> > route?
> 
> The main reason for its existence was to allow guest owner to inject
> multiple blocks of the data if they need to do so, e.g IIRC, Enarx
> folks use this to inject the keep which is much bigger than 128K.

In some ways this sounds like the wrong approach.  I mean we could use
injection to inject the entire VM image as well, but we don't, we
inject the key and decrypt the image ... it does rather sound like
that's what should be happening for other bulk data, like the keep.  If
you do it this way you can use the main CPU and bulk memory encryption
to pull the data into the secure memory rather than using the PSP,
which is a lot slower.

Also one of the problems with having OVMF define the secret location is
that we have to find space in the MEMFD.  For a single page like the
current implementation uses, that's easy, but for tens to hundreds of
pages it would be impossible.  Even if we guid describe everything,
standard aes keys are 16-32 bytes, so even in the worst case we can fit
85 guid described decryption keys in a page, which should be more than
enough for anyone, provided we inject the key to the bulk data, not the
bulk data itself.

>  I am not sure if we really need it for the VM boot flow but we
> probably need to define the secret page layout such that it contains
> multiple entries in it. In our case the Secret can't be more than a
> page, so, we can define a secret page layout such that it can contain
> more than one disk key. I was thinking about something like this
> 
> typedef enum {
> 
>    DISK_KEY_AES_128,
> 
>    SSH_PRIVATE_KEY,
> 
>    ...
> 
> } data_type;
> 
> struct secret_data {
> 
>    u8 entries;
> 
>    struct {
> 
>       data_type type;
> 
>       u16 len;
> 
>       u8 name[16];
> 
>       u8 data[];
> 
>    } entry[];
> 
> }
> 
> This should allow us to package multiple secrets in one inject.

I proposed something slightly different in a prior email.  If we use
the guid approach, we don't have to define the data structure a-priori
... just the producer and consumer have to agree on what it is.

> > > 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 guess it depends if you get the Grub to pass the fs secret down
> > to the kernel or let it pick it up itself from the same place.
> 
> I guess the main reason why I was asking this is, what if guest owner
> provides more than one disk keys in the secret injection blob. Grub
> can use the boot disk key to access the Linux images and other disk
> keys may later be used by Linux.

Right, see other email for limitations.

James