On Tue, Jun 27, 2023 at 05:11:07PM -0700, Dan Williams wrote:

Dionna Amalie Glaze wrote:

quoted

On Sun, Jun 25, 2023 at 8:06 PM Sathyanarayanan Kuppuswamy
[off-list ref] wrote:

[..]

quoted

quoted

Hi Dan,

On 6/23/23 3:27 PM, Dan Williams wrote:

quoted

Dan Williams wrote:

quoted

[ add David, Brijesh, and Atish]

Kuppuswamy Sathyanarayanan wrote:

quoted

In TDX guest, the second stage of the attestation process is Quote
generation. This process is required to convert the locally generated
TDREPORT into a remotely verifiable Quote. It involves sending the
TDREPORT data to a Quoting Enclave (QE) which will verify the
integrity of the TDREPORT and sign it with an attestation key.

Intel's TDX attestation driver exposes TDX_CMD_GET_QUOTE IOCTL to
allow the user agent to get the TD Quote.

Add a kernel selftest module to verify the Quote generation feature.

TD Quote generation involves following steps:

* Get the TDREPORT data using TDX_CMD_GET_REPORT IOCTL.
* Embed the TDREPORT data in quote buffer and request for quote
  generation via TDX_CMD_GET_QUOTE IOCTL request.
* Upon completion of the GetQuote request, check for non zero value
  in the status field of Quote header to make sure the generated
  quote is valid.

What this cover letter does not say is that this is adding another
instance of the similar pattern as SNP_GET_REPORT.

Linux is best served when multiple vendors trying to do similar
operations are brought together behind a common ABI. We see this in the
history of wrangling SCSI vendors behind common interfaces. Now multiple
confidential computing vendors trying to develop similar flows with
differentiated formats where that differentiation need not leak over the
ABI boundary.

[..]

Below is a rough mock up of this approach to demonstrate the direction.
Again, the goal is to define an ABI that can support any vendor's
arch-specific attestation method and key provisioning flows without
leaking vendor-specific details, or confidential material over the
user/kernel ABI.

Thanks for working on this mock code and helping out. It gives me the
general idea about your proposal.

quoted

The observation is that there are a sufficient number of attestation
flows available to review where Linux can define a superset ABI to
contain them all. The other observation is that the implementations have
features that may cross-polinate over time. For example the SEV
privelege level consideration ("vmpl"), and the TDX RTMR (think TPM
PCRs) mechanisms address generic Confidential Computing use cases.

I agree with your point about VMPL and RTMR feature cases. This observation
is valid for AMD SEV and TDX attestation flows. But I am not sure whether
it will hold true for other vendor implementations. Our sample set is not
good enough to make this conclusion. The reason for my concern is, if you
check the ABI interface used in the S390 arch attestation driver
(drivers/s390/char/uvdevice.c), you would notice that there is a significant
difference between the ABI used in that driver and SEV/TDX drivers. The S390
driver attestation request appears to accept two data blobs as input, as well
as a variety of vendor-specific header configurations.

Maybe the s390 attestation model is a special case, but, I think we consider
this issue. Since we don't have a common spec, there is chance that any
superset ABI we define now may not meet future vendor requirements. One way to
handle it to leave enough space in the generic ABI to handle future vendor
requirements.

I think it would be better if other vendors (like ARM or RISC) can comment and
confirm whether this proposal meets their demands.

The VMPL-based separation that will house the supervisor module known
as SVSM can have protocols that implement a TPM command interface, or
an RTMR-extension interface, and will also need to have an
SVSM-specific protocol attestation report format to keep the secure
chain of custody apparent. We'd have different formats and protocols
in the kernel, at least, to speak to each technology. 

That's where I hope the line can be drawn, i.e. that all of this vendor
differentiation really only matters inside the kernel in the end.

Looking at your keys subsystem based PoC (thanks for putting it
together), I understand that the intention is to pass an attestation
evidence request as a payload to the kernel, in a abstract way.
i.e. the void *data in:
static int guest_attest_request_key(struct key *authkey, void *data)

And then passiing that down to vendor specific handlers
(tdx_request_attest in your PoC) for it to behave as a key server for
that attestation evidence request. The vendor magic of transforming an
attestation request into an actual attestation evidence (typically
signed with platform derived keys) is stuffed into that handler. The
format, content and protection of both the attestation evidence request
and the evidence itself is left for the guest kernel handler (e.g.
tdx_request_attest) to handle.

Is that a fair description of your proposal?

If it is, then it makes sense to me, and could serve as a generic
abstraction for confidential computing guest attestation evidence
requests. I think it could support the TDX, SEV and also the RISC-V
(aka CoVE) guest attestation request evidence flow.

quoted

I'm not sure it's worth the trouble of papering over all the... 3-4
technologies with similar but still weirdly different formats and ways
of doing things with an abstracted attestation ABI, especially since
the output all has to be interpreted in an architecture-specific way
anyway.

This is where I need help. Can you identify where the following
assertion falls over:

"The minimum viable key-server is one that can generically validate a
blob with an ECDSA signature".

I.e. the fact that SEV and TDX send different length blobs is less
important than validating that signature.

I'm not sure which signature we're talking about here.
The final attestation evidence (The blob the guest workload will send to
a remote attestation service) is signed with a platform derived key,
typically rooted into a manufacturer's CA. It is then up to the *remote*
attestation service to authenticate and validate the evidence signature.
Then it can go through the actual attestation verification flow
(comparison against reference values, policy checks, etc). The latter
should be none of the guest kernel's business, which is what your
proposal seems to be heading to.

If it is always the case that specific fields in the blob need to be
decoded then yes, that weakens the assertion. 

Your vendor specific key handler may have to decode the passed void
pointer into a vendor specific structure before sending it down to the
TSM/ASP/etc, and that's fine imho.

Cheers,
Samuel.