linux-kernel - Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf

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:   Thu, 1 Sep 2016 09:26:29 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Stephane Eranian <eranian@...il.com>,
        Russell King <linux@....linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Subject: Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to
 perf_regs structure

On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> It's a perennial request from hardware folks to be able to
> see the raw values of the pmu registers. Partly it's so that
> they can verify perf is doing what they want, and some
> of it is that they're interested in some of the more obscure
> info that isn't plumbed out through other perf interfaces.

How much and what is that? Can't we try and get interfaces sorted?

> Over the years internally have used various hack to get
> the requested data out but this is an attempt to use a
> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).

Not really liking that. It assumes too much and doesn't seem to cover
about half the perf use-cases.

It assumes the machine state can be captured by registers (this is false
for things like Intel DS/PT, which have state in memory), it might
assume <= 64 registers but I didn't look that closely, this too might
become somewhat restrictive.

Worse, it doesn't work for !sampling workloads, of which you also very
much want to verify programming etc.

> This would also be helpful for those of us working on the perf
> hardware backends, to be able to verify that we're programming
> things correctly, without resorting to debug printks etc.

On x86 we can trace the MSR writes. No need to add debug printk()s.
We could (and I have on occasion) added tracepoints (well trace_printk)
to the Intel DS memory stores to see what was written there.

Tracing is much more flexible for debugging this stuff.

Can't you do something along those lines?