On Wed, 2016-10-19 at 07:26 -0300, Arnaldo Carvalho de Melo wrote:
>
> But self profiling JITs would be useful for non-developers, on Android
> (anywhere, really), and for that it would require being able to at
> least, well, self profile, using sys_perf_event_open() by a normal
> process, limited
On Wed, 2016-10-19 at 10:41 +0100, Mark Rutland wrote:
> On Mon, Oct 17, 2016 at 10:54:33AM -0400, Daniel Micay wrote:
> > On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote:
> > > It's also my understanding that for Android, perf_event_paranoid
> > > is
>
On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote:
> On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland
> wrote:
> > Hi,
> >
> > Attempt to revive discussions below...
> >
> > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
> > > When kernel.perf_event_paranoid is set to 3 (or gre
On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote:
> Hi,
>
> Attempt to revive discussions below...
>
> On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
> > When kernel.perf_event_paranoid is set to 3 (or greater), disallow
> > all access to performance events by users witho
> My claim was not that the mainline code was impressively perfect, but
> rather that the vendor code was worse, countering a prior claim
> otherwise. Hence, reality.
You're arguing with a straw man.
I was responding to a comment about out-of-tree code, not generic
architecture perf drivers vs. a
On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote:
> On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote:
> >
> > Qualcomm's drivers might be lower quality than core kernel code, but
> > they're way above the baseline set by mainline kernel drivers...
On Thu, 2016-08-04 at 16:11 +0200, Peter Zijlstra wrote:
> On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote:
> >
> > Qualcomm's perf driver is out-of-tree along with most of their other
> > drivers.
>
>
> So you're asking us to maim
On Thu, 2016-08-04 at 11:28 +0100, Mark Rutland wrote:
> On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote:
> >
> > There's a lot of architecture and vendor specific perf events code
> > and
> > lots of bleeding edge features. On Android, a lot of the
> One of the strengths of linux is applications of features the authors
> of
> the software had not imagined. Your proposals seem to be trying to
> put
> the world a tiny little box where if someone had not imagined and
> preapproved a use of a feature it should not happen. Let's please
> avoid
Having this in Yama would also make it probable that there would be a
security-centric default. It would end up wiping out unprivileged perf
events access on distributions using Yama for ptrace_scope unless they
make the explicit decision to disable it. Having the perf subsystem
extend the existing
> The default has no impact on the "it's too coarse and limiting"
> negative property
> of this patch, which is the show-stopper aspect. Please fix that
> aspect instead of
> trying to argue around it.
Disabling perf events in the kernel configuration is even more limiting,
and is currently the
> > 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 atte
On Tue, 2016-08-02 at 11:52 +0200, Peter Zijlstra wrote:
> On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
> >
> > When kernel.perf_event_paranoid is set to 3 (or greater), disallow
> > all access to performance events by users without CAP_SYS_ADMIN.
> >
> > This new level of r
On Fri, 2016-06-17 at 17:00 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 17, 2016 at 12:16:47PM -0400, Daniel Micay escreveu:
> > On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote:
> > > This Changelog is completely devoid of information. _WHY_ are yo
On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote:
> On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote:
> > Hi guys,
> >
> > This patch wasn't originally CCed to you (I'm fixing that now).
> > Would
> > you consider taking this into the perf tree?
>
> No.
>
> > It's been in active
> As a debian user, is this a good place to complain? Because it does
> get
> it the way.
It would be relevant to whether or not it should be set to 3 by default
in the kernel without explicit configuration, but there's no proposal to
do that. Debian has to pick a trade-off beyond security and a t
> This feature is already implemented by two distros, and likely wanted
> by others. We cannot ignore that.
Date point: Arch Linux won't be enabling CONFIG_USERNS until there's a
way to disable unprivileged user namespaces. The kernel maintainers are
unwilling to carry long-term out-of-tree patche
17 matches
Mail list logo
