Re: netmsg can now exec files (sort of)

[Richard Braun]

On Mon, Aug 29, 2016 at 03:56:00PM -1000, Brent W. Baccala wrote:
> I've figured out why the patched exec server didn't work with mmap, and
> just opened a bug on it, with a fix attached.
> 
> So now I've got a working, mmap-less exec server that burns a lot of extra
> RAM (each process gets its own private copy of the C library), but lets me
> execute files across a netmsg TCP/IP session.
> 
> I think the next logical step is to get it to attempt an mmap, and only
> fall back if that doesn't work.

You might also want to consider making the mmap-less case more
efficient by carefully copying the data. I didn't insist on
COW zero-copy for no reason.

-- 
Richard Braun

Re: netmsg can now exec files (sort of)

[Brent W. Baccala]

I've figured out why the patched exec server didn't work with mmap, and
just opened a bug on it, with a fix attached.

So now I've got a working, mmap-less exec server that burns a lot of extra
RAM (each process gets its own private copy of the C library), but lets me
execute files across a netmsg TCP/IP session.

I think the next logical step is to get it to attempt an mmap, and only
fall back if that doesn't work.

agape
brent

Re: netmsg

[Brent W. Baccala]

On Tue, Aug 23, 2016 at 11:45 PM, Brent W. Baccala 
wrote:

>
> Any ideas why this basic sequence wouldn't work?
>
>node = file_name_lookup("/lib/ld.so", O_RDONLY, 0)
>io_map(node, , )
>/* create control and objname with send/receive rights on both */
>memory_object_init(rdobj, control, objname)
>
>
The answer is that libpager can only handle a single client.

agape
brent

Re: netmsg

[Brent W. Baccala]

On Tue, Aug 23, 2016 at 2:12 AM, Richard Braun  wrote:

>
> > It's got a lot of problems.  No authentication handoff; everything the
> > client requests happens with the permissions of the server.  exec'ing a
> > file doesn't work; the last RPC before the hang is memory_object_init.
> > emacs doesn't work; the last RPC before the hang is io_reauthenticate.
>
> That's a very interesting problem indeed, not sure how to fix it.


I've looked into it a bit more.

The auth server is going to be more trouble than I anticipated because it
depends on using Mach ports for rendezvous.  A send right, after transfer
across a TCP/IP connection, will appear to be a completely different port.
I'll think about it more.

The exec problem, on the other hand, is more of a puzzle.
memory_object_init gets sent, but we never see memory_object_ready in
reply.  Of course, we're getting memory_object_init from a user process and
not the kernel.  So I wrote a little test program to try sending
memory_object_init from a user process and, sure enough, no
memory_object_ready.

Any ideas why this basic sequence wouldn't work?

   node = file_name_lookup("/lib/ld.so", O_RDONLY, 0)
   io_map(node, , )
   /* create control and objname with send/receive rights on both */
   memory_object_init(rdobj, control, objname)

...and now I expect to see memory_object_ready on control, but it never
happens.

agape
brent

Re: netmsg

[Richard Braun]

On Mon, Aug 22, 2016 at 04:40:58PM -1000, Brent W. Baccala wrote:
> I've gotten a basic netmsg server/translator running that relays Mach
> messages across a TCP/IP connection.
> 
> The code is available at g...@github.com:BrentBaccala/netmsg.git

That's great.

> It's got a lot of problems.  No authentication handoff; everything the
> client requests happens with the permissions of the server.  exec'ing a
> file doesn't work; the last RPC before the hang is memory_object_init.
> emacs doesn't work; the last RPC before the hang is io_reauthenticate.

That's a very interesting problem indeed, not sure how to fix it.

-- 
Richard Braun