Use `process_vm_readv`/`process_vm_writev`instead of opening `/proc/<pid>/mem`?

[rocallahan]

These are available in Linux 3.2 so it would be no trouble to depend on them. I think this would simplify the code a bit since we might be able to use that syscall in all situations and not have to reopen the mem-fd or worry about the state where it's not open.

My only concern is whether there are cases where we are ptracing a process but those syscalls don't work due to permissions. Might need to experiment.

[g2p]

I think this would be useful to keep rr working on hardened platforms.
/proc/self/mem allows bypassing per-mapping page permissions. Because of that all writes directly through /proc/self/mem are blocked on Chrome OS for example.

[khuey]

I think we are currently using the "ignores permissions" bit of /proc/self/mem.

[g2p]

Is it a matter of bypassing some untouched processes that restrict permissions in one way and not the other, as roc suggested? Or for some other reason?

[rocallahan]

From that bug report, it sounds like rr would work if you run it as root or give it CAP_DAC_OVERRIDE.

[rocallahan]

I would be surprised if ChromeOS does not already block process_vm_writev. Have you tested it?

[g2p]

In my testing, and my reading of the bug report, being root doesn't help.
There's a permissions restriction for non-root user (/proc/self/maps is mode r-- --- ---), and another check to deny root/CAP_DAC_OVERRIDE users.

I have not tested process_vm_writev, but my understanding is that it goes through ptrace permissions and would be more likely to work now that the solution that ignores permissions is blocked.