[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1470143405.13627.22.camel@gmail.com>
Date: Tue, 02 Aug 2016 09:10:05 -0400
From: Daniel Micay <danielmicay@...il.com>
To: kernel-hardening@...ts.openwall.com, Peter Zijlstra
<peterz@...radead.org>
Cc: Jeff Vander Stoep <jeffv@...gle.com>, mingo@...hat.com,
alexander.shishkin@...ux.intel.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH 1/2] security, perf: allow
further restriction of perf_event_open
> > So the problem I have with this is that it will completely inhibit
> > development of things like JITs that self-profile to re-compile
> > frequently used code.
>
> Or reimplement strace with sys_perf_event_open(), speeding it up
> greatly
> by not using ptrace (see 'perf trace', one such attempt), combining it
> with sys_bpf(), which can run unpriviledged as well, provides lots of
> possibilities for efficient tooling that would be greatly stiffled by
> such big hammer restrictions :-(
The usage on Android wouldn't impact strace. It's a debugging tool used
over the debugging shell so it could be taught to toggle on unprivileged
access to perf events as the other tools using the API were.
Download attachment "signature.asc" of type "application/pgp-signature" (852 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
