How can mprotect be used soundly?

[RalfJung]

Miri now contains some quite cursed hacks in native-lib / FFI mode where it will mprotect(PROT_NONE) a bunch of memory before invoking native C code, and some cursed ptrace magic then kicks in when the program actually accesses those pages. That got me to wonder, which ways of using mprotect are actually sound?

What Miri does could be sound because the cursed ptrace logic conspires to make all memory accesses still work as normal. We just run some extra code on each access. So even if LLVM decided to move some memory accesses around the mprotect calls, that would just confuse our tracing, but the accesses should work as excpected.

Is that the only way mprotect can be used soundly? Just taking away memory that Rust thinks it can access cannot work in general, so it seems quite tricky to use mprotect correctly.

[bjorn3]

At the AM level would it be possible to model mprotect using a fake thread which does non-atomic reads and writes to memory that it is told to do together with mprotect telling this thread (using appropriate synchronization) to start/stops doing accessing the passed in region in such a way that things the mprotect denies would become data-races? So for example if you do mprotect(region, PROT_NONE), then the fake thread would start reading and writing region (so any access by the user code would be a data-race), if you do mprotect(region, PROT_READ) it will only read (so writes by user code would be data-races) and if you do mprotect(region, PROT_READ | PROT_WRITE) it will not access the memory at all.

It would make LLVM's lowering to the CM unsound if it does speculative loads though unless you catch SIGSEGV for loads and write a garbage value to the destination register of the load if you do mprotect(region, PROT_NONE). Speculative stores aren't possible either way, right? So mprotect(region, PROT_READ) should be completely fine with current LLVM under this model I think (ignoring the fact that LLVM currently optimizes as if calls never contain atomic fences).

[RalfJung]

At the AM level would it be possible to model mprotect using a fake thread which does non-atomic reads and writes to memory that it is told to do together with mprotect telling this thread (using appropriate synchronization) to start/stops doing accessing the passed in region in such a way that things the mprotect denies would become data-races?

LLVM can still read from memory even when there are races, and that must not cause segfaults.

mprotect(region, PROT_READ) should be completely fine with current LLVM

Hm... LLVM thinks of write-write races as just overwriting memory with undef, so I don't think causing writes to trap is correct either. (I don't know if that model is coherent, though. AFAIK it has not been formally studied.) Allocations can be entirely read-only of course but I it's not clear when it'd be sound to change that state.

[ia0]

Trying to break this down, I see a few additional questions:

• Does the AM claim SIGSEGV? If yes then some form of disjointness is probably needed to decide which of the AM or the program (including ASM/FFI) is supposed to handle a given SIGSEGV.
• If the signal handler is written in Rust, is the AM aware signal handlers can run any time? I guess that's What is the opsem of signal/interrupt handlers. #444
• If the signal handler is not written in Rust, has anything it uses been "exposed" to ASM/FFI (and will be used according to the exposed permissions)?
• Does the AM understand mprotect? Just for completeness, I hope it's just an arbitrary FFI call.

[RalfJung]

The AM has no notion of segfaults. Signals in general are a separate topic that would derail this thread -- they are basically a funny form of threads; the AM says nothing about when they are invoked but can execute them when they do get invoked.

Does the AM understand mprotect? Just for completeness, I hope it's just an arbitrary FFI call.

Yeah it's just an arbitrary call, the problem is what it does to the AM state. LLVM could move memory accesses around in ways that could introduce segfaults. Generally, the AM assumes that memory it knows about is mapped and can be read (and written, for read-write memory) normally.

[ia0]

Yeah it's just an arbitrary call, the problem is what it does to the AM state.

I see, the question was about the mprotect call itself (namely what "equivalent Rust code" to give it). Since it doesn't take any pointer as argument, there doesn't seem to be many options.

If one wants stronger guarantees, they need to leak some pointers to ASM/FFI right before calling mprotect. That should be sound because whatever "equivalent Rust code" is needed for mprotect can be stuffed in the preceding ASM/FFI and have mprotect be a no-op from AM perspective (but not tell the AM so). So the AM can't permute those 2 calls and can't permute read/writes with the initial ASM/FFI, and thus not with the mprotect call either.

[comex]

I assume this is the right file to be looking at?

Let’s see if I can summarize the facts.

---

This involves a parent process ptracing a child process, where the child process executes unknown native code, and the parent catches segfaults through ptrace and contains most of the logic for toggling memory on/off. However, Linux doesn’t let you remotely change a process’s memory mappings. So the parent process forces the child to make its own call to mprotect. The parent does the following: (1) saves the old register state, (2) sets the stack pointer to a temporary stack and sets the instruction pointer to a helper function (mempr_off / mempr_on), (3) continues the thread, (4) catches a signal when the helper function is done, and (5) reverts to the original register state.

The above sequence is performed twice for each fault. First the parent uses the sequence to make the child call mempr_off, then the it makes the child execute the single instruction that faulted, then it makes the child call mempr_on, then it continues the child.

Because the helper functions are written in Rust, we have to consider how they interact with the AM of the child process (the AM of Miri itself, not the one being emulated).

---

Okay, now some observations.

First: This mechanism (backing up register state then forcibly updating the instruction pointer) is essentially the same mechanism that powers signal handlers. Here it’s being done by userland whereas signal handlers are managed by the kernel, but it’s the same idea. Therefore, for AM purposes we should likely model the helper function calls the same way we do signal handlers, i.e. as creating a separate AM thread.

Second: There is a window at the beginning of mempr_off where it has not yet called mprotect to make the pages accessible. Likewise, there is a window at the end of mempr_on after it calls mprotect to make the pages inaccessible. If these functions were to access the target memory in this window, there is no way to recover. Therefore, if it’s possible for LLVM to add such accesses, then the design is unsound.

Third: LLVM is never going to literally “move some memory accesses around the mprotect calls”. mempr_off and mempr_on never explicitly access the target memory at all, so there is nothing to move. There might be other accesses in the function that faulted, but LLVM has no idea that that control flow is going to be forcibly redirected from that function to mempr_off/mempr_on, so it’s not going to move code from one to the other.

But I suppose LLVM could hypothetically emit some code that dynamically decides where to access memory based on observed control flow, in a way that causes mempr_off/mempr_on to perform accesses that originated from the faulting code. This is never going to happen in practice, but I don’t know if anything rules it out. So perhaps the design is indeed unsound.

This concern could be avoided by writing mempr_off/mempr_on in assembly instead of Rust. But it would be pretty annoying if that were a soundness requirement.

[RalfJung]

I was originally thinking of these calls but have since reordered that code a bit so that part should be sound now.

I didn't even consider the calls done via ptrace hijacking the control flow... that's a whole other level of crazy from an AM perspective.^^

[VorpalBlade]

While this issue has so far centered on the miri use case, (PROT_NONE), another interesting case is that of JIT compilers: I have seen some that only enables writing to the JIT generated code while it is being updated, and only enable the executable flag while it is is not writing to the memory in question.

I would assume this should be fine as long as LLVM doesn't perform spurious writes. Calling into the generated code would be the equivalent of an FFI call, so it should also be fine (equivalent to dlopen/dlclose etc).