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: <CALMp9eRYvPJ5quwa7Dr1GgjPpmZVm+6TM_fkhA6KbVAdMsGH7g@mail.gmail.com>
Date: Fri, 14 Mar 2025 08:33:07 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sean Christopherson <seanjc@...gle.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Provide a capability to disable APERF/MPERF
 read intercepts

On Fri, Mar 14, 2025 at 8:07 AM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On 3/14/25 14:59, Sean Christopherson wrote:
> > 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.
>
> True but it's not even a capability, it's just a new bit in the existing
> KVM_CAP_X86_DISABLE_EXITS.
>
> Just one question:
>
> > -       u64 r = KVM_X86_DISABLE_EXITS_PAUSE;
> > +       u64 r = KVM_X86_DISABLE_EXITS_PAUSE | KVM_X86_DISABLE_EXITS_APERFMPERF;
>
> Should it be conditional on the host having the APERFMPERF feature
> itself?  As is the patch _does_ do something sensible, i.e. #GP, but
> this puts the burden on userspace of checking the host CPUID and
> figuring out whether it makes sense to expose the feature to the guest.
> It would be simpler for userspace to be able to say "if the bit is there
> then enable it and make it visible through CPUID".

Good point. I'll take care of that in v2.

I feel like I am abandoning my principles with this patch, but as long
as you and Sean are on-board, I will do what needs to be done.