Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #55996

Re: Should the kernel perf interface be available on autobuilders?

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Sun, 2016-12-04 at 14:41 +0100, Philipp Kern wrote:
> On 04.12.2016 07:52, Petter Reinholdtsen wrote:
> > Lluís Vilanova (cc) and I maintain the coz-profiler package in Debian,
> > and this package uses the perf kernel interface for profiling.  This
> > subsystem has received strict access limitations in recent Debian
> > kernels.  During build of the coz-profiler package it test itself to
> > ensure it is working, and this work on all autobuilders except one, the
> > x32 architecture.
> > 
> > Are the autobuilders expected to block access to the perf kernel
> > interface, or is this a misconfiguration of the x32 build host?
> > 
> > The reason I ask is that the restricted setting has changed in recent
> > years, and I expect all autobuilders to get the restricted setting of
> > x32 when they are upgraded.  I would prefer it to be defined that the
> > autobuilders should provide access to the perf interface during build.
> > This can be set by inserting a lower value in
> > /proc/sys/kernel/perf_event_paranoid, for example like this:
> > 
> >   echo 1 > /proc/sys/kernel/perf_event_paranoid
> > 
> > The default value in Jessie is 1

(I wish it wasn't.)

> >  and this work with the coz-profiler
> > build, while the default value in unstable/testing is 3 and causes the
> > build to fail.  The details of this issue with coz-profiler can be found
> > in <URL: https://bugs.debian.org/844633 >.
> 
> I think ultimately it's up to DSA to decide to diverge from the default
> here and up to the kernel team to potentially change the default. (Both
> cc'ed.)
> 
> Do we know what 3 (vs. 2) actually stands for today? The source is
> elusive here, as you documented already. Specifically the capability you
> are asking for is access to the perf interface *without* CAP_SYS_ADMIN,
> correct? (Hence 1 instead of 2.)

Like most sysctls, this is now documented:

    perf_event_paranoid:

    Controls use of the performance events system by unprivileged
    users (without CAP_SYS_ADMIN).  The default value is 2.

     -1: Allow use of (almost) all events by all users
    >=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK
    >=1: Disallow CPU event access by users without CAP_SYS_ADMIN
    >=2: Disallow kernel profiling by users without CAP_SYS_ADMIN

The patch that adds the higher level doesn't currently touch that,
though.  The value of 3 disallows all use by unprivileged users.

> Requiring custom kernel sysctls to enable package builds is something we
> should try to avoid - I don't think we have a precedent at all here. At
> the same time it's unreasonable to require CAP_SYS_ADMIN for a build.

The insecurity of the perf subsystem can be quickly demonstrated by
fuzzing it with Trinity or perf_fuzzer
<http://web.eece.maine.edu/~vweaver/projects/perf_events/fuzzer/>.  I
recommend that you do not override the default.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Should the kernel perf interface be available on autobuilders? Philipp Kern <pkern@debian.org> - 2016-12-04 14:50 +0100
  Re: Should the kernel perf interface be available on autobuilders? Ben Hutchings <ben@decadent.org.uk> - 2016-12-04 17:20 +0100

csiph-web