Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Tue, 01 Aug 2023 21:48:50 +0300
Message-Id: <CUHFLMO6MJBP.1AHYJWGAEEEKT@suppilovahvero>
To:     "Huang, Kai" <kai.huang@intel.com>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "dhowells@redhat.com" <dhowells@redhat.com>
Cc:     "sameo@rivosinc.com" <sameo@rivosinc.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "bp@alien8.de" <bp@alien8.de>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "sathyanarayanan.kuppuswamy@linux.intel.com" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "dionnaglaze@google.com" <dionnaglaze@google.com>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "brijesh.singh@amd.com" <brijesh.singh@amd.com>,
        "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
        "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports
From:   "Jarkko Sakkinen" <jarkko@kernel.org>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <CUE22P5RYPH3.1K05T2OCK1CN1@seitikki> <64c41aa5ba9ac_a88b29494@dwillia2-xfh.jf.intel.com.notmuch> <CUG9XAK3RNFF.GWCYLXSTWX5E@seitikki> <3ba03a0d0eafc6622eee9e485bd89d22778a7592.camel@intel.com>
In-Reply-To: <3ba03a0d0eafc6622eee9e485bd89d22778a7592.camel@intel.com>
Precedence: bulk

On Tue Aug 1, 2023 at 1:41 AM EEST, Huang, Kai wrote:
> On Mon, 2023-07-31 at 10:09 +0000, Jarkko Sakkinen wrote:
> > > This facility is different, it is just aiming to unify this attestati=
on
> > > 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 ha=
s
> > > tested this with tdx-guest. I am hoping Samuel can evaluate it for
> > > cove-guest or whatever that driver ends up being called.
> >=20
> > 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?

I have no answer to that. I'm merely trying to understand what this is.

BR, Jarkko