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

[Brijesh Singh <brijesh.singh@amd.com>]

On 11/12/20 4:50 PM, James Bottomley wrote:
> 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.

I wanted to highlight spec. I agree that in our VM launch I don't see a
need to provide a multiple LAUNCH_SECRET as long as we define producer
and consumer format to package the multiple secrets in one inject.


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


Yes, your guid approach is much preferred. thanks

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