* Jann Horn:
On Wed, Apr 14, 2021 at 12:27 PM Florian Weimer [off-list ref] wrote:
quoted
* Andrei Vagin:
quoted
We already have process_vm_readv and process_vm_writev to read and write
to a process memory faster than we can do this with ptrace. And now it
is time for process_vm_exec that allows executing code in an address
space of another process. We can do this with ptrace but it is much
slower.
= Use-cases =
We also have some vaguely related within the same address space: running
code on another thread, without modifying its stack, while it has signal
handlers blocked, and without causing system calls to fail with EINTR.
This can be used to implement certain kinds of memory barriers.
That's what the membarrier() syscall is for, right? Unless you don't
want to register all threads for expedited membarrier use?
membarrier is not sufficiently powerful for revoking biased locks, for
example.
For the EINTR issue, <https://github.com/golang/go/issues/38836> is an
example. I believe CIFS has since seen a few fixes (after someone
reported that tar on CIFS wouldn't work because the SIGCHLD causing
utimensat to fail—and there isn't even a signal handler for SIGCHLD!),
but the time it took to get to this point doesn't give me confidence
that it is safe to send signals to a thread that is running unknown
code.
But as you explained regarding the set*id broadcast, it seems that if we
had this run-on-another-thread functionality, we would likely encounter
issues similar to those with SA_RESTART. We don't see the issue with
set*id today because it's a rare operation, and multi-threaded file
servers that need to change credentials frequently opt out of the set*id
broadcast anyway. (What I have in mind is a future world where any
printf call, any malloc call, can trigger such a broadcast.)
The cross-VM CRIU scenario would probably somewhere in between (not
quite the printf/malloc level, but more frequent than set*id).
Thanks,
Florian