Re: exec server behavior

[Brent W. Baccala]

On Thu, Aug 25, 2016 at 12:20 AM, Richard Braun <rbraun@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