Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Aug 2016 21:06:02 +0000
From: Jeffrey Vander Stoep <>
To: Kees Cook <>, Peter Zijlstra <>
Cc: Ingo Molnar <>, Arnaldo Carvalho de Melo <>, 
	Alexander Shishkin <>, 
	"" <>, 
	"" <>, LKML <>, 
	Jonathan Corbet <>, "Eric W. Biederman" <>
Subject: Re: Re: [PATCH 1/2] security, perf: allow further
 restriction of perf_event_open

Far from trying to kill perf, we want (and require) perf to be available to
developers on Android. All that this patch enables us to do is gate it
behind developer settings - just like we do with other developer targeted

On Tue, Aug 2, 2016 at 1:51 PM Kees Cook <> wrote:

> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <>
> wrote:
> > On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote:
> >
> >> Now, obviously, these API have huge value, otherwise they wouldn't
> >> exist in the first place, and they wouldn't be built into end-user
> >> kernels if they were universally undesirable. But that's not the
> >> situation: the APIs are needed, but they lack the appropriate knobs to
> >> control their availability.
> >
> > So far so good, but I take exception with the suggestion that the
> > proposed knob is appropriate.
> >
> >> And this isn't just about Android: regular
> >> distro kernels (like Debian, who also uses this patch) tend to build
> >> in everything so people can use whatever they want. But for admins
> >> that want to reduce their systems' attack surface, there needs to be
> >> ways to disable things like this.
> >
> > And here I think you're overestimating the knowledge of most admins.
> Well, I suspect that's why both Android and Debian default this to off
> right now. :) But, regardless, I think it's weird to block admins who
> DO understand about attack surface from being able to limit it.
> >> > 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.
> >>
> >> This is a good example of a use-case where this knob would be turned
> >> down. But for many many other use-cases, when presented with a
> >> pre-built kernel, there isn't a way to remove the attack surface.
> >
> > No, quite the opposite. Having this knob will completely inhibit
> > development of such applications. Worse it will probably render perf
> > dead for quite a large body of developers.
> I hear what you're saying, but I think there's a few problems: the
> proposed self-profiling JIT doesn't exist (so it's pointless to
> discuss), and the number of developers that don't have access to their
> own system is impossibly tiny when compared to the hundreds of
> millions of end-users for whom perf is not needed.
> > The moment you frame it like: perf or sekjurity, and even default to
> > no-perf-because-sekjurity, a whole bunch of corporate IT departments
> > will not enable this, even for their developers.
> It's not "vs security", it's a risk analysis of attack surface. The
> vast majority of people running Linux do not use perf (right now).
> I've never suggested it be default disabled: I'm wanting to upstream
> the sysctl setting that is already in use on distros where the distro
> kernel teams have deemed this is needed knob for their end-users. All
> of the objections you're talking about assume that the knob doesn't
> exist, but it does already. It's just not in upstream. :)
> > Have you never had to 'root' your work machine to get work done? I have.
> > Luckily this was pre-secure-boot times so it was trivial since I had
> > physical access to the machine. But it still sucked I had to fight IT
> > over mostly 'trivial' crap.
> Yeah, I've had to do similar. Frankly most people use VMs or non-corp
> hardware for doing development work, so I don't think this is a useful
> comparison.
> >
> >> > I would much rather have an LSM hook where the security stuff can do
> >> > more fine grained control of things. Allowing some apps perf usage
> while
> >> > denying others.
> >>
> >> I'm not against an LSM, but I think it's needless complexity when
> >> there is already a knob for this but it just doesn't go "high" enough.
> >> :)
> >
> > So what will you to the moment the Google Dalvik guys come to you and
> > say: "Hey, we want to do active profiling to do better on-line code
> > generation?".
> That hasn't happened yet. When it does, we can revisit this. But right
> now, today, there is a need for this knob.
> > I see 0 up-sides of this approach and, as per the above, a whole bunch
> > of very serious downsides.
> >
> > A global (esp. default inhibited) knob is too coarse and limiting.
> I haven't suggested it be default inhibit in the upstream Kconfig. And
> having this knob already with the 0, 1, and 2 settings seems
> incomplete to me without this highest level of restriction that 3
> would provide. That seems rather arbitrary to me. :)
> Let me take this another way instead. What would be a better way to
> provide a mechanism for system owners to disable perf without an LSM?
> (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as
> wide a coverage as possible.)
> -Kees
> --
> Kees Cook
> Chrome OS & Brillo Security

Content of type "text/html" skipped

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.