Re: [PATCH v3 3/3] selftests/tdx: Test GetQuote TDX attestation feature

[Huang, Kai]

On Fri, 2023-06-23 at 15:27 -0700, Dan Williams wrote:
> An example, to show what the strawman patch below enables: (req_key is
> the sample program from "man 2 request_key")
> 
> # ./req_key guest_attest guest_attest:0:0-$desc $(cat user_data | base64)
> Key ID is 10e2f3a7
> # keyctl pipe 0x10e2f3a7 | hexdump -C
> 00000000  54 44 58 20 47 65 6e 65  72 61 74 65 64 20 51 75  |TDX Generated Qu|
> 00000010  6f 74 65 00 00 00 00 00  00 00 00 00 00 00 00 00  |ote.............|
> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00004000
> 
> This is the kernel instantiating a TDX Quote without the TDREPORT
> implementation detail ever leaving the kernel. 

There might be one small issue here.  The generated Quote has a userspace
provided 'u64 REPORTDATA' (which originally comes from userspace when generating
the TDREPORT) which is supposed to be used by the attestation service to
uniquely identify this Quote to mitigate some sort of reply-attack.  For
instance, the REPORTDATA could be a per-TLS-session data provided by the
attestation service.

I don't know whether other archs have similar thing in their Quote-like blob,
but I believe this in general is a reasonable thing.

IIUC, one problem of using above request_key() to generate the Quote is
potentially other userspace processes are able to see this, while I believe this
REPORTDATA is only supposed to be visible by the application which is
responsible for talking to the attestation service.  

I am not sure whether this is a risk, but using IOCTL() should be able to avoid
this risk.