On 4/13/21 10:52 PM, Andrei Vagin wrote: > process_vm_exec has two modes: > > * Execute code in an address space of a target process and stop on any > signal or system call. We already have a perfectly good context switch mechanism: context switches. If you execute code, you are basically guaranteed to be subject to being hijacked, which means you pretty much can't allow syscalls. But there's a lot of non-syscall state, and I think context switching needs to be done with extreme care. (Just as example, suppose you switch mms, then set %gs to point to the LDT, then switch back. Now you're in a weird state. With %ss the plot is a bit thicker. And there are emulated vsyscalls and such.) If you, PeterZ, and the UMCG could all find an acceptable, efficient way to wake-and-wait so you can switch into an injected task in the target process and switch back quickly, then I think a much nicer solution will become available. > > * Execute a system call in an address space of a target process. I could get behind this, but there are plenty of cans of worms to watch out for. Serious auditing would be needed.
