[PATCH v6 0/5] Allow guest access to EFI confidential computing secret area

[Dov Murik]

Hello Boris,

On 03/01/2022 20:59, Borislav Petkov wrote:
> On Mon, Nov 29, 2021 at 11:42:46AM +0000, Dov Murik wrote:
>> As a usage example, consider a guest performing computations on
>> encrypted files.  The Guest Owner provides the decryption key (= secret)
>> using the secret injection mechanism.  The guest application reads the
>> secret from the efi_secret filesystem and proceeds to decrypt the files
>> into memory and then performs the needed computations on the content.
>>
>> In this example, the host can't read the files from the disk image
>> because they are encrypted.  Host can't read the decryption key because
>> it is passed using the secret injection mechanism (= secure channel).
>> Host can't read the decrypted content from memory because it's a
>> confidential (memory-encrypted) guest.
> 
> So maybe I don't understand the example properly or something's missing
> but why can't the guest owner simply scp the secrets into the guest? Why
> is this special thing needed?

If the Guest Owner chooses to inject secrets via scp, it needs
to be sure it is scp-ing to the correct VM - the one that has SEV
enabled and was measured at launch.

One way to achieve that would be to inject the guest's SSH private key
using the proposed efi_secret mechanism.  This way the Guest Owner is
sure it is talking to the correct guest and not to some other VM that
was started by the untrusted cloud provider (say, with SEV disabled so
the cloud provider can steal its memory content).


> 
> The secret below says "...kata-secrets" so this sounds like
> something-automated-containers-thing where they'd profit from getting
> secrets automatically supplied to the guest. But I guess there you can
> scp too...

Indeed this proposed efi_secret module is in use for enabling SEV
confidential containers using Kata containers [1], but there's nothing
specific in the current patch series about containers.  The patch series
just exposes the launch-injected SEV secrets to userspace as virtual files
(under securityfs).

[1] https://github.com/confidential-containers/attestation-agent/tree/main/src/kbc_modules/offline_sev_kbc


> 
> So what am I missing?
> 

It boils down to: the confidential guest needs to have access to a
secret which the untrusted host can't read, and which is essential for
the normal operation of the guest.  This secret can be a decryption key,
an SSH private key, an API key to a Key Management system, etc.  If a
malicious cloud provider tries to start that VM without a secret (or
with the wrong one), the actual workload that the guest is supposed to
run will not execute meaningfully.

The proposed patch series exposes the SEV injected secrets as virtual
files, which can later be used as decryption keys (as done in the kata
confidential containers use-case), or SSH private keys, or any other
possible implementation.

-Dov