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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 4 Aug 2016 17:10:01 +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: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further
 restriction of perf_event_open

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...

I don't think that's true for the arm/arm64 perf code.

I think we've done a reasonable job of testing and fixing those, along
with core infrastructure issues. The perf fuzzer runs for a very long
time on a mainline kernel without issues, while on my Nexus 5x I get a
hard lockup after ~85 seconds (and prior to the last android update the
lockup was instantaneous).

> Shining the same light on mainline drivers wouldn't be pretty. The work
> going into hardening the Qualcomm drivers isn't happening upstream to
> any comparable extent.

>From my personal experience (and as above), and talking specifically
about PMU drivers, I think that the opposite is true. This is not to say
there aren't issues; I would not be surprised if there are. But it's
disingenuous to say that mainline code is worse than that which exists
in a vendor kernel when the latter is demonstrably much easier to break
than the former.

If there are issues you are aware of, please report them. If those
issues only exist in non-upstream code, then the applicable concerns are
somewhat different (though certainly still exist).

But please, let's frame the argument to match reality.

Thanks,
Mark.