linux-kernel - Re: [RFC PATCH 03/20] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d1ec91ad-b368-4993-aadb-18af489ea87e@suse.com>
Date: Tue, 3 Jun 2025 14:22:20 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Chao Gao <chao.gao@...el.com>, linux-coco@...ts.linux.dev,
 x86@...nel.org, kvm@...r.kernel.org
Cc: seanjc@...gle.com, pbonzini@...hat.com, eddie.dong@...el.com,
 kirill.shutemov@...el.com, dave.hansen@...el.com, dan.j.williams@...el.com,
 kai.huang@...el.com, isaku.yamahata@...el.com, elena.reshetova@...el.com,
 rick.p.edgecombe@...el.com, Farrah Chen <farrah.chen@...el.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/20] x86/virt/seamldr: Introduce a wrapper for
 P-SEAMLDR SEAMCALLs



On 5/23/25 12:52, Chao Gao wrote:
> P-SEAMLDR is another component alongside the TDX module within the
> protected SEAM range. Software can invoke its functions by executing the
> SEAMCALL instruction with the 63 bit of RAX set to 1. P-SEAMLDR SEAMCALLs
> differ from those of the TDX module in terms of error codes and the
> handling of the current VMCS.
> 
> Add a wrapper for P-SEAMLDR SEAMCALLs based on the SEAMCALL infrastructure.
> 
> Intel® Trust Domain CPU Architectural Extensions (May 2021 edition)
> Chapter 2.3 states:
> 
> SEAMRET from the P-SEAMLDR clears the current VMCS structure pointed to by
> the current-VMCS pointer. A VMM that invokes the P-SEAMLDR using SEAMCALL
> must reload the current-VMCS, if required, using the VMPTRLD instruction.
> 
> So, save and restore the current-VMCS pointer using VMPTRST and VMPTRLD
> instructions to avoid breaking KVM, which manages the current-VMCS.
> 
> Disable interrupts to prevent KVM code from interfering with P-SEAMLDR
> SEAMCALLs. For example, if a vCPU is scheduled before the current VMCS is
> restored, it may encounter an invalid current VMCS, causing its VMX
> instruction to fail. Additionally, if KVM sends IPIs to invalidate a
> current VMCS and the invalidation occurs right after the current VMCS is
> saved, that VMCS will be reloaded after P-SEAMLDR SEAMCALLs, leading to
> unexpected behavior.
> 
> NMIs are not a problem, as the only scenario where instructions relying on
> the current-VMCS are used is during guest PMI handling in KVM. This occurs
> immediately after VM exits with IRQ and NMI disabled, ensuring no
> interference with P-SEAMLDR SEAMCALLs.
> 
> Signed-off-by: Chao Gao <chao.gao@...el.com>
> Tested-by: Farrah Chen <farrah.chen@...el.com>
> ---
>   arch/x86/Kconfig                | 10 ++++++++
>   arch/x86/virt/vmx/tdx/Makefile  |  1 +
>   arch/x86/virt/vmx/tdx/seamldr.c | 44 +++++++++++++++++++++++++++++++++
>   arch/x86/virt/vmx/vmx.h         | 40 ++++++++++++++++++++++++++++++
>   4 files changed, 95 insertions(+)
>   create mode 100644 arch/x86/virt/vmx/tdx/seamldr.c
>   create mode 100644 arch/x86/virt/vmx/vmx.h
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 4b9f378e05f6..8b1e0986b7f8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1932,6 +1932,16 @@ config INTEL_TDX_HOST
>   
>   	  If unsure, say N.
>   
> +config INTEL_TDX_MODULE_UPDATE
> +	bool "Intel TDX module runtime update"
> +	depends on INTEL_TDX_HOST
> +	help
> +	  This enables the kernel to support TDX module runtime update. This allows
> +	  the admin to upgrade the TDX module to a newer one without the need to
> +	  terminate running TDX guests.
> +
> +	  If unsure, say N.
> +

WHy should this be conditional?