Re: [PATCH v2 11/17] x86/virt/tdx: Add interface to generate a Quote

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tdx_quote_generate() uses an uninterruptible mutex lock for a guest-triggered hardware operation, creating a potential host-level denial of service.
--

commit 3bb73b03a2480c47534841c05b531b06bda047a9
Author: Peter Fang <peter.fang@intel.com>

x86/virt/tdx: Add interface to generate a Quote

This commit provides an interface to generate a Quote via the TDH.QUOTE.GET
Extension-SEAMCALL. It introduces a global mutex to serialize access to a
shared quote buffer.

> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c

[ ... ]

> +void *tdx_quote_generate(struct tdx_td *td, void *in_data, u32 in_data_len,
> +			 u32 *quote_len)
> +{
> +	struct tdx_quote_data *qdata = &tdx_quote;
> +	void *quote_dup = NULL;
> +	u64 r, out_len;
> +
> +	if (!tdx_quote_enabled())
> +		return NULL;
> +
> +	mutex_lock(&tdx_quote_lock);

[Severity: High]
Since this path can be triggered by a guest, could using an uninterruptible
mutex_lock() here lead to a host-level denial of service?

If a guest rapidly requests quotes from multiple vCPUs, it could monopolize
the global tdx_quote_lock. Other vCPU threads waiting for the lock would
block in an uninterruptible sleep (D state). If an administrator attempts
to kill the waiting VMs, the threads will not respond to fatal signals until
they acquire the lock.

Would it be safer to use mutex_lock_killable() here to allow fatal signals
to interrupt the wait and permit VM teardown?

> +
> +	/*
> +	 * Use the first page of the quote buffer for input data. The buffer
> +	 * must be at least one page in size. @in_data may not be page-aligned,
> +	 * but TDH.QUOTE.GET expects page-aligned addresses.
> +	 */
> +	memcpy(qdata->buf, in_data, in_data_len);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618081355.3253581-1-yilun.xu@linux.intel.com?part=11