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: <d7a0ed833909551c24bf1c2c52b8955d75359249.camel@intel.com>
Date: Thu, 28 Mar 2024 01:06:07 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Gao, Chao" <chao.gao@...el.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.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@...ux.intel.com"
	<isaku.yamahata@...ux.intel.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>, "Yuan,
 Hang" <hang.yuan@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for
 unsupported cases

On Thu, 2024-03-28 at 08:58 +0800, Xiaoyao Li wrote:
> > How so? Userspace needs to learn to create a TD first.
> 
> The current ABI of KVM_EXIT_X86_RDMSR/WRMSR is that userspace itself 
> sets up MSR fitler at first, then it will get such EXIT_REASON when 
> guest accesses the MSRs being filtered.
> 
> If you want to use this EXIT reason, then you need to enforce userspace 
> setting up the MSR filter. How to enforce?

I think Isaku's proposal was to let userspace configure it.

For the sake of conversation, what if we don't enforce it? The downside of not enforcing it is that
we then need to worry about code paths in KVM the MTRRs would call. But what goes wrong
functionally? If userspace doesn't fully setup a TD things can go wrong for the TD.

A plus side of using the MSR filter stuff is it reuses existing functionality.

>  If not enforce, but exit with 
> KVM_EXIT_X86_RDMSR/WRMSR no matter usersapce sets up MSR filter or not. 
> Then you are trying to introduce divergent behavior in KVM.

The current ABI of KVM_EXIT_X86_RDMSR when TDs are created is nothing. So I don't see how this is
any kind of ABI break. If you agree we shouldn't try to support MTRRs, do you have a different exit
reason or behavior in mind?