Disallowing perf_event_open()

Posted Aug 5, 2016 0:17 UTC (Fri) by deater (subscriber, #11746)
In reply to: Disallowing perf_event_open() by ballombe
Parent article: Disallowing perf_event_open()

> or maybe because perf is not disabled by default on Debian.

I always forget that most people do not run unstable.

to post comments

Disallowing perf_event_open()

Posted Aug 5, 2016 0:57 UTC (Fri) by creemj (subscriber, #56061) [Link] (1 responses)

I upgraded to testing two or three weeks ago and had to spend some time working out why my profiling code stopped working. It was a bit annoying to find that perf events was disabled in the kernel from scratch, but I managed to write my first ever systemd init config to write a sensible value to /proc/sys/kernel/perf_event_paranoid on boot up so that I wouldn't be pissed off every time I rebooted.

The pain level has to be quite high before I would report a bug or issue back to Debian --- I hate the reportbug interface and find 'apt-get purge crappy-buggy-package' a much easier and quicker solution in most cases.

I am wondering, however, whether there is a kernel option to change the default? That would be a neater solution.

Disallowing perf_event_open()

Posted Aug 5, 2016 4:36 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> …but I managed to write my first ever systemd init config to write a sensible value to /proc/sys/kernel/perf_event_paranoid on boot up…

Why a systemd init config? Isn't this exactly why we have /etc/sysctl.conf and /etc/sysctl.d/?

# echo "kernel.perf_event_paranoid = 0" > /etc/sysctl.d/perf_events.conf
# update-initramfs -k all -u

Disallowing perf_event_open()

Posted Aug 6, 2016 17:35 UTC (Sat) by anton (subscriber, #25547) [Link] (3 responses)

I run stable, and I find that the default restrictions of perf are broken for my uses, so I have this nice line in /etc/rc.local:

echo 0 >/proc/sys/kernel/perf_event_paranoid

Disallowing perf_event_open()

Posted Aug 6, 2016 18:06 UTC (Sat) by spender (guest, #23067) [Link] (2 responses)

I like that we have two comments now in this thread alone demonstrating how people have no problem at all with the serious security side-effects of the coarseness of the toggle in the other direction, yet all the complaints are focused on the mere option of an additional, more secure setting. When you consider that even CONFIG_NET can be disabled, but PERF_EVENTS cannot, it's obvious that all the pushback has to do with an arch maintainer also being the maintainer of a pet project he wants to force on everyone, spending more time on adding new bells and whistles and not on (for instance) fixing known issues deater has been talking about here for years now exposed by simple fuzzing, meanwhile offering users no way to mitigate those issues.

-Brad

Disallowing perf_event_open()

Posted Aug 8, 2016 15:09 UTC (Mon) by deater (subscriber, #11746) [Link] (1 responses)

And it turns out that 4.8-rc1 falls over even more quickly than normal with the perf_fuzzer.

The fun part is that the serial console only manages to print
[163405.758086] BUG: unable to handle kernel
before completely locking up.

I'll try reporting this to linux-kernel, but the reports are usually ignored and the deep seated problems the fuzzer is tickling are a bit out of my league to track down.

Disallowing perf_event_open()

Posted Aug 9, 2016 15:34 UTC (Tue) by deater (subscriber, #11746) [Link]

For those keeping track, I ran the perf_fuzzer on a Haswell machine running 4.8-rc1.

The bug mentioned previously that quickly locked the machine turns out to be a known bug (found with trinity a few weeks ago) with a working patch that hasn't hit upstream yet. Once I patched for the bug I let perf_fuzzer run again.

It lasted 6 hours before completely crashing. Along the way it found:

2 known WARNings
2 new WARNings
3 gpf/slab poisoning warnings

and then it finally crashed hard.