* Jann Horn: > On Wed, Apr 14, 2021 at 12:27 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Andrei Vagin: >> >> > 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
