linux-kernel - Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases

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: <20db87741e356e22a72fadeda8ab982260f26705.camel@intel.com>
Date: Tue, 26 Mar 2024 02:42:36 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "isaku.yamahata@...ux.intel.com"
	<isaku.yamahata@...ux.intel.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"Huang, Kai" <kai.huang@...el.com>, "Chen, Bo2" <chen.bo@...el.com>,
	"sagis@...gle.com" <sagis@...gle.com>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Yuan, Hang" <hang.yuan@...el.com>,
	"sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>
Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for
 unsupported cases

On Tue, 2024-03-26 at 10:32 +0800, Chao Gao wrote:
> > > > Something like this for "112/130 KVM: TDX: Handle TDX PV rdmsr/wrmsr hypercall"
> > > > Compile only tested at this point.
> > > 
> > > Seems reasonable to me. Does QEMU configure a special set of MSRs to filter for TDX currently?
> > 
> > No for TDX at the moment.  We need to add such logic.
> 
> What if QEMU doesn't configure the set of MSRs to filter? In this case, KVM
> still needs to handle the MSR accesses.

Do you see a problem for the kernel? I think if any issues are limited to only the guest, then we
should count on userspace to configure the msr list.

Today if the MSR access is not allowed by the filter, or the MSR access otherwise fails, an error is
returned to the guest. I think Isaku's proposal is to return to userspace if the filter list fails,
and return an error to the guest if the access otherwise fails. So the accessible MSRs are the same.
It's just change in how error is reported.