Update perf_event_paranoid help message to include setcap method

[firelizzard18]

Executing sudo setcap "cap_sys_ptrace,cap_perfmon=ep" $(which rr) (from this comment) allows rr run in fast mode without changing perf_event_paranoid. Changing the capabilities for a single binary (or a for a single user?) seems more secure than changing perf_event_paranoid for the whole system. IMO the error message rr prints out about perf_event_paranoid should be updated to include this option.

[rocallahan]

There are a few problems with that:

• The 'I saw this temporarily but it went away during my experimentation' problem which is worrying.

• This only works in kernel 5.8 and up. So we'd have to make sure to give the right advice depending on the kernel version.

• Apparently Ubuntu may be carrying kernel patches so that perf_event_paranoid set to 4 prevents rr from working even with those caps: https://github.com/rr-debugger/rr/issues/3202#issuecomment-1133372865

So this would need to be very carefully tested.

But yes, if we could deploy this it would be great, especially if we could deploy this in the distro rr packages, because then they would just work with zero configuration changes.

[rocallahan]

Ubuntu is carrying a patch that limits all perf_event_open() usage to CAP_SYS_ADMIN if /perf/event/paranoid if 4 or greater. This patch dates to 2016 or earlier and is also present in Debian and Android.

This Ubuntu patch should probably be updated to check CAP_PERFMON instead. I have sent an email to [email protected] about that, we'll see what they say. If they make that change then no perf_event_paranoid change will be required in future Ubuntu releases, but for now, even if we add CAP_PERFMON to rr, users will still have to change perf_event_paranoid as well.

However it probably is a good idea to add CAP_PERFMON to rr packages right away. It shouldn't hurt and might be useful already in distros not carrying that patch.

[Keno]

I imagine distros might not like that we pass CAP_PERFMON through to tracees. Should we switch to opening the desched counter on the tracee's behalf and sending the fd over, so that we can drop the caps?

[rocallahan]

We could look into that, but a sufficiently dedicated attacker writing malicious code that someone's debugging with rr could have that code hack rr and get CAP_PERFMON that way. I wouldn't trust rr to debug malicious code, it should be run in an untrusted VM for that.

Doing this without slowing down thread creation (which is important) is tricky. We would want to restructure a lot of code so that we can send both the syscallbuf shared memory fd and the desched fd in a single round-trip.

[rocallahan]

Well, given we're already doing the retrieve_fd dance maybe replacing that with a send_fd would not be bad. But backwards compatibility would be a real pain :-(.