On Sun, Aug 28, 2016 at 12:49 PM, Richard Braun <rbr...@sceen.net> wrote:
>
> I'm really not seeing the relation between "multiple clients" and
> "multiple threads". Libpager must be able to handle multiple clients
> with a single thread, otherwise we don't control scalability and we're
> back to where we were before Justus' rework...
>
Are you referring to the work about two years ago to use a fixed number of
threads?
libpager handles multiple clients with a single thread, but I don't think
it can handle multiple clients for a single file.
In ext2fs/ext2fs.h, we find:
/* ext2fs specific per-file data. */
struct disknode
{
...
/* This file's pager. */
struct pager *pager;
...
};
which suggests a single struct pager for each file, right? And in
libpager/priv.h, we find:
struct pager
{
...
/* Interface ports */
memory_object_control_t memobjcntl;
memory_object_name_t memobjname;
...
};
which suggests only a single client, with a single pair of control/name
ports, for each struct pager.
I'm saying that the struct pager needs to have a list of multiple clients,
with multiple control/name port pairs.
> And again, I think it's much easier and much more helpful to change
> exec and others to _avoid_ mmap, and copy the data in instead,
> possibly (and in this case probably) with zero-copy.
>
I should elaborate on what I found with exec. After I fixed the problem
with the exec server mmap'ing the library's ELF headers, it just got on a
little bit further in the process, and then croaked when it tried to mmap
the program binary itself.
Assume two hosts, Alice and Bob. Alice has mounted a remote file system
from Bob and now tries to execute a file residing on Bob. So we have the
new task and the shared libraries, both on Alice, and the exec server and
the program binary, both on Bob. Bob's exec server will try to mmap the
shared library headers into its own address space to examine them, which is
a problem. Once we get past that point, the exec server tries to mmap the
program binary (on Bob) into the new task (on Alice). Bob's ext2fs
translator now has a new memory object client - Alice's kernel.
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.
> Finally, I fail to see how making libpager handle multiple clients
> will solve that issue. The only client should be the local kernel,
> right ?
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.
agape
brent
