linux-kernel - Re: [PATCH v14 11/22] KVM: VMX: Emulate read and write to CET MSRs

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: <aMMv7bAMBWu-0ZhQ@google.com>
Date: Thu, 11 Sep 2025 13:24:13 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	acme@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com, 
	john.allen@....com, mingo@...nel.org, mingo@...hat.com, 
	minipli@...ecurity.net, mlevitsk@...hat.com, namhyung@...nel.org, 
	pbonzini@...hat.com, prsampat@....com, rick.p.edgecombe@...el.com, 
	shuah@...nel.org, tglx@...utronix.de, weijiang.yang@...el.com, x86@...nel.org, 
	xin@...or.com
Subject: Re: [PATCH v14 11/22] KVM: VMX: Emulate read and write to CET MSRs

On Thu, Sep 11, 2025, Chao Gao wrote:
> On Thu, Sep 11, 2025 at 04:05:23PM +0800, Xiaoyao Li wrote:
> >On 9/9/2025 5:39 PM, Chao Gao wrote:
> >> From: Yang Weijiang <weijiang.yang@...el.com>
> >> 
> >> Add emulation interface for CET MSR access. The emulation code is split
> >> into common part and vendor specific part. The former does common checks
> >> for MSRs, e.g., accessibility, data validity etc., then passes operation
> >> to either XSAVE-managed MSRs via the helpers or CET VMCS fields.
> >
> >I planed to continue the review after Sean posts v15 as he promised.
> >But I want to raise my question regarding it sooner so I just ask it on v14.
> >
> >Do we expect to put the accessibility and data validity check always in
> >__kvm_{s,g}_msr(), when the handling cannot be put in kvm_{g,s}et_common()
> >only? i.e., there will be 3 case:
> 
> For checks that are shared between VMX/SVM, I think yes and there is no other
> sensible choice to me; other options just cause code duplication.

+1.  Put as much emulation as possible into x86.c, e.g. validity checks, state
tracking, etc.  Ideally, the only thing in vendor code is vendor specific, e.g.
checks that are unique such as CR4.VMXE interactions, and propagation to/from
the VMCS/VMCB.  See also https://lore.kernel.org/all/aLDm9YID-r5WWcD9@google.com.

> For checks that are not common, we have to put them into vendor code.
> 
> >
> >- All the handling in kvm_{g,s}et_common(), when the MSR emulation is common
> >to vmx and svm.
> >
> >- generic accessibility and data validity check in __kvm_{g,s}et_msr() and
> >vendor specific handling in {vmx,svm}_{g,s}et_msr()
> >
> >- generic accessibility and data validity check in __kvm_{g,s}et_msr() ,
> >vendor specific handling in {vmx,svm}_{g,s}et_msr() and other generic
> >handling in kvm_{g,s}et_common()