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

Borislav Petkov bp at suse.de
Wed Jan 5 19:01:10 UTC 2022


On Wed, Jan 05, 2022 at 11:43:25AM +0000, Dr. David Alan Gilbert wrote:
> There's more than one type of dance;

So Brijesh and I talked about this a bit yesterday. There's all kinds of
dances...

> this partially varies depending on the system (SEV/TDX etc)

By "SEV" I guess you mean pre-SNP because SNP attestation is reportedly
much better.

TDX I'm being told is not interested in something like that atm. I guess
they wanna do something different wrt attestation.

So what we're talking about here is pre-SNP attestation, AFAICT.

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

Right.

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

That is the other example I heard about.

So, to sum up: this looks like part of a pre-SNP attestation flow, i.e.,
for SEV and SEV-ES guests.

Follow-up question: is this going to be used by other cloud vendors too?
Or am I gonna get another implementation of sharing secrets with a guest
which is just a little bit different but sender #2 can't use this one
because raisins?

Because that would not be good.

So, is this what cloud vendors using SEV/-ES guests would like to use
and what they all agree upon?

Thx.

-- 
Regards/Gruss,
    Boris.

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



More information about the Linux-security-module-archive mailing list