[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <369b819c-5235-424d-a8c9-c7c45a9fd4db@linux.intel.com>
Date: Tue, 2 Dec 2025 16:00:58 -0800
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>, "Kirill A . Shutemov"
<kas@...nel.org>
Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev
Subject: Re: [PATCH v5] virt: tdx-guest: Handle GetQuote request error code
Hi Dave,
Thanks for the review.
On 12/2/2025 2:46 PM, Dave Hansen wrote:
> On 12/2/25 14:22, Kuppuswamy Sathyanarayanan wrote:
>> The tdx-guest driver sends Quote requests to the quoting enclave via a
>> hypercall to obtain attestation evidence for the current TD state.
>> Quote generation can fail in two ways: a hypercall failure, or a Quote
>> failure that occurs after the VMM processes the request. The driver
>> currently handles only hypercall failures and timeout errors during
>> Quote processing. Update it to also handle other Quote failures
>> reported by the VMM (for more details, refer to GHCI spec, v1.5,
>> March 2023, sec titled "TDG.VP.VMCALL<GetQuote>).
>
> I think you're talking about the "GetQuote Status Code" here, right?
> That would have been nice to mention. It wasn't exactly trivial to find
> because instead of saying what the format of a TDREPORT_STRUCT is, the
> docs just call it "format of shared GPA".
Yes, that's correct. I am referring to the GetQuote Status Code returned
by TDG.VP.VMCALL<GetQuote>, specifically the error codes that were not
previously checked (GET_QUOTE_ERROR and GET_QUOTE_SERVICE_UNAVAILABLE).
For clarity, I will update the commit description to explicitly refer to
status code table — Table 3-11: TDG.VP.VMCALL<GetQuote> – GetQuote Status
Code.
>
>> This change does not break the existing ABI behavior. When a Quote
>> failure occurs, the VMM sets the Quote length to zero. Userspace
>> already interprets a zero-length Quote as a Quote generation failure.
>> Returning an explicit error in such cases makes the behavior more
>> consistent and simplifies error handling in userspace.
> I'm also not seeing a clear problem statement here. What is the end user
> visible effect of this "fix"? Why *should* the kernel be parsing this
> buffer? Why not not just leave the error handling to userspace?
The issue is that, prior to this patch, the kernel silently returned
success for certain Quote failure cases such as when the Quote service
is unavailable or when the VMM reports a processing error. In these
cases, the Quote buffer ends up being empty and userspace is expected
to infer failure indirectly by checking for a zero length Quote. This
behavior is ambiguous and has caused confusion in practice, as reported
in: https://github.com/confidential-containers/guest-components/issues/823
With this patch, all VMM reported Quote failures are explicitly
translated into kernel error returns. This makes failure detection
uniform and simplifies userspace error handling.
The reason the kernel must parse the status field is that the failure
code is only available in the header portion of the shared GPA buffer
populated by the VMM. Userspace currently does not have access to this
header since we only expose the Quote payload itself. Because userspace
cannot directly interpret the VMM status codes, the kernel needs to parse
them and return appropriate generic error codes.
>
>> Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS")
>> Reported-by: Xiaoyao Li <xiaoyao.li@...el.com>
>> Closes: https://lore.kernel.org/linux-coco/6bdf569c-684a-4459-af7c-4430691804eb@linux.intel.com/T/#u
>> Closes: https://github.com/confidential-containers/guest-components/issues/823
>> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
>> Reviewed-by: Xiaoyao Li <xiaoyao.li@...el.com>
>> Acked-by: Kai Huang <kai.huang@...el.com>
>> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
>> Tested-by: Mikko Ylinen <mikko.ylinen@...ux.intel.com>
>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
>
> Please take a look at:
>
> https://docs.kernel.org/process/maintainer-tip.html#ordering-of-commit-tags
>
Thanks for pointing this out. I will reorder the commit tags in the next revision.
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Powered by blists - more mailing lists