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

[Dan Middleton <dan.middleton@linux.intel.com>]

On 2/8/24 7:42 AM, Mikko Ylinen wrote:
> 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
Sorry, I somehow missed the continuation of this thread.

I think there's a couple use cases mentioned here including
1. Service TDs like vTPM (there is code for this[1]. I can't speak to 
its adoption.)

2. Locally verifiable evidence as visible in CNCF CoCo (thanks Mikko).

I don't think it should be deprecated until / unless there is a
committed alternative like a configfs-tsm feature.
I don't know the kernel community's preference for a single vendor
configfs-tsm feature vs a single vendor ioctl.

I would suspect that other vendors will offer local attestations based
on local appearing in SGX and TDX, but that's speculation. If so their
APIs would better inform a new common configfs-tsm feature.
Maybe people with knowledge of AMD, Arm, and RISC-V disclosed plans can

comment.


[1] https://github.com/intel/vtpm-td/tree/main


Thanks,
Dan Middleton