[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