Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams <dan.j.williams@intel.com>]

Kuppuswamy Sathyanarayanan wrote:
> 
> On 1/31/24 11:50 AM, Dan Williams wrote:
> > Kuppuswamy Sathyanarayanan wrote:
> >> + Dan Middleton
> >>
> >> Hi Boris,
> >>
> >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> >>> IOCTL based interface was the natural choice for interacting with the
> >>> quote generation machine at a time when there wasn't anything better.
> >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> >>> obviates the need to have the IOCTL-based interface.
> >>>
> >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> >>> deprecated as well as introduce a runtime warning.
> >>>
> >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> >>> ---
> >> In the following thread, Dan Middleton raised a point about this interface
> >> being used for local attestation use cases.
> >>
> >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> >>
> >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > What are local attestation use cases, and what happens if Linux does not
> > provide a local attestation interface and standardizes on remotely
> > attestable as the standard?
> 
> 
> Local attestation is used by one TD on the same platform to prove to another TD
> in the same platform about its identity. It is mainly used in cases where a TD provides
> some special services required by other TDs. Since they are all in the same platform,
> there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> to check the correctness of the TD.
> 
> I am not sure about actual local attestation users. May be Dan can share that info.
> 
> Regarding your question about using "remotely attestable as the standard", I think
> remote attestation can handle all local attestation use cases. But, does it make sense to
> force users to run a Quoting service if they don't need to communicate with 3rd party
> servers?

SEV-SNP seems to get by without a local attestation flow, if I am not
mistaken, so the question is why should the kernel support cross-vendor
divergence here? Remember, the kernel ends up being the "standardization
body of last resort", it does not need to onboard all the complexity it
can find.

> SGX also seems to have local attestation concept
> 
> https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation/inter-process-local-attestation

I am less concerned with concepts, and more concerned with use cases.
For example it could be the case that configfs-tsm needs to grow to
support local attestation for multiple vendors, but that should be due
to concrete use cases to be deployed, not theoretical observations.