linux-kernel - Re: [PATCH v19 116/130] KVM: TDX: Silently discard SMI request

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: <ZiJ3Krs_HoqdfyWN@google.com>
Date: Fri, 19 Apr 2024 06:52:42 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: isaku.yamahata@...el.com
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com, 
	Sagi Shahar <sagis@...gle.com>, Kai Huang <kai.huang@...el.com>, chen.bo@...el.com, 
	hang.yuan@...el.com, tina.zhang@...el.com
Subject: Re: [PATCH v19 116/130] KVM: TDX: Silently discard SMI request

On Mon, Feb 26, 2024, isaku.yamahata@...el.com wrote:
> From: Isaku Yamahata <isaku.yamahata@...el.com>
> 
> TDX doesn't support system-management mode (SMM) and system-management
> interrupt (SMI) in guest TDs.  Because guest state (vcpu state, memory
> state) is protected, it must go through the TDX module APIs to change guest
> state, injecting SMI and changing vcpu mode into SMM.  The TDX module
> doesn't provide a way for VMM to inject SMI into guest TD and a way for VMM
> to switch guest vcpu mode into SMM.
> 
> We have two options in KVM when handling SMM or SMI in the guest TD or the
> device model (e.g. QEMU): 1) silently ignore the request or 2) return a
> meaningful error.
> 
> For simplicity, we implemented the option 1).
>
> Signed-off-by: Isaku Yamahata <isaku.yamahata@...el.com>
> ---
>  arch/x86/kvm/smm.h         |  7 +++++-
>  arch/x86/kvm/vmx/main.c    | 45 ++++++++++++++++++++++++++++++++++----
>  arch/x86/kvm/vmx/tdx.c     | 29 ++++++++++++++++++++++++
>  arch/x86/kvm/vmx/x86_ops.h | 12 ++++++++++
>  4 files changed, 88 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kvm/smm.h b/arch/x86/kvm/smm.h
> index a1cf2ac5bd78..bc77902f5c18 100644
> --- a/arch/x86/kvm/smm.h
> +++ b/arch/x86/kvm/smm.h
> @@ -142,7 +142,12 @@ union kvm_smram {
>  
>  static inline int kvm_inject_smi(struct kvm_vcpu *vcpu)
>  {
> -	kvm_make_request(KVM_REQ_SMI, vcpu);
> +	/*
> +	 * If SMM isn't supported (e.g. TDX), silently discard SMI request.
> +	 * Assume that SMM supported = MSR_IA32_SMBASE supported.
> +	 */
> +	if (static_call(kvm_x86_has_emulated_msr)(vcpu->kvm, MSR_IA32_SMBASE))
> +		kvm_make_request(KVM_REQ_SMI, vcpu);
>  	return 0;

No, just do what KVM already does for CONFIG_KVM_SMM=n, and return -ENOTTY.  The
*entire* point of have a return code is to handle setups that don't support SMM.

	if (!static_call(kvm_x86_has_emulated_msr)(vcpu->kvm, MSR_IA32_SMBASE)))
		return -ENOTTY;

And with that, I would drop the comment, it's pretty darn clear what "assumption"
is being made.  In quotes because it's not an assumption, it's literally KVM's
implementation.

And then the changelog can say "do what KVM does for CONFIG_KVM_SMM=n" without
having to explain why we decided to do something completely arbitrary for TDX.

>  }
>  
> diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c
> index ed46e7e57c18..4f3b872cd401 100644
> --- a/arch/x86/kvm/vmx/main.c
> +++ b/arch/x86/kvm/vmx/main.c
> @@ -283,6 +283,43 @@ static void vt_msr_filter_changed(struct kvm_vcpu *vcpu)
>  	vmx_msr_filter_changed(vcpu);
>  }
>  
> +#ifdef CONFIG_KVM_SMM
> +static int vt_smi_allowed(struct kvm_vcpu *vcpu, bool for_injection)
> +{
> +	if (is_td_vcpu(vcpu))
> +		return tdx_smi_allowed(vcpu, for_injection);

Adding stubs for something that TDX will never support is silly.  Bug the VM and
return an error.

	if (KVM_BUG_ON(is_td_vcpu(vcpu)))
		return -EIO;

And I wouldn't even bother with vt_* wrappers, just put that right in vmx_*().
Same thing for everything below.