From: Borislav Petkov <bp@suse.de>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Dov Murik <dovmurik@linux.ibm.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
linux-efi@vger.kernel.org, Ashish Kalra <ashish.kalra@amd.com>,
Ard Biesheuvel <ardb@kernel.org>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Andi Kleen <ak@linux.intel.com>,
Greg KH <gregkh@linuxfoundation.org>,
Andrew Scull <ascull@google.com>,
Dave Hansen <dave.hansen@intel.com>,
James Bottomley <jejb@linux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
Jim Cadden <jcadden@ibm.com>,
Daniele Buono <dbuono@linux.vnet.ibm.com>,
linux-coco@lists.linux.dev,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area
Date: Wed, 5 Jan 2022 20:01:10 +0100 [thread overview]
Message-ID: <YdXq9t75aYLJfb69@zn.tnic> (raw)
In-Reply-To: <YdWEXRt7Ixm6/+Dq@work-vm>
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
next prev parent reply other threads:[~2022-01-05 19:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 11:42 [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area Dov Murik
2021-11-29 11:42 ` [PATCH v6 1/5] efi: Save location of EFI confidential computing area Dov Murik
2021-11-29 11:42 ` [PATCH v6 2/5] efi/libstub: Reserve confidential computing secret area Dov Murik
2021-11-29 11:42 ` [PATCH v6 3/5] virt: Add efi_secret module to expose confidential computing secrets Dov Murik
2021-12-06 7:58 ` kernel test robot
2021-12-06 7:58 ` kernel test robot
2021-11-29 11:42 ` [PATCH v6 4/5] efi: Load efi_secret module if EFI secret area is populated Dov Murik
2021-11-29 11:42 ` [PATCH v6 5/5] docs: security: Add coco/efi_secret documentation Dov Murik
2021-12-15 11:33 ` [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area Dov Murik
2022-01-03 18:59 ` Borislav Petkov
2022-01-04 7:02 ` Dov Murik
2022-01-04 18:26 ` Borislav Petkov
2022-01-05 11:43 ` Dr. David Alan Gilbert
2022-01-05 19:01 ` Borislav Petkov [this message]
2022-01-05 20:07 ` Dr. David Alan Gilbert
2022-01-07 11:59 ` Borislav Petkov
2022-01-07 19:16 ` Peter Gonda
2022-01-10 11:14 ` Dov Murik
2022-01-10 16:27 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YdXq9t75aYLJfb69@zn.tnic \
--to=bp@suse.de \
--cc=ak@linux.intel.com \
--cc=ardb@kernel.org \
--cc=ascull@google.com \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@intel.com \
--cc=dbuono@linux.vnet.ibm.com \
--cc=dgilbert@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jcadden@ibm.com \
--cc=jejb@linux.ibm.com \
--cc=jmorris@namei.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=thomas.lendacky@amd.com \
--cc=tobin@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.