linux-kernel - Re: [PATCH v16 24/51] KVM: nVMX: Always forward XSAVES/XRSTORS exits from L2 to L1

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: <ae21938a-3db9-47c9-b8e6-85a497cde195@intel.com>
Date: Tue, 23 Sep 2025 22:49:34 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Tom Lendacky <thomas.lendacky@....com>,
 Mathias Krause <minipli@...ecurity.net>, John Allen <john.allen@....com>,
 Rick Edgecombe <rick.p.edgecombe@...el.com>, Chao Gao <chao.gao@...el.com>,
 Binbin Wu <binbin.wu@...ux.intel.com>, Maxim Levitsky <mlevitsk@...hat.com>,
 Zhang Yi Z <yi.z.zhang@...ux.intel.com>, Xin Li <xin@...or.com>
Subject: Re: [PATCH v16 24/51] KVM: nVMX: Always forward XSAVES/XRSTORS exits
 from L2 to L1

On 9/20/2025 6:32 AM, Sean Christopherson wrote:
> Unconditionally forward XSAVES/XRSTORS VM-Exits from L2 to L1, as KVM
> doesn't utilize the XSS-bitmap (KVM relies on controlling the XSS value
> in hardware to prevent unauthorized access to XSAVES state).  KVM always
> loads vmcs02 with vmcs12's bitmap, and so any exit _must_ be due to
> vmcs12's XSS-bitmap.
> 
> Drop the comment about XSS never being non-zero in anticipation of
> enabling CET_KERNEL and CET_USER support.
> 
> Opportunistically WARN if XSAVES is not enabled for L2, as the CPU is
> supposed to generate #UD before checking the XSS-bitmap.
> 
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>

Reviewed-by: Xiaoyao Li <xiaoyao.li@...el.com>

> ---
>   arch/x86/kvm/vmx/nested.c | 15 +++++++++------
>   1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 2156c9a854f4..846c07380eac 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -6570,14 +6570,17 @@ static bool nested_vmx_l1_wants_exit(struct kvm_vcpu *vcpu,
>   		return nested_cpu_has2(vmcs12, SECONDARY_EXEC_WBINVD_EXITING);
>   	case EXIT_REASON_XSETBV:
>   		return true;
> -	case EXIT_REASON_XSAVES: case EXIT_REASON_XRSTORS:
> +	case EXIT_REASON_XSAVES:
> +	case EXIT_REASON_XRSTORS:
>   		/*
> -		 * This should never happen, since it is not possible to
> -		 * set XSS to a non-zero value---neither in L1 nor in L2.
> -		 * If if it were, XSS would have to be checked against
> -		 * the XSS exit bitmap in vmcs12.
> +		 * Always forward XSAVES/XRSTORS to L1 as KVM doesn't utilize
> +		 * XSS-bitmap, and always loads vmcs02 with vmcs12's XSS-bitmap
> +		 * verbatim, i.e. any exit is due to L1's bitmap.  WARN if
> +		 * XSAVES isn't enabled, as the CPU is supposed to inject #UD
> +		 * in that case, before consulting the XSS-bitmap.
>   		 */
> -		return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_XSAVES);
> +		WARN_ON_ONCE(!nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_XSAVES));
> +		return true;
>   	case EXIT_REASON_UMWAIT:
>   	case EXIT_REASON_TPAUSE:
>   		return nested_cpu_has2(vmcs12,