* Borislav Petkov (bp@suse.de) wrote:

On Tue, Jan 04, 2022 at 09:02:03AM +0200, Dov Murik wrote:

quoted

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.

There's more than one type of dance; this partially varies
depending on the system (SEV/TDX etc) and also depends on how you depend
to boot your VM (separate kernel or VM disk).   Also it's important to
note that when the dance happens varies - in SEV and SEV-ES this happens
before the guest executes any code.
So at the end of the dance, the guest owner hands over that secret - but
only then does the geust start booting; that secret has to go somewhere
to be used by something later.
For example, something might pull out that key and use it to decrypt a
disk that then has other secrets on it (e.g. your ssh key).

Dave

quoted

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

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

quoted

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?

quoted

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.

quoted

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

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK