linux-kernel - Re: perf: rdpmc bug when viewing all procs on remote cpu

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: <alpine.DEB.2.21.1901180905090.5762@macbook-air>
Date:   Fri, 18 Jan 2019 09:09:04 -0500 (EST)
From:   Vince Weaver <vincent.weaver@...ne.edu>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: perf: rdpmc bug when viewing all procs on remote cpu

On Fri, 18 Jan 2019, Peter Zijlstra wrote:

> On Fri, Jan 11, 2019 at 04:52:22PM -0500, Vince Weaver wrote:
> > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > 
> > > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > > 
> > > > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > > > 
> > > > > However if you create an all-process attached to CPU event:
> > > > > 	perf_event_open(attr, -1, X, -1, 0);
> > > > > the mmap event index is set as if this were a valid event and so the rdpmc
> > > > > succeeds even though it shouldn't (we're trying to read an event value
> > > > > on a remote cpu with a local rdpmc).
> > 
> > so on further looking at the code, it doesn't appear that rdpmc events are 
> > explicitly marked as unavailable in the attach-cpu or attach-pid case, 
> > it's just by luck the check for PERF_EVENT_STATE_ACTIVE catches most of 
> > the cases?
> > 
> > should an explicit check be added to zero out userpg->index in cases where 
> > the event being measured is running on a different core?
> 
> And how would we konw? We don't know what CPU will be observing the
> mmap().
> 
> RDPMC fundamentally only makes sense on 'self' (either task or CPU).

so is this a "don't do that then" thing and I should have PAPI 
userspace avoid using rdpmc() whenever a proc/cpu was attached to?

Or is there a way to have the kernel indicate this?  Does the kernel track 
current CPU and original CPU of the mmap and could zero out the index 
field in this case?  Or would that add too much overhead?

Vince