LWN: Comments on "Running code within another process's address space"

Some questions on Running code within another process's address space

avagin — Fri, 23 Apr 2021 05:18:04 +0000

> 2) the caller resumes execution by jumping to the IP specified in `uctx` in the target's address space; and the caller somehow gets back to the original context in the original address space when the target [makes a syscall / gets a signal].

I would rephrase this:

2) the caller resumes execution by jumping to the IP specified in `uctx` in the target's address space; and the caller somehow gets back to the original context in the original address space when it makes a syscall or gets a signal.

The target process is used only to grub its address space. process_vm_exec doesn't stop it and doesn't change its state (registers, signals, fpu, etc).

There are a few examples, I think they can help to understand how this works:
https://lwn.net/ml/linux-kernel/20210414055217.543246-5-a...

Running code within another process's address space

avagin — Thu, 22 Apr 2021 16:50:53 +0000

Yes, we will need to create memory mappings. You can look at CRIU how it injects a parasite code into a process.

Running code within another process's address space

alkbyby — Thu, 22 Apr 2021 02:01:46 +0000

It is indeed nifty to have such "immediate signal" facility within same address space. And assuming it will be used with sigmask set to block everything, it looks robust. Even delivering another such "signal" when one is already running (assuming the caller provides the stack in both cases which seems reasonable anyways) would work. I assume things like backtraces would work too, as this facility could use same sigreturn trampoline stuff as real signals.

One particularly nice feature of this is that it is entirely compatible with all kinds of libraries. I.e. today libraries are essentially unable to use signals because it is ~impossible to arbitrate between libraries who is using which signal number. When there are no signal numbers or any state (e.g. altstack, sigaction) involved in first place, it looks like there no any kinds compatibility trouble.

Another thing that would be nifty is being able to somehow specify not saving/restoring huge simd states to enable cheaper or more perf-sensitive usages of this facility (e.g. garbage collectors might choose to use it too), and to save stack. It seems inevitable that safe usage of this facility requires caller to allocate stack for each thread's "remote call" and not having to bother about simd registers would save nontrivial number of bytes.

Running code within another process's address space

jnewsome — Mon, 19 Apr 2021 16:54:00 +0000

As someone working on a process sandbox/simulator/emulator <http://shadow.github.io/>, this looks super-exciting! We're in the process now of moving from LD_PRELOAD-based interposition to ptrace. This simplifies a lot of things and is more robust, but is a significant performance hit. AFAICT we'd be able to switch over from ptrace to this new API without much work.

Running code within another process's address space

pm215 — Sat, 17 Apr 2021 15:09:28 +0000

I would have thought that the correct way to solve "implementing POSIX semantics for setuid() purely in userspace is somewhere between tricky and impossible" (the glibc machinery for it is pretty gnarly) is "implement a new kernel syscall that provides the whole-process semantics". The kernel is in a much better position to be able to do that than userspace ever will be. I'm mildly surprised that nobody's ever had a go at it.

Some questions on Running code within another process's address space

dongmk — Sat, 17 Apr 2021 10:57:55 +0000

Thanks for your reply. :) But I find that it's more complex than I thought earlier, and I am getting more confused.

It may be helpful to confirm what the caller will do during `process_vm_exec`; here are two possibilities:

1) the caller blocks until the target [makes a syscall / gets a signal];
2) the caller resumes execution by jumping to the IP specified in `uctx` in the target's address space; and the caller somehow gets back to the original context in the original address space when the target [makes a syscall / gets a signal].

For 1), emmm, there seems to be no `exec` effect since the original address space is restored when `process_vm_exec` returns; the caller simply blocks to wait for the target's syscall/signal.

For 2), a new control flow seems to have emerged after `process_vm_exec`, and the new control flow is terminated (at any time) upon the target's syscall/signal.

Some questions on Running code within another process's address space

smurf — Sat, 17 Apr 2021 09:23:43 +0000

> > that execution will continue until the **process** either makes a system call or receives a signal.

> Is this **process** the calling process or the target process? Or both?

Umm, the target of course. When the target does [ make a syscall / gets a signal ], the system call returns, as described in the text. It obviously cannot do that if the caller continues execution in any way.

Running code within another process's address space

flussence — Sat, 17 Apr 2021 09:15:21 +0000

Surely it should be called process_vm_exec*v*? :)

Some questions on Running code within another process's address space

dongmk — Sat, 17 Apr 2021 05:57:38 +0000

Thanks for your nice article! The `process_vm_exec` system call is interesting, and I get some questions while reading the article.

1. If I understand correctly, the current `process_vm_exec` can only execute code that is already in the target process's address space, which could be inconvenient for tasks such as inspecting the address space content.
In other words, the calling process needs to inject the code to the target (perhaps by `process_vm_writev`) before it invokes `process_vm_exec` to execute the injected code.

Or does `process_vm_exec` provide some mechanisms to "bring" its own code to the switched address space?

> that execution will continue until the **process** either makes a system call or receives a signal.

Is this **process** the calling process or the target process? Or both?

Will the target process (and threads in the target process) pause its execution upon the system call?
If so, how could the calling process resume the target's execution?
If not, the calling process could miss some system calls made by the target, right?

3. I think things will be complicated when there are multiple threads in the calling process.
For example, when one thread calls `process_vm_exec` to switch the address space, other threads will run in the "wrong address space" and fail.

Sorry for asking so many questions.

Solaris-style Doors

CChittleborough — Sat, 17 Apr 2021 01:26:50 +0000

The Linux port was only “alpha quality”, and sadly work on it seems to have stopped in 2003.

The Doors facility needs both (1) kernel support and (2) a non-trivial user-space library. Door servers need that library to manage a thread pool in ways that almost require tight integration with the threads library. This is much easier when one organization produces both the kernel and the core libraries than in the Linux community.

(Full disclosure: I created that Wikipedia article.)

Running code within another process's address space

Cyberax — Sat, 17 Apr 2021 00:47:47 +0000

Can we just get a file-decriptor based process API? Then the need to inject stuff into other processes would be severely reduced.

Running code within another process's address space

roc — Sat, 17 Apr 2021 00:02:21 +0000

Remote system calls often need parameters (both in and out) in memory. If the target task is running, how do you guarantee with PROCESS_VM_EXEC_SYSCALL that any memory changes you make aren't overwritten by the running task? You won't be able to use the stack for example. Would you have to remote-sycall an mmap/munmap to allocate dedicated memory for your parameters?

Running code within another process's address space

luto — Fri, 16 Apr 2021 20:13:33 +0000

setuid could be solved by a new syscall. The error handling might be nontrivial, but it’s doable.

Running code within another process's address space

klbrun — Fri, 16 Apr 2021 17:50:32 +0000

Whatever happened to the Sun Microsystems Solaris door? Per Wikipedia, a port was made for Linux 2.4.18 in 2003.

Running code within another process's address space

josh — Fri, 16 Apr 2021 16:46:44 +0000

I do wonder if problems like the setuid issue could be solved by io_uring and a "run this on behalf of" mechanism that allows one thread to submit items into an io_uring that runs in the context of another thread.

Running code within another process's address space

rvolgers — Fri, 16 Apr 2021 15:58:21 +0000

Just as io_uring has finally settled on a sane context management mechanism for its worker threads, a new fundamentally broken way to mix-and-match process contexts is being invented. Marvelous.