linux-kernel - Re: [PATCH] KVM: x86: Provide a capability to disable APERF/MPERF read intercepts

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: <Z9Q2Tl50AjxpwAKG@google.com>
Date: Fri, 14 Mar 2025 06:59:42 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH] KVM: x86: Provide a capability to disable APERF/MPERF
 read intercepts

On Thu, Mar 13, 2025, Jim Mattson wrote:
> On Mon, Feb 24, 2025 at 4:47 PM Jim Mattson <jmattson@...gle.com> wrote:
> >
> > Allow a guest to read the physical IA32_APERF and IA32_MPERF MSRs
> > without interception.
> >
> > The IA32_APERF and IA32_MPERF MSRs are not virtualized. Writes are not
> > handled at all. The MSR values are not zeroed on vCPU creation, saved
> > on suspend, or restored on resume. No accommodation is made for
> > processor migration or for sharing a logical processor with other
> > tasks. No adjustments are made for non-unit TSC multipliers. The MSRs
> > do not account for time the same way as the comparable PMU events,
> > whether the PMU is virtualized by the traditional emulation method or
> > the new mediated pass-through approach.
> >
> > Nonetheless, in a properly constrained environment, this capability
> > can be combined with a guest CPUID table that advertises support for
> > CPUID.6:ECX.APERFMPERF[bit 0] to induce a Linux guest to report the
> > effective physical CPU frequency in /proc/cpuinfo. Moreover, there is
> > no performance cost for this capability.
> >
> > Signed-off-by: Jim Mattson <jmattson@...gle.com>
> > ---

...

> Any thoughts?

It's absolutely absurd, but I like it.  I would much rather provide functionality
that is flawed in obvious ways, as opposed to functionality that is flawed in
subtle and hard-to-grok ways.  Especially when the former is orders of magnitude
less complex.

I have no objections, so long as we add very explicit disclaimers in the docs.

FWIW, the only reason my response was delayed is because I was trying to figure
out if there's a clean way to avoid adding a large number of a capabilities for
things like this.  E.g. if we can add generic uAPI to let userspace disable MSR
interception.  But AFAICT, there aren't very many MSRs where it would be sane to
let the guest read unadultered MSRs, so it's probably not worth the complexity.