linux-kernel - Re: [PATCH v3 4/6] KVM: x86: Add support for RDMSR/WRMSRNS w/ immediate on Intel

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] [day] [month] [year] [list]

Message-ID: <aMxQkRhuEi-SduTH@google.com>
Date: Thu, 18 Sep 2025 11:33:53 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>
Cc: Xin Li <xin@...or.com>, Binbin Wu <binbin.wu@...ux.intel.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v3 4/6] KVM: x86: Add support for RDMSR/WRMSRNS w/
 immediate on Intel

On Wed, Sep 03, 2025, Xiaoyao Li wrote:
> On 9/2/2025 10:50 PM, Sean Christopherson wrote:
> > On Mon, Sep 01, 2025, Xiaoyao Li wrote:
> > > On 9/1/2025 3:04 PM, Xin Li wrote:
> > > > On 8/31/2025 11:34 PM, Binbin Wu wrote:
> > > > > > We need to inject #UD for !guest_cpu_has(X86_FEATURE_MSR_IMM)
> > > > > > 
> > > > > 
> > > > > Indeed.
> > > > 
> > > > Good catch!
> > > > 
> > > > > 
> > > > > There is a virtualization hole of this feature for the accesses to the
> > > > > MSRs not intercepted. IIUIC, there is no other control in VMX for this
> > > > > feature. If the feature is supported in hardware, the guest will succeed
> > > > > when it accesses to the MSRs not intercepted even when the feature is not
> > > > > exposed to the guest, but the guest will get #UD when access to the MSRs
> > > > > intercepted if KVM injects #UD.
> > > > 
> > > > hpa mentioned this when I just started the work.  But I managed to forget
> > > > it later... Sigh!
> > > > 
> > > > > 
> > > > > But I guess this is the guest's fault by not following the CPUID,
> > > > > KVM should
> > > > > still follow the spec?
> > > > 
> > > > I think we should still inject #UD when a MSR is intercepted by KVM.
> > 
> > Hmm, no, inconsistent behavior (from the guest's perspective) is likely worse
> > than eating with the virtualization hole.
> 
> Then could we document this design decision somewhere?

Yeah, Documentation/virt/kvm/x86/errata.rst would be the place for that.

> I believe people won't stop wondering why not inject #UD when no guest
> CPUID, when reading the code.
> 
> > Practically speaking, the only guest that's going to be surprised by the
> > hole is a guest that's fuzzing opcodes, and a guest that's fuzzing opcodes
> > at CPL0 isn't is going to create an inherently unstable environment no
> > matter what.
> > 
> > Though that raises the question of whether or not KVM should emulate WRMSRNS and
> > whatever the official name for the "RDMSR with immediate" instruction is (I can't
> > find it in the SDM).
> 
> do you mean because guest might be able to use immediate form of MSR access
> even if the CPUID doesn't advertise it, should KVM emulate it on platform
> doesn't support it, to make sure immediate form of MSR access is always
> supported?

No, I'm calling out that as implemented, KVM doesn't support emulating WRMSRNS
at all.  Most of me just doesn't care.  The only way to encounter WRMSRNS would
be to disable unrestricted guest and execute WRMSRNS in an odd context, or to
force emulation.  Adding emulation support just for forced emulation is absurd,
and adding WRMSRNS emulation for !URG is almost as ridiculous.