linux-kernel - Re: Question about Perf's handling of in-use performance counters

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

Date:   Wed, 30 Nov 2016 19:17:42 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Taylor Andrews <andrewst@...are.com>
Cc:     Andi Kleen <andi@...stfloor.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Alok Kataria <akataria@...are.com>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: Question about Perf's handling of in-use performance counters

On Wed, Nov 30, 2016 at 03:44:57PM +0000, Taylor Andrews wrote:

> > No, it was about the (mis)guide-line having fundamental races and the
> > belief that the BIOS has no business what so ever using these resources
> > to begin with.
> 
> Can you please describe what fundamental races you are talking about?

The protocol does a RDMSR to see if the counter is configured or not, if
not, then it can proceed with the WRMSR.

Since these are two separate instructions, there is nothing that
prevents a vCPU preemption or SMI to come in between and invalidate the
state we just read.

> Why do you believe the BIOS should never be using performance counters?

The BIOS's job is to boot the system and then stay the heck away.
Runtime services are not what its for.

Now I know some hardware vendors like to (ab)use SMM for
fail^Wfeature-add, and that is exactly the kind of crap we don't need.
BIOS monkeys always get it wrong and BIOS code is _never_ updated, so
then you're stuck with wreckage.

> Even if you discount the BIOS use case (despite Intel considering it
> legitimate), we still have the scenario of a Hypervisor exposing some
> virtual performance counters as in-use and unavailable.  What was the
> rationale that the PMU cooperative sharing guidelines outlined by
> Intel should be intentionally ignored, and that perf should attempt to
> take over all generic performance counters, regardless of if they are
> marked in-use?

See the thread here:

  https://lkml.org/lkml/2011/3/24/608