Re: [RFC PATCH 0/3] Allow access to confidential computing secret area

* Andi Kleen (ak@linux.intel.com) wrote:

quoted

The SEV-SNP attestation approach is very similar to what Andi described
for the TDX. However, in the case of legacy SEV and ES, the attestation
verification is performed before the guest is booted. In this case, the
hyervisor puts the secret provided by the guest owner (after the
attestation) at a fixed location. Dov's driver is simply reading that
fixed location and making it available through the simple text file.

That's the same as our SVKL model.

The (not yet posted) driver is here:

https://github.com/intel/tdx/commit/62c2d9fae275d5bf50f869e8cfb71d2ca1f71363

Is there any way we could merge these two so that the TDX/SVKL would
look similar to SEV/ES to userspace?  If we needed some initrd glue here
for luks it would be great if we could have one piece of glue.
[I'm not sure if the numbering/naming of the secrets, and their format
are defined in the same way]

We opted to use ioctls, with the idea that it should be just read and
cleared once to not let the secret lying around. Typically you would just
use it to set up dmcrypt or similar once. I think read-and-clear with
explicit operations is a better model than some virtual file because of the
security properties.

Do you think the ioctl is preferable to read+ftruncate/unlink ?
And if it was an ioctl, again could we get some standardisation here -
i.e.
maybe a /dev/confguest with a CONF_COMP_GET_KEY etc ?

Dave

-Andi

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK