On Thu, Aug 25, 2016 at 12:20 AM, Richard Braun <rbr...@sceen.net> wrote:
> On Wed, Aug 24, 2016 at 07:24:16PM -1000, Brent W. Baccala wrote:
> > So, I'll modify libpager to handle multiple clients. Not trivial, but it
> > seems necessary and correct.
>
> Don't start that immediately, wait for more discussions. I'm not so
> sure it would make sense to support more than one client.
>
>From the Mach 3 Kernel Interfaces document, page 149:
If a client thread calls *vm_map* to map a memory object while the kernel
is calling *memory_object_terminate* for the same memory object, the
*memory_object_init* call may appear before the *memory_object_terminate*
call. This sequence is indistinguishable from the case where another kernel
is issuing a *memory_object_init* call. In other words, the control and
name ports included in the initialization will be different from those
included in the termination. A memory manager must be aware that this
sequence can occur even when all mappings of a memory object take place on
the same host.
It sounds like the Mach designers anticipated multiple clients for a memory
object server.
> One question is whether the exec server really needs to do a vm_map to
> > examine an ELF header. A simple read would suffice. Which should be
> > preferred?
>
> I agree that read should be preferred. In a completely separate
> non-existent issue, it would be the only way to support nommu systems.
>
>
OK, then I'll take a look at changing that. Easier than a pager handling
multiple clients.
> > A more serious question is why the exec server is running on the server
> > side at all. Shouldn't it be running on the client? Then the only
> network
> > operation it would need is to map the one file that it's trying to
> execute.
> >
> > Examining diskfs_S_file_exec reveals some interesting behavior. The file
> > server caches a port to its exec server, so the same exec server gets
> used
> > by all of its clients! Furthermore, it gets the exec server in the first
> > place by looking up _SERVERS_EXEC in its own name space, not the
> client's!
> >
> > Shouldn't the exec server be looked for in the client's name space?
>
> You're getting into the same kind of "light virtualization" issues we
> have with e.g. chroot. Many operations are done by servers, from their
> execution context, and this breaks that kind of behaviour.
>
> I started thinking about these only a couple of weeks ago, and so far
> the only solutions my limited brain can come up with is to either use
> the client context (by perhaps passing its root) but that could cause
> security issues, or have a third-party like auth (or proc or whatever)
> store enough of this context that the server can use it.
>
Actually, the exec server is already being passed the client's root, so it
could easily use that handle to lookup _SERVERS_EXEC. The question is:
should it?
agape
brent
