kernel-hardening - Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160804170944.GA16464@leverpostej>
Date: Thu, 4 Aug 2016 18:09:44 +0100
From: Mark Rutland <mark.rutland@....com>
To: kernel-hardening@...ts.openwall.com
Cc: Peter Zijlstra <peterz@...radead.org>,
	Kees Cook <keescook@...omium.org>,
	Jeff Vander Stoep <jeffv@...gle.com>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>
Subject: Re: Re: [PATCH 1/2] security, perf: allow further
 restriction of perf_event_open

On Thu, Aug 04, 2016 at 12:32:32PM -0400, Daniel Micay wrote:
> On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote:
> I wasn't talking specifically about perf.

Then this is irrelevant to a discussion about limiting access to the
perf interface.

Hardening drivers in general is a very interesting topic, but it is a
different topic.

> > But please, let's frame the argument to match reality.
> 
> The argument is framed in reality. Stating that it now often takes a
> few hours to find a vulnerability with the unaltered, widely known
> public perf fuzzer is not impressive. It's really an argument for
> claiming that it's a significant security issue.

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.

There is cetainly much that can be done to improve things, if we discuss
that which is actually applicable.

Thanks,
Mark.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.