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: <20210830085106.GF4353@worktop.programming.kicks-ass.net>
Date:   Mon, 30 Aug 2021 10:51:06 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vince Weaver <vincent.weaver@...ne.edu>
Cc:     Andy Lutomirski <luto@...nel.org>, Rob Herring <robh@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will@...nel.org>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-perf-users@...r.kernel.org
Subject: Re: [RFC 2/3] perf/x86: Control RDPMC access from .enable() hook

On Sun, Aug 29, 2021 at 11:05:55PM -0400, Vince Weaver wrote:

> as the author of those perf_event tests for rdpmc, I have to say if ARM 
> comes up with a cleaner implementation I'd be glad to have x86 transition 
> to something better.
> 
> The rdpmc code is a huge mess and has all kinds of corner cases.  I'm not 
> sure anyone besides the PAPI library tries to use it, and while it's a 
> nice performance improvement to use rdpmc it is really hard to get things 
> working right.
> 
> As a PAPI developer we actually have run into the issue where the CPU 
> switches and we were reporting the wrong results.  Also if I recall (it's 
> been a while) we were having issues where the setup lets you attach to a 
> process on another CPU for monitoring using the rdpmc interface and it 
> returns results even though I think that will rarely ever work in 
> practice.

There's just not much we can do to validate the usage, fundamentally at
RDPMC time we're not running any kernel code, so we can't validate the
conditions under which we're called.

I suppose one way would be to create a mode where RDPMC is disabled but
emulated -- which completely voids the reason for using RDPMC in the
first place (performance), but would allow us to validate the usage.

Fundamentally, we must call RDPMC only for events that are currently
actuve on *this* CPU. Currently we rely on userspace to DTRT and if it
doesn't we have no way of knowing and it gets to keep the pieces.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ