linux-kernel - Re: [PATCH v19 105/130] KVM: TDX: handle KVM hypercall with TDG.VP.VMCALL

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: <20240528171612.GA454482@ls.amr.corp.intel.com>
Date: Tue, 28 May 2024 10:16:12 -0700
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
Cc: Isaku Yamahata <isaku.yamahata@...el.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Sean Christopherson <seanjc@...gle.com>,
	Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, isaku.yamahata@...il.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,
	isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH v19 105/130] KVM: TDX: handle KVM hypercall with
 TDG.VP.VMCALL

On Mon, May 27, 2024 at 08:57:28AM +0800,
Binbin Wu <binbin.wu@...ux.intel.com> wrote:

> 
> 
> On 4/17/2024 3:02 PM, Isaku Yamahata wrote:
> > On Wed, Apr 17, 2024 at 02:16:57PM +0800,
> > Binbin Wu <binbin.wu@...ux.intel.com> wrote:
> > 
> > > 
> > > On 4/4/2024 9:27 AM, Isaku Yamahata wrote:
> > > > On Tue, Apr 02, 2024 at 04:52:46PM +0800,
> > > > Chao Gao <chao.gao@...el.com> wrote:
> > > > 
> > > > > > +static int tdx_emulate_vmcall(struct kvm_vcpu *vcpu)
> > > > > > +{
> > > > > > +	unsigned long nr, a0, a1, a2, a3, ret;
> > > > > > +
> > > > > do you need to emulate xen/hyper-v hypercalls here?
> > > > No. kvm_emulate_hypercall() handles xen/hyper-v hypercalls,
> > > > __kvm_emulate_hypercall() doesn't.
> > > So for TDX, kvm doesn't support xen/hyper-v, right?
> > > 
> > > Then, should KVM_CAP_XEN_HVM and KVM_CAP_HYPERV be filtered out for TDX?
> > That's right. We should update kvm_vm_ioctl_check_extension() and
> > kvm_vcpu_ioctl_enable_cap().  I didn't pay attention to them.
> Currently, QEMU checks the capabilities for Hyper-v/Xen via
> kvm_check_extension(), which is the global version.
> Only modifications in KVM can't hide these capabilities. It needs userspace
> to use VM or vCPU version to check the capabilities for Hyper-v and Xen.
> Is it a change of ABI when the old global version is still workable, but
> userspace switches to use VM/vCPU version to check capabilities for Hyper-v
> and Xen?
> Are there objections if both QEMU and KVM are modified in order to
> hide Hyper-v/Xen capabilities for TDX?

I think it's okay for KVM_X86_TDX_VM as long as we don't change the value for
KVM_X86_DEFAULT_VM.  Because vm_type KVM_X86_TDX_VM is different from the
default and the document (Documentation/virt/kvm/api.rst), 4.4
KVM_CHECK_EXTENSION explicitly encourages VM version.

  Based on their initialization different VMs may have different capabilities.
  It is thus encouraged to use the vm ioctl to query for capabilities (available
  with KVM_CAP_CHECK_EXTENSION_VM on the vm fd)

The change to qemu will be mostly trivial with the quick check.
-- 
Isaku Yamahata <isaku.yamahata@...el.com>