linux-kernel - Re: [PATCH 5/5] KVM: x86/pmu: Hide guest counter updates from the VMRUN instruction

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: <CALMp9eR_xYapRm=zJ3OdAzBVFjpzeQWYv9nTs1ZstAsugEwWRQ@mail.gmail.com>
Date:   Wed, 24 May 2023 13:47:53 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Sandipan Das <sandipan.das@....com>,
        Like Xu <like.xu.linux@...il.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Ravi Bangoria <ravi.bangoria@....com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Santosh Shukla <santosh.shukla@....com>,
        "Tom Lendacky (AMD)" <thomas.lendacky@....com>,
        Ananth Narayan <ananth.narayan@....com>
Subject: Re: [PATCH 5/5] KVM: x86/pmu: Hide guest counter updates from the
 VMRUN instruction

On Wed, May 24, 2023 at 1:41 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Wed, Apr 26, 2023, Sandipan Das wrote:
> > Hi Sean, Like,
> >
> > On 4/19/2023 7:11 PM, Like Xu wrote:
> > >> Heh, it's very much explicable, it's just not desirable, and you and I would argue
> > >> that it's also incorrect.
> > >
> > > This is completely inaccurate from the end guest pmu user's perspective.
> > >
> > > I have a toy that looks like virtio-pmu, through which guest users can get hypervisor performance data.
> > > But the side effect of letting the guest see the VMRUN instruction by default is unacceptable, isn't it ?
> > >
> > >>
> > >> AMD folks, are there plans to document this as an erratum?ï¿½ I agree with Like that
> > >> counting VMRUN as a taken branch in guest context is a CPU bug, even if the behavior
> > >> is known/expected.
> > >
> >
> > This behaviour is architectural and an erratum will not be issued. However, for clarity, a future
> > release of the APM will include additional details like the following:
> >
> >   1) From the perspective of performance monitoring counters, VMRUNs are considered as far control
> >      transfers and VMEXITs as exceptions.
> >
> >   2) When the performance monitoring counters are set up to count events only in certain modes
> >      through the "OsUserMode" and "HostGuestOnly" bits, instructions and events that change the
> >      mode are counted in the target mode. For example, a SYSCALL from CPL 3 to CPL 0 with a
> >      counter set to count retired instructions with USR=1 and OS=0 will not cause an increment of
> >      the counter. However, the SYSRET back from CPL 0 to CPL 3 will cause an increment of the
> >      counter and the total count will end up correct. Similarly, when counting PMCx0C6 (retired
> >      far control transfers, including exceptions and interrupts) with Guest=1 and Host=0, a VMRUN
> >      instruction will cause an increment of the counter. However, the subsequent VMEXIT that occurs,
> >      since the target is in the host, will not cause an increment of the counter and so the total
> >      count will end up correct.
>
> The count from the guest's perspective does not "end up correct".  Unlike SYSCALL,
> where _userspace_ deliberately and synchronously executes a branch instruction,
> VMEXIT and VMRUN are supposed to be transparent to the guest and can be completely
> asynchronous with respect to guest code execution, e.g. if the host is spamming
> IRQs, the guest will see a potentially large number of bogus (from it's perspective)
> branches retired.

The reverse problem occurs when a PMC is configured to count "CPUID
instructions retired." Since KVM intercepts CPUID and emulates it, the
PMC will always read 0, even if the guest executes a tight loop of
CPUID instructions.

The PMU is not virtualizable on AMD CPUs without significant
hypervisor corrections. I have to wonder if it's really worth the
effort.