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

Message-ID: <aLcEMCMDRCEZnmdH@google.com>
Date: Tue, 2 Sep 2025 07:50:24 -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 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.  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).  I'm leaning "no", because outside of forced emulation, KVM
should only "need" to emulate the instructions if Unrestricted Guest is disabled,
the instructions should only be supported on CPUs with unrestricted guest, there's
no sane reason (other than testing) to run a guest without Unrestricted Guest,
and using the instructions in Big RM would be quite bizarre.  On the other hand,
adding emulation support should be quite easy...

Side topic, does RDMSRLIST have any VMX controls?

> For handle_wrmsr_imm(), it seems we need to check
> guest_cpu_cap_has(X86_FEATURE_WRMSRNS) as well, since immediate form of MSR
> write is only supported on WRMSRNS instruction.
> 
> It leads to another topic, do we need to bother checking the opcode of the
> instruction on EXIT_REASON_MSR_WRITE and inject #UD when it is WRMSRNS
> instuction and !guest_cpu_cap_has(X86_FEATURE_WRMSRNS)?
> 
> WRMSRNS has virtualization hole as well, but KVM at least can emulate the
> architectural behavior when the write on MSRs are not pass through.