Re: [PATCH v3 4/6] x86/virt/tdx: Make TDX module initialize the extensions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] x86/tdx: missing cache flush for extension memory before TDH_EXT_MEM_ADD
--

commit 218ae840fc4855126ea1a0f203de6a4e414fa8d7
Author: Xu Yilun <yilun.xu@linux.intel.com>

x86/virt/tdx: Make TDX module initialize the extensions

TDX module extensions need memory for their execution environment
to serve SEAMCALL leafs. Several add-on features depend on the
extensions to execute their SEAMCALL leafs.

After providing all required memory to the TDX module, initialize TDX
module extensions via TDH.EXT.INIT, then those add-on features can use
their SEAMCALL leafs normally.

> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index c445359335516..d8df3b2b1d17d 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1348,12 +1348,35 @@ static __init int tdx_ext_mem_setup(void)
[ ... ]
>  static __init int init_tdx_module_extensions(void)
>  {
> +	int ret;
> +
>  	if (!(tdx_sysinfo.features.tdx_features0 & TDX_FEATURES0_EXT))
>  		return 0;
>  
> -	return tdx_ext_mem_setup();
> +	ret = tdx_ext_mem_setup();

[Severity: High]
Does tdx_ext_mem_setup() need to explicitly flush the extension memory cache
lines?

During TDX module initialization, a global cache flush (wbinvd_on_all_cpus())
is performed via config_global_keyid(). After this global flush,
init_tdx_module_extensions() is called, allocating memory via
alloc_contig_pages() in tdx_ext_mem_setup().

Because this memory is allocated after the wbinvd, it may contain dirty cache
lines. The pages are then passed to tdx_ext_mem_add() without an explicit
cache flush (such as tdx_clflush_page()):

arch/x86/virt/vmx/tdx/tdx.c:tdx_ext_mem_setup() {
    ...
		for (i = 0; i < chunk_pages; i++)
			hpa_list->phys[i] = page_to_phys(chunk + i);

		ret = tdx_ext_mem_add(hpa_list, chunk_pages);
    ...
}

Could missing cache flushes when transferring memory from the host (KeyID 0)
to the TDX module (which uses the global private KeyID) cause MKTME KeyID
aliasing MCEs? If dirty cache lines associated with KeyID 0 remain in the CPU
caches and are later evicted, they could corrupt the TDX module's private
memory.

> +	if (ret)
> +		return ret;
> +
> +	return tdx_ext_init();
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006-tdx-module-ext-v3-0-db52cb05b918@linux.intel.com?part=4