[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ba03a0d0eafc6622eee9e485bd89d22778a7592.camel@intel.com>
Date: Mon, 31 Jul 2023 22:41:06 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"dhowells@...hat.com" <dhowells@...hat.com>
CC: "sameo@...osinc.com" <sameo@...osinc.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"bp@...en8.de" <bp@...en8.de>,
"peterz@...radead.org" <peterz@...radead.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
reports
On Mon, 2023-07-31 at 10:09 +0000, Jarkko Sakkinen wrote:
> > This facility is different, it is just aiming to unify this attestation
> > report flow. It scales to any driver that can provide the ->auth_new()
> > operation. I have the sev-guest conversion in this set, and Sathya has
> > tested this with tdx-guest. I am hoping Samuel can evaluate it for
> > cove-guest or whatever that driver ends up being called.
>
> What about SGX without TDX?
SGX attestation is completely among userspace enclaves, and the existing SGX
userspace stack has fully adopted what is needed to do attestation. Why do we
need to cover SGX?
Powered by blists - more mailing lists