On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > So we still have to mmap across the network. We certainly don't want to > avoid mmap's entirely for program text and (especially) for shared > libraries. Although I admit that it would be best to detect when the mmap > fails and fall back on ordinary reads.
Again, we could avoid mmap entirely by passing memory out-of-line, with copy-on-write zero-copy. When I say zero-copy, it means that the underlying memory will not be actually copied until accessed. > The obvious additional client would be a remote kernel, but as the exploit > program that I posted shows, it could just as easily be an unprivileged > process. You don't need much permission to get a memory object, just read > access on the file. OK, this comes from the fact that io_map directly provides memory objects indeed... Do we actually want to pass them around ? How come calls like memory_object_init (specifically meant to be used between the kernel and the pager) can be made from any client ? If we don't want to pass them around, we could instead let the server handle the mapping on behalf of the client, but this violates Hurd's principle of "mutually untrusting clients and servers". Although I personally believe this principle is impossible to apply in practice (one basic denial of service is to merely sleep and never wake up, where an explicit action from the user is required to break the ipc call, no different in practice from killing a process), I recognize the user might want to apply his own policy to the mapping, so it might be advantageous to allow passing the memory objects anyway. If we consider Unix as a reference, then the map call uses a file descriptor. It's equivalent to a memory object because the translation is done privately in the kernel, but we could also change the mapping interface to provide some proxy object to the client, which could be thought of as an unprivileged memory object. When mapping, the kernel would then invoke the proxy object to obtain the memory object, which, in addition to replacing mmap with COW zero-copy, solves the problem. What I'm stressing here is the importance of viewing a memory object as a private communication channel between the kernel and a pager. The changes involved here are heavy, which is one reason we'd want to avoid them. It also makes the system slightly slower by adding a new layer of abstraction. So we may just want to support multiple clients at the pager level, but I really don't see the benefit other than "it works". You really need to justify why it's a good thing that any unprivileged client is allowed to perform memory object management calls... -- Richard Braun
