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: <20240402070921.GZ2444378@ls.amr.corp.intel.com>
Date: Tue, 2 Apr 2024 00:09:21 -0700
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: Chao Gao <chao.gao@...el.com>
Cc: isaku.yamahata@...el.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, isaku.yamahata@...il.com,
	Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com,
	Sean Christopherson <seanjc@...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,
	isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH v19 094/130] KVM: TDX: Implement methods to inject NMI

On Fri, Mar 29, 2024 at 10:11:05AM +0800,
Chao Gao <chao.gao@...el.com> wrote:

> >+static void vt_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked)
> >+{
> >+	if (is_td_vcpu(vcpu))
> >+		return;
> >+
> >+	vmx_set_nmi_mask(vcpu, masked);
> >+}
> >+
> >+static void vt_enable_nmi_window(struct kvm_vcpu *vcpu)
> >+{
> >+	/* Refer the comment in vt_get_nmi_mask(). */
> >+	if (is_td_vcpu(vcpu))
> >+		return;
> >+
> >+	vmx_enable_nmi_window(vcpu);
> >+}
> 
> The two actually request something to do done for the TD. But we make them nop
> as TDX module doesn't support VMM to configure nmi mask and nmi window. Do you
> think they are worth a WARN_ON_ONCE()? or adding WARN_ON_ONCE() requires a lot
> of code factoring in KVM's NMI injection logics?

Because user space can reach those hooks with KVM_SET_VCPU_EVENTS, we shouldn't
add WARN_ON_ONCE().  There are two choices.  Ignore the request (the current
choice) or return error for unsupported request.

It's troublesome to allow error for them because we have to fix up the caller
up to the user space.  The user space may abort on such error without fix.
-- 
Isaku Yamahata <isaku.yamahata@...el.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ