linux-kernel - Re: [RFC PATCH 18/41] KVM: x86/pmu: Intercept full-width GP counter MSRs by checking with perf capabilities

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]

Date: Fri, 12 Apr 2024 09:01:52 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: Xiong Zhang <xiong.y.zhang@...ux.intel.com>, pbonzini@...hat.com, 
	peterz@...radead.org, mizhang@...gle.com, kan.liang@...el.com, 
	zhenyuw@...ux.intel.com, dapeng1.mi@...ux.intel.com, kvm@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	zhiyuan.lv@...el.com, eranian@...gle.com, irogers@...gle.com, 
	samantha.alt@...el.com, like.xu.linux@...il.com, chao.gao@...el.com, 
	Xiong Zhang <xiong.y.zhang@...el.com>
Subject: Re: [RFC PATCH 18/41] KVM: x86/pmu: Intercept full-width GP counter
 MSRs by checking with perf capabilities

On Thu, Apr 11, 2024, Jim Mattson wrote:
> On Thu, Apr 11, 2024 at 2:23 PM Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > On Fri, Jan 26, 2024, Xiong Zhang wrote:
> > > From: Mingwei Zhang <mizhang@...gle.com>
> > >
> > > Intercept full-width GP counter MSRs in passthrough PMU if guest does not
> > > have the capability to write in full-width. In addition, opportunistically
> > > add a warning if non-full-width counter MSRs are also intercepted, in which
> > > case it is a clear mistake.
> > >
> > > Co-developed-by: Xiong Zhang <xiong.y.zhang@...el.com>
> > > Signed-off-by: Xiong Zhang <xiong.y.zhang@...el.com>
> > > Signed-off-by: Mingwei Zhang <mizhang@...gle.com>
> > > ---
> > >  arch/x86/kvm/vmx/pmu_intel.c | 10 +++++++++-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
> > > index 7f6cabb2c378..49df154fbb5b 100644
> > > --- a/arch/x86/kvm/vmx/pmu_intel.c
> > > +++ b/arch/x86/kvm/vmx/pmu_intel.c
> > > @@ -429,6 +429,13 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> > >       default:
> > >               if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) ||
> > >                   (pmc = get_gp_pmc(pmu, msr, MSR_IA32_PMC0))) {
> > > +                     if (is_passthrough_pmu_enabled(vcpu) &&
> > > +                         !(msr & MSR_PMC_FULL_WIDTH_BIT) &&
> > > +                         !msr_info->host_initiated) {
> > > +                             pr_warn_once("passthrough PMU never intercepts non-full-width PMU counters\n");
> > > +                             return 1;
> >
> > This is broken, KVM must be prepared to handle WRMSR (and RDMSR and RDPMC) that
> > come in through the emulator.
> 
> Don't tell me that we are still supporting CPUs that don't have
> "unrestricted guest"! Sigh.

Heh, KVM still supports CPUs without VMX virtual NMIs :-)

Practically speaking, if we want to eliminate things like emulated WRMSR/RDMSR,
a Kconfig to build a reduced emulator would be the way to go.  But while a reduced
emulator would be nice for host security, I don't think it would buy us much from
a code perspective, since KVM still needs to handle host userspace MSR accesses.

E.g. KVM could have conditional sanity checks for MSRs that are supposed to be
passed through, but unless a reduced emulator is a hard requirement for passthrough
PMUs, we'd still need the code to handle the emulated accesses.  And even if a
reduced emulator were a hard requirement, I'd still push for a WARN-and-continue
approach, not a "inject a bogus #GP because KVM screwed up" approach.