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

[Mikko Ylinen <mikko.ylinen@linux.intel.com>]

On Wed, Jan 31, 2024 at 01:09:03PM -0800, Dan Williams wrote:
> 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.

Confidential Containers project started using the tdx_guest ioctl() to get
the TD report. This is used by the attestation-agent to check that the hash
of a policy file is correctly included in the TD report's MRCONFIGID field.

The report stays within the TD and there's no need take it to the host QGS
quoting service for signing. Right now we need to go to configs-tsm for
the quote and tdx_guest ioctl() for the TD report.

The corresponding SNP check in this use case is to get the HOSTDATA report
field by using 'get report' ioctl() (non-ext version is enough). With
configfs-tsm this is same as using just 'outblob' and ignoring 'auxblob',
AFAICS.

However, perhaps some generic report 'type' TSM report attribute would be
justified here to allow users select between TD report/quote and
report/ext_report generation?

-- Regards, Mikko