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.
