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

netmsg can now exec files (sort of)

[Brent W. Baccala]

Aloha -

I've gotten 'netmsg' to the point where files in the mounted, remote
filesystem can be executed on the local machine.  This isn't remote
execution - it's just copying the files to the local machine and executing
them there.  Nothing more than what you'd expect from NFS or Samba, but it
works.

'libpager', as we've discussed, can't handle multiple clients, and some
extra effort is required to avoid this limitation.  You need a custom exec
server that doesn't attempt any mmap()'s.  It's a simple patch, but not one
we want in the mainline code, except perhaps for testing purposes.  Anybody
see any reason for a --no-mmap flag to the exec server?

Unfortunately, my patched exec server doesn't work as /hurd/exec.  The
system freezes right after the "Hurd server bootstrap" line, and I've spent
the afternoon trying to figure out why.  At first I thought it was a
problem with my exec server executing shell scripts (runsystem.sysv, to be
specific), but I now realize that this is a bug in the standard exec server
executing shell scripts.  I filed a bug report; it has to do with
re-authentication, so I'd rather somebody else sign off on how to fix it.

In the mean time, I'm still wondering why an mmap-less exec server won't
boot my Hurd.

Obviously, this is a Band-Aid.  We don't want a mmap-less exec server; we
want libpager to handle multiple clients, right?

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

netmsg

[Brent W. Baccala]

Aloha -

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

Basic usage:

netmsg -s (server)

settrans -a node netmsg localhost (client)

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.

Nevertheless, ls, cp, mkdir all work through it.

I'm going to keep plugging away at it; let me know what you think.

Richard was right, by the way - it was best to just start over from scratch.

agape
brent