Hi All,

In TDX guest, the attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest.

The TDX guest attestation process consists of two steps:

1. TDREPORT generation
2. Quote generation.

The First step (TDREPORT generation) involves getting the TDX guest
measurement data in the format of TDREPORT which is further used to
validate the authenticity of the TDX guest. The second step involves
sending the TDREPORT to a Quoting Enclave (QE) server to generate a
remotely verifiable Quote. TDREPORT by design can only be verified on
the local platform. To support remote verification of the TDREPORT,
TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
locally and convert it to a remotely verifiable Quote. Although
attestation software can use communication methods like TCP/IP or
vsock to send the TDREPORT to QE, not all platforms support these
communication models. So TDX GHCI specification [1] defines a method
for Quote generation via hypercalls. Please check the discussion from
Google [2] and Alibaba [3] which clarifies the need for hypercall based
Quote generation support. This patch set adds this support.

Support for TDREPORT generation already exists in the TDX guest driver. 
This patchset extends the same driver to add the Quote generation
support.

Following are the details of the patch set:

Patch 1/3 -> Adds event notification IRQ support.
Patch 2/3 -> Adds Quote generation support.
Patch 3/3 -> Adds selftest support for Quote generation feature.

[1] https://cdrdv2.intel.com/v1/dl/getContent/726790, section titled "TDG.VP.VMCALL<GetQuote>".
[2] https://lore.kernel.org/lkml/CAAYXXYxxs2zy_978GJDwKfX5Hud503gPc8=1kQ-+JwG_kA79mg@mail.gmail.com/
[3] https://lore.kernel.org/lkml/a69faebb-11e8-b386-d591-dbd08330b008@linux.alibaba.com/

Kuppuswamy Sathyanarayanan (3):
  x86/tdx: Add TDX Guest event notify interrupt support
  virt: tdx-guest: Add Quote generation support
  selftests/tdx: Test GetQuote TDX attestation feature

 Documentation/virt/coco/tdx-guest.rst        |  11 ++
 arch/x86/coco/tdx/tdx.c                      | 194 +++++++++++++++++++
 arch/x86/include/asm/tdx.h                   |   8 +
 drivers/virt/coco/tdx-guest/tdx-guest.c      | 175 ++++++++++++++++-
 include/uapi/linux/tdx-guest.h               |  44 +++++
 tools/testing/selftests/tdx/tdx_guest_test.c |  65 ++++++-
 6 files changed, 490 insertions(+), 7 deletions(-)

-- 
2.34.1

Kuppuswamy Sathyanarayanan wrote:
> Hi All,
> 
> In TDX guest, the attestation process is used to verify the TDX guest
> trustworthiness to other entities before provisioning secrets to the
> guest.
> 
> The TDX guest attestation process consists of two steps:
> 
> 1. TDREPORT generation
> 2. Quote generation.
> 
> The First step (TDREPORT generation) involves getting the TDX guest
> measurement data in the format of TDREPORT which is further used to
> validate the authenticity of the TDX guest. The second step involves
> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> remotely verifiable Quote. TDREPORT by design can only be verified on
> the local platform. To support remote verification of the TDREPORT,
> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> locally and convert it to a remotely verifiable Quote. Although
> attestation software can use communication methods like TCP/IP or
> vsock to send the TDREPORT to QE, not all platforms support these
> communication models. So TDX GHCI specification [1] defines a method
> for Quote generation via hypercalls. Please check the discussion from
> Google [2] and Alibaba [3] which clarifies the need for hypercall based
> Quote generation support. This patch set adds this support.
> 
> Support for TDREPORT generation already exists in the TDX guest driver. 
> This patchset extends the same driver to add the Quote generation
> support.

I missed that the TDREPORT ioctl() and this character device are already
upstream. The TDREPORT ioctl() if it is only needed for quote generation
seems a waste because it just retrieves a blob that needs to be turned
around and injected back into the kernel to generate a quote.

An ABI wants to care about the abstractions around what the hardware
mechanism enables. The TD quote is not even at the end of that chain of
what the ABI needs to offer. The guest wants to use the TD quote to access
/ unlock other resources, just like the SEV report is used to
"...provide the VM with secrets, such as a disk decryption key, or other
keys required for operation".

That's where the ABI line needs to be drawn. I.e. for the guest to be
able to request the distributions of keys to unlock resources by a
key-type and key-descriptor. Enable userspace to interrogate an
attestation object without blobs needing to traverse the kernel. If the
remote service needs more than just a blob and signature to validate the
state of the guest then provide faclity to interrogate that property of
quote / report in a common way versus the ABI risk of conveying vendor
specific binary data formats in the kernel ABI.

On 6/23/23 9:05 PM, Dan Williams wrote:
> Kuppuswamy Sathyanarayanan wrote:
>> Hi All,
>>
>> In TDX guest, the attestation process is used to verify the TDX guest
>> trustworthiness to other entities before provisioning secrets to the
>> guest.
>>
>> The TDX guest attestation process consists of two steps:
>>
>> 1. TDREPORT generation
>> 2. Quote generation.
>>
>> The First step (TDREPORT generation) involves getting the TDX guest
>> measurement data in the format of TDREPORT which is further used to
>> validate the authenticity of the TDX guest. The second step involves
>> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
>> remotely verifiable Quote. TDREPORT by design can only be verified on
>> the local platform. To support remote verification of the TDREPORT,
>> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
>> locally and convert it to a remotely verifiable Quote. Although
>> attestation software can use communication methods like TCP/IP or
>> vsock to send the TDREPORT to QE, not all platforms support these
>> communication models. So TDX GHCI specification [1] defines a method
>> for Quote generation via hypercalls. Please check the discussion from
>> Google [2] and Alibaba [3] which clarifies the need for hypercall based
>> Quote generation support. This patch set adds this support.
>>
>> Support for TDREPORT generation already exists in the TDX guest driver. 
>> This patchset extends the same driver to add the Quote generation
>> support.
> 
> I missed that the TDREPORT ioctl() and this character device are already
> upstream. The TDREPORT ioctl() if it is only needed for quote generation
> seems a waste because it just retrieves a blob that needs to be turned
> around and injected back into the kernel to generate a quote.

Although the end goal is to generate the quote, the method the user chooses to
achieve it may differ for a variety of reasons. In this case, we're trying to
support the use case where the user will use methods like TCP/IP or vsock to
generate the Quote. They can use the GET_REPORT IOCTL to get the TDREPORT and
send it to the quoting enclave via the above-mentioned methods.  TDVMCALL-based
quote generation is intended for users who, for a variety of security reasons, do
not wish to use the methods described above.



-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Sathyanarayanan Kuppuswamy wrote:
> 
> 
> On 6/23/23 9:05 PM, Dan Williams wrote:
> > Kuppuswamy Sathyanarayanan wrote:
> >> Hi All,
> >>
> >> In TDX guest, the attestation process is used to verify the TDX guest
> >> trustworthiness to other entities before provisioning secrets to the
> >> guest.
> >>
> >> The TDX guest attestation process consists of two steps:
> >>
> >> 1. TDREPORT generation
> >> 2. Quote generation.
> >>
> >> The First step (TDREPORT generation) involves getting the TDX guest
> >> measurement data in the format of TDREPORT which is further used to
> >> validate the authenticity of the TDX guest. The second step involves
> >> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> >> remotely verifiable Quote. TDREPORT by design can only be verified on
> >> the local platform. To support remote verification of the TDREPORT,
> >> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> >> locally and convert it to a remotely verifiable Quote. Although
> >> attestation software can use communication methods like TCP/IP or
> >> vsock to send the TDREPORT to QE, not all platforms support these
> >> communication models. So TDX GHCI specification [1] defines a method
> >> for Quote generation via hypercalls. Please check the discussion from
> >> Google [2] and Alibaba [3] which clarifies the need for hypercall based
> >> Quote generation support. This patch set adds this support.
> >>
> >> Support for TDREPORT generation already exists in the TDX guest driver. 
> >> This patchset extends the same driver to add the Quote generation
> >> support.
> > 
> > I missed that the TDREPORT ioctl() and this character device are already
> > upstream. The TDREPORT ioctl() if it is only needed for quote generation
> > seems a waste because it just retrieves a blob that needs to be turned
> > around and injected back into the kernel to generate a quote.
> 
> Although the end goal is to generate the quote, the method the user chooses to
> achieve it may differ for a variety of reasons. In this case, we're trying to
> support the use case where the user will use methods like TCP/IP or vsock to
> generate the Quote. They can use the GET_REPORT IOCTL to get the TDREPORT and
> send it to the quoting enclave via the above-mentioned methods.  TDVMCALL-based
> quote generation is intended for users who, for a variety of security reasons, do
> not wish to use the methods described above.

This flexibility could be supported with keys if necessary, although I
would want to hear strong reasons not a "variety of reasons" why
everyone cannot use a unified approach. ABI proliferation has a
maintenance cost and a collaboration cost. It is within the kernel
community's right to judge the cost of ABI flexibility and opt for a
constrained implementation if that cost is too high.

What I would ask of those who absolutely cannot support the TDVMCALL
method is to contribute a solution that intercepts the "upcall" to the
platform "guest_attest_ops" and turn it into a typical keys upcall to
userspace that can use the report data with a vsock tunnel.

That way the end result is still the same, a key established with the
TDX Quote evidence contained within a Linux-defined envelope.

On Sun, Jun 25, 2023 at 9:32 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> Sathyanarayanan Kuppuswamy wrote:
> >
> >
> > On 6/23/23 9:05 PM, Dan Williams wrote:
> > > Kuppuswamy Sathyanarayanan wrote:
> > >> Hi All,
> > >>
> > >> In TDX guest, the attestation process is used to verify the TDX guest
> > >> trustworthiness to other entities before provisioning secrets to the
> > >> guest.
> > >>
> > >> The TDX guest attestation process consists of two steps:
> > >>
> > >> 1. TDREPORT generation
> > >> 2. Quote generation.
> > >>
> > >> The First step (TDREPORT generation) involves getting the TDX guest
> > >> measurement data in the format of TDREPORT which is further used to
> > >> validate the authenticity of the TDX guest. The second step involves
> > >> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> > >> remotely verifiable Quote. TDREPORT by design can only be verified on
> > >> the local platform. To support remote verification of the TDREPORT,
> > >> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> > >> locally and convert it to a remotely verifiable Quote. Although
> > >> attestation software can use communication methods like TCP/IP or
> > >> vsock to send the TDREPORT to QE, not all platforms support these
> > >> communication models. So TDX GHCI specification [1] defines a method
> > >> for Quote generation via hypercalls. Please check the discussion from
> > >> Google [2] and Alibaba [3] which clarifies the need for hypercall based
> > >> Quote generation support. This patch set adds this support.
> > >>
> > >> Support for TDREPORT generation already exists in the TDX guest driver.
> > >> This patchset extends the same driver to add the Quote generation
> > >> support.
> > >
> > > I missed that the TDREPORT ioctl() and this character device are already
> > > upstream. The TDREPORT ioctl() if it is only needed for quote generation
> > > seems a waste because it just retrieves a blob that needs to be turned
> > > around and injected back into the kernel to generate a quote.
> >
> > Although the end goal is to generate the quote, the method the user chooses to
> > achieve it may differ for a variety of reasons. In this case, we're trying to
> > support the use case where the user will use methods like TCP/IP or vsock to
> > generate the Quote. They can use the GET_REPORT IOCTL to get the TDREPORT and
> > send it to the quoting enclave via the above-mentioned methods.  TDVMCALL-based
> > quote generation is intended for users who, for a variety of security reasons, do
> > not wish to use the methods described above.
>
> This flexibility could be supported with keys if necessary, although I
> would want to hear strong reasons not a "variety of reasons" why
> everyone cannot use a unified approach. ABI proliferation has a
> maintenance cost and a collaboration cost. It is within the kernel
> community's right to judge the cost of ABI flexibility and opt for a
> constrained implementation if that cost is too high.
>
> What I would ask of those who absolutely cannot support the TDVMCALL
> method is to contribute a solution that intercepts the "upcall" to the
> platform "guest_attest_ops" and turn it into a typical keys upcall to
> userspace that can use the report data with a vsock tunnel.
>
> That way the end result is still the same, a key established with the
> TDX Quote evidence contained within a Linux-defined envelope.

I agree a unified ABI across vendors would be ideal in the long term.
However, it sounds like a non-trivial task and could take quite some
time to achieve.
Given there's already an AMD equivalent approach upstreamed, can we
also allow this TDVMCALL patch as an intermediate step to unblock
various TDX attestation user cases while targeting unified ABI? The
TDVMCALL here is quite isolated and serves a very specific purpose, it
should be very low risk to other kernel features and easy to be
reverted in the future.

On Tue, Jun 27 2023 at 00:50, Chong Cai wrote:
> On Sun, Jun 25, 2023 at 9:32 PM Dan Williams <dan.j.williams@intel.com> wrote:
>> What I would ask of those who absolutely cannot support the TDVMCALL
>> method is to contribute a solution that intercepts the "upcall" to the
>> platform "guest_attest_ops" and turn it into a typical keys upcall to
>> userspace that can use the report data with a vsock tunnel.
>>
>> That way the end result is still the same, a key established with the
>> TDX Quote evidence contained within a Linux-defined envelope.
>
> I agree a unified ABI across vendors would be ideal in the long term.
> However, it sounds like a non-trivial task and could take quite some
> time to achieve.
> Given there's already an AMD equivalent approach upstreamed, can we
> also allow this TDVMCALL patch as an intermediate step to unblock
> various TDX attestation user cases while targeting unified ABI? The
> TDVMCALL here is quite isolated and serves a very specific purpose, it
> should be very low risk to other kernel features and easy to be
> reverted in the future.

No way. This is exactly how the kernel ends up with an unmaintainable
mess simply because this creates an user space ABI which is not
revertable ever.

It's bad enough that nobody paid attention when the AMD muck was merged,
but that does not make an argument or any form of justification to add
more of this.

Dan's proposal makes a lot of sense and allows to implement this in a
mostly vendor agnostic way. While the AMD interface is not going away
due to that, I'm 100% confident (pun intended) that such an unified
interface is going to be utilized and supported by AMD (or any other
vendor) sooner than later simply because the user space people who have
to implement vendor agnostic orchestration tools will go for it as it
makes their life easier too.

The time wasted to argue about this TDX ioctl mess could have been spent
to actually migrate TDX over to this scheme. But sure it's way simpler
to flog a dead horse instead of actually sitting down and getting useful
work done.

Thanks,

        tglx

Dan Williams wrote:
> Kuppuswamy Sathyanarayanan wrote:
> > Hi All,
> > 
> > In TDX guest, the attestation process is used to verify the TDX guest
> > trustworthiness to other entities before provisioning secrets to the
> > guest.
> > 
> > The TDX guest attestation process consists of two steps:
> > 
> > 1. TDREPORT generation
> > 2. Quote generation.
> > 
> > The First step (TDREPORT generation) involves getting the TDX guest
> > measurement data in the format of TDREPORT which is further used to
> > validate the authenticity of the TDX guest. The second step involves
> > sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> > remotely verifiable Quote. TDREPORT by design can only be verified on
> > the local platform. To support remote verification of the TDREPORT,
> > TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> > locally and convert it to a remotely verifiable Quote. Although
> > attestation software can use communication methods like TCP/IP or
> > vsock to send the TDREPORT to QE, not all platforms support these
> > communication models. So TDX GHCI specification [1] defines a method
> > for Quote generation via hypercalls. Please check the discussion from
> > Google [2] and Alibaba [3] which clarifies the need for hypercall based
> > Quote generation support. This patch set adds this support.
> > 
> > Support for TDREPORT generation already exists in the TDX guest driver. 
> > This patchset extends the same driver to add the Quote generation
> > support.
> 
> I missed that the TDREPORT ioctl() and this character device are already
> upstream. The TDREPORT ioctl() if it is only needed for quote generation
> seems a waste because it just retrieves a blob that needs to be turned
> around and injected back into the kernel to generate a quote.
> 
> An ABI wants to care about the abstractions around what the hardware
> mechanism enables. The TD quote is not even at the end of that chain of
> what the ABI needs to offer. The guest wants to use the TD quote to access
> / unlock other resources, just like the SEV report is used to
> "...provide the VM with secrets, such as a disk decryption key, or other
> keys required for operation".
> 
> That's where the ABI line needs to be drawn. I.e. for the guest to be
> able to request the distributions of keys to unlock resources by a
> key-type and key-descriptor. Enable userspace to interrogate an
> attestation object without blobs needing to traverse the kernel. If the
> remote service needs more than just a blob and signature to validate the
> state of the guest then provide faclity to interrogate that property of
> quote / report in a common way versus the ABI risk of conveying vendor
> specific binary data formats in the kernel ABI.

A proposal for how this space moves forward:

1/ Stop accepting new arch specific ioctls in this space and revert the
   Intel TDREPORT ioctl if its only reason for existing is "quote"
   generation.

2/ Define a container format / envelope for platform-provided
   attestation evidence.

   The observation here is that although it is too late to unify the
   evidence formats across vendors, they appear to share the common form of
   a blob with an ECDSA signature. That reduces the minimum viable
   attestation service to something that can generically verify an
   evidence-blob signature.

3/ Define a key-description format that considers a superset of the
   platform needs. For example a 'privelege-level' concept can map to
   'vmpl' on AMD, but be ignored for now for Intel.

4/ For in progress enabling concepts like runtime measurement registers,
   look to reuse / abstract that behind the Keys subsystem existing support
   for managing TPM PCRs.

5/ Deprecate the multiple arch specific attestation ioctl interfaces in
   favor of this unified conveyance method.

Tested-by: Qinkun Bao <qinkun@google.com>

Thanks Sathyanarayanan for the new patch! This patch is critical for
our use case.
We built a guest image with the patch, and verified it works for us,
when using a host kernel built with https://github.com/intel/tdx repo.

On Sun, May 14, 2023 at 12:24 AM Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>
> Hi All,
>
> In TDX guest, the attestation process is used to verify the TDX guest
> trustworthiness to other entities before provisioning secrets to the
> guest.
>
> The TDX guest attestation process consists of two steps:
>
> 1. TDREPORT generation
> 2. Quote generation.
>
> The First step (TDREPORT generation) involves getting the TDX guest
> measurement data in the format of TDREPORT which is further used to
> validate the authenticity of the TDX guest. The second step involves
> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> remotely verifiable Quote. TDREPORT by design can only be verified on
> the local platform. To support remote verification of the TDREPORT,
> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> locally and convert it to a remotely verifiable Quote. Although
> attestation software can use communication methods like TCP/IP or
> vsock to send the TDREPORT to QE, not all platforms support these
> communication models. So TDX GHCI specification [1] defines a method
> for Quote generation via hypercalls. Please check the discussion from
> Google [2] and Alibaba [3] which clarifies the need for hypercall based
> Quote generation support. This patch set adds this support.
>
> Support for TDREPORT generation already exists in the TDX guest driver.
> This patchset extends the same driver to add the Quote generation
> support.
>
> Following are the details of the patch set:
>
> Patch 1/3 -> Adds event notification IRQ support.
> Patch 2/3 -> Adds Quote generation support.
> Patch 3/3 -> Adds selftest support for Quote generation feature.
>
> [1] https://cdrdv2.intel.com/v1/dl/getContent/726790, section titled "TDG.VP.VMCALL<GetQuote>".
> [2] https://lore.kernel.org/lkml/CAAYXXYxxs2zy_978GJDwKfX5Hud503gPc8=1kQ-+JwG_kA79mg@mail.gmail.com/
> [3] https://lore.kernel.org/lkml/a69faebb-11e8-b386-d591-dbd08330b008@linux.alibaba.com/
>
> Kuppuswamy Sathyanarayanan (3):
>   x86/tdx: Add TDX Guest event notify interrupt support
>   virt: tdx-guest: Add Quote generation support
>   selftests/tdx: Test GetQuote TDX attestation feature
>
>  Documentation/virt/coco/tdx-guest.rst        |  11 ++
>  arch/x86/coco/tdx/tdx.c                      | 194 +++++++++++++++++++
>  arch/x86/include/asm/tdx.h                   |   8 +
>  drivers/virt/coco/tdx-guest/tdx-guest.c      | 175 ++++++++++++++++-
>  include/uapi/linux/tdx-guest.h               |  44 +++++
>  tools/testing/selftests/tdx/tdx_guest_test.c |  65 ++++++-
>  6 files changed, 490 insertions(+), 7 deletions(-)
>
> --
> 2.34.1
>

Hi,

On 5/24/23 2:33 PM, Chong Cai wrote:
> Tested-by: Qinkun Bao <qinkun@google.com>
> 
> Thanks Sathyanarayanan for the new patch! This patch is critical for
> our use case.
> We built a guest image with the patch, and verified it works for us,
> when using a host kernel built with https://github.com/intel/tdx repo.

Qinkun Bao/Chong Cai, thanks for testing it. I really appreciate the help.

Dave/Boris, could you please take a look at this patch set?

> 
> On Sun, May 14, 2023 at 12:24 AM Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>>
>> Hi All,
>>
>> In TDX guest, the attestation process is used to verify the TDX guest
>> trustworthiness to other entities before provisioning secrets to the
>> guest.
>>
>> The TDX guest attestation process consists of two steps:
>>
>> 1. TDREPORT generation
>> 2. Quote generation.
>>
>> The First step (TDREPORT generation) involves getting the TDX guest
>> measurement data in the format of TDREPORT which is further used to
>> validate the authenticity of the TDX guest. The second step involves
>> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
>> remotely verifiable Quote. TDREPORT by design can only be verified on
>> the local platform. To support remote verification of the TDREPORT,
>> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
>> locally and convert it to a remotely verifiable Quote. Although
>> attestation software can use communication methods like TCP/IP or
>> vsock to send the TDREPORT to QE, not all platforms support these
>> communication models. So TDX GHCI specification [1] defines a method
>> for Quote generation via hypercalls. Please check the discussion from
>> Google [2] and Alibaba [3] which clarifies the need for hypercall based
>> Quote generation support. This patch set adds this support.
>>
>> Support for TDREPORT generation already exists in the TDX guest driver.
>> This patchset extends the same driver to add the Quote generation
>> support.
>>
>> Following are the details of the patch set:
>>
>> Patch 1/3 -> Adds event notification IRQ support.
>> Patch 2/3 -> Adds Quote generation support.
>> Patch 3/3 -> Adds selftest support for Quote generation feature.
>>
>> [1] https://cdrdv2.intel.com/v1/dl/getContent/726790, section titled "TDG.VP.VMCALL<GetQuote>".
>> [2] https://lore.kernel.org/lkml/CAAYXXYxxs2zy_978GJDwKfX5Hud503gPc8=1kQ-+JwG_kA79mg@mail.gmail.com/
>> [3] https://lore.kernel.org/lkml/a69faebb-11e8-b386-d591-dbd08330b008@linux.alibaba.com/
>>
>> Kuppuswamy Sathyanarayanan (3):
>>   x86/tdx: Add TDX Guest event notify interrupt support
>>   virt: tdx-guest: Add Quote generation support
>>   selftests/tdx: Test GetQuote TDX attestation feature
>>
>>  Documentation/virt/coco/tdx-guest.rst        |  11 ++
>>  arch/x86/coco/tdx/tdx.c                      | 194 +++++++++++++++++++
>>  arch/x86/include/asm/tdx.h                   |   8 +
>>  drivers/virt/coco/tdx-guest/tdx-guest.c      | 175 ++++++++++++++++-
>>  include/uapi/linux/tdx-guest.h               |  44 +++++
>>  tools/testing/selftests/tdx/tdx_guest_test.c |  65 ++++++-
>>  6 files changed, 490 insertions(+), 7 deletions(-)
>>
>> --
>> 2.34.1
>>

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer