[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <033ee694b6e9706dca86fb88d27d7f4e0b078f03.camel@intel.com>
Date: Fri, 19 Aug 2022 00:22:39 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"bp@...en8.de" <bp@...en8.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Cox, Philip" <philip.cox@...onical.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>,
"wander@...hat.com" <wander@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Luck, Tony" <tony.luck@...el.com>,
"tim.gardner@...onical.com" <tim.gardner@...onical.com>,
"marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"khalid.elmously@...onical.com" <khalid.elmously@...onical.com>
Subject: Re: [PATCH v9 1/6] x86/tdx: Add TDX Guest attestation interface
driver
On Thu, 2022-08-18 at 09:25 -0700, Dave Hansen wrote:
> On 8/18/22 07:18, Borislav Petkov wrote:
> > > + /*
> > > + * Generate TDREPORT using "TDG.MR.REPORT" TDCALL.
> > > + *
> > > + * Get the TDREPORT using REPORTDATA as input. Refer to
> > > + * section 22.3.3 TDG.MR.REPORT leaf in the TDX Module 1.0
> > > + * Specification for detailed information.
> > > + */
> > > + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(tdreport),
> > > + virt_to_phys(reportdata), req.subtype,
> > That subtype you're not checking either.
>
> I'll chime in here a bit since you're touching on something that bugged
> me too. This whole mechanism is because of two TDX shortcuts. (calling
> them shortcuts is generous, but I digress...)
>
> 1. TDX guest attestation relies on SGX. TDX does not have its own
> attestation mechanism.
> 2. TDX guests can not run SGX enclaves. Only TDX hosts can.
>
> As a result, any TDX guest that wants to do the attestation dance has to
> talk to the host, who them talks to the SGX enclave. There's actually a
> nice diagram of it in here (Figure 5.8):
>
> > https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-whitepaper-v4.pdf
>
> This "talking" can be done via any old communication mechanism. Shared
> memory, virtio, morse code, whatever. TDX_GET_REPORT just happens to be
> yet another communication mechanism dedicated *only* to these
> attestation reports.
Hi Dave,
Just want to clarify, the *yet another communication mechanism" you mentioned
is actually TDX_GET_QUOTE, but not TDX_GET_REPORT.
The TDREPORT (which this TDX_GET_REPORT ABI will report to userspace) is the
data blob that needs to be sent to SGX quoting enclave to generate a Quote
(which can be remotely verified). It's the first step of supporting TDX
attestation, no matter whatever communication channel is going to be used to
talk to quoting enclave (vsock, tcp, or GetQuote).
>
> So, this is not a *STRICTLY* required ABI. Guests _can_ use other
> mechanisms to talk to an SGX attestation (quoting) enclave. Second,
> this ABI *is* TDX-specific because no other hardware architectures have
> made the same design "choices".
>
> That's why this was jettisoned for v10. It might reappear later, though.
Agreed (assuming you mean TDX_GET_QUOTE ABI).
Btw, my thinking is perhaps we can just make GetQuote support as a Intel-
specific driver, which can be a module, can have a separate Kconfig, etc. It
doesn't have to be a core functionality.
--
Thanks,
-Kai
Powered by blists - more mailing lists