CheriABI: mmap should restrict permissions on returned capabilities

[brooksdavis]

mmap() currently returns a capability with the same permissions in all cases. It should honor PROT_* flags appropriately.

[rwatson]

One tricking thing about mmap(2) is that the user process can later request changes in mapping permissions using mprotect(2) that may have more rights than those originally requested for the mapping. The kernel keeps track of both the requested permissions, and also maxprot: the max permissions we can allow for the mapping should mprotect(2) be called.

One approach might be to have mmap(2) return a capability based on requested permissions, and that a new API (something like) cheri_mprotect(2) returns a new capability with the revised requested permissions. This has some non-ideal properties -- e.g., that applications using the unmodified mprotect(2) semantics might experience surprises if they request, for example, removing write and adding execute permission would still have a capability without write permission, regardless of what the MMU believes. The current model caters to that problem but has the disadvantage of having a very privileged capability.

[davidchisnall]

A concrete example of this from libobjc2 (something very similar is in Apple libobjc):

The imp_implementationWithBlock function takes a block and returns a method pointer. Block invoke functions have the block pointer in the first argument and, in this case, will have the receiver as the second. Objective-C methods have the receiver as the first argument and the selector as the second. This function will return a pointer to a small trampoline that will move the first argument (the receiver) over the second and then jump to the block invoke method.

The implementation allocates pages in pairs. The first contains the jump targets. The second contains the trampoline. The trampoline reads from $pc - 4096 to get the correct value. We use valloc (which wraps posix_memalign, though we could use mmap directly) to allocate the two pages, which are initially read-write. We then fill in the trampolines and map the second page read-execute (I believe that the Apple implementation stores a page of trampolines in the executable and just mmaps them in the right place). We must then derive a capability that has read access to both pages, the offset of the trampoline that we're using, and read-execute permission (and with the MMU removing the execute part for the first page, which is writeable via a different capability).

This currently works, because posix_memalign is missing in libmalloc_simple, so we use mmap directly and mmap returns a read-write-execute capability.

This is a very simple form of the mechanism required by any JIT. We will need to:

1. Allocate some memory
2. Write to it
3. Make some of it executable
4. Hand out function pointers to it, while keeping parts of it writeable / keeping writeable capabilities

Ideally, I'd like to not lose the MMU protection (which, for this, is enforcing W^X for each page), even when we have capabilities that can write and capabilities that can execute the whole range.