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

[Borislav Petkov]

On Tue, Jan 04, 2022 at 09:02:03AM +0200, Dov Murik wrote:
> 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.

Hmm, I'd expect that to be part of the attestation dance. I admit,
though, I have only listened about the whole attestation bla from the
sidelines so I'm unclear whether that's part of that protocol. I guess
Tom and Brijesh should have a better idea here.

> One way to achieve that would be to inject the guest's SSH private key

Well, is that "one way" or *the way*?

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

Because we would need *some* way of verifying the owner is talking
to the correct guest. And if so, this should be made part of the big
picture of SEV guest attestation. Or is this part of that attestation
dance?

I guess I'm wondering where in the big picture this fits into?

> 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 one of the aspects for this is to use it in automated deployments.

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

Right, and is this going to be the proper way to authenticate SEV guests
to their owners or is this just another technique for safely supplying
secrets into the guest?

I hope I'm making some sense here...

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg