Email or username:

Password:

Forgot your password?
Top-level
Sergey Bugaev

@civodul

So yeah, the Hurd servers aren't much different or any more "external" to the environment than /bin/sh. I don't think you should be firmlinking stuff from the host; you should probably just spawn a mini subhurd for each build. You want pipes and fork/exec, so you need pflocal, proc, and exec servers.

@janneke

14 comments
Sergey Bugaev

@civodul

(Also /servers/proc, mentioned in your mail, is not a thing, of course 🙂 — the proc server is one of the two servers, the other one being auth, that are not accessible through the file system, but only through _hurd_ports.)

@janneke

Sergey Bugaev

@civodul

Your mail about /bin/sh also raises an interesting topic of paths. Do you want to change /dev/null and /servers/exec to some other (hash-derived I would imagine) paths? Sounds wild but you totally could!

You could then either patch glibc (and everyone who expects to find /dev/null at its usual place), or provide symlinks. But then again I don't know enough about Guix to judge here.

@janneke

Sergey Bugaev

@civodul

Unfortunately all this wouldn't help you too much with bootstrapping from source, since you cannot do I/O easily on the Hurd like you can on Linux with a few instructions; you need to do RPCs and all that (even to get your argv). This is of course hidden from you when you're using glibc.

@janneke

Sergey Bugaev

@civodul

> Also, one could argue that things like /dev/null have a well-defined interface that’s set in stone and that, consequently, how they’re implemented does not matter at all.

Yes, but also no: there certainly can be differences in behavior that are allowed by the interface (where it explicitly doesn't guarantee something), but (due to bugs) can influence the outcome. For instance, does every write to /dev/null always write the whole buffer, or can there be short writes?

@janneke

Sergey Bugaev replied to Sergey

@civodul

Or: can a signal interrupt a write to /dev/null? (On SerenityOS the answer used to be no, on the Hurd it's a resounding yes, dunno about Linux.)

@janneke

Ludovic Courtès

@bugaevc Exactly! So the question becomes: assuming you have nothing but the Mach syscalls at your disposal, what chain of programs building on each other would eventually let you run a proc and an exec server so you have the beginning of a POSIX build environment?

The whole stage0/M2/Mes story on Linux was quite a puzzle; its Hurd version would push it further. :-)

@janneke

Ludovic Courtès

@bugaevc The Hurd code lives in /gnu/store/…-hurd-*, but the translation points in the build environment would remain /dev/* and /servers/*. Changing that would be impractical and bring nothing.

@janneke

Sergey Bugaev

@civodul

Here's a fun little problem: if you have lost your proc and auth ports, but still have your fs root dir port, how can you recover those two?

@janneke

Ludovic Courtès

@bugaevc Possibly (but not necessarily) by looking up /servers/proc for the first one; as for auth, it’s forever lost?

@janneke

Ludovic Courtès

@janneke @bugaevc Actually I keep making the same mistake: there’s no /servers/proc but for some reason we have it in childhurds, just with no translator on it (I may be the guilty party :-)).

Sergey Bugaev replied to Ludovic

@civodul

Yes, /servers/proc is not it :)

I was thinking of the following scheme, which I have not tried, so this is just a theory.

You create an executable (perhaps as an unnamed file) that is setuid to yourself, and then exec it (not over your own task, unless you want that), without passing an auth or proc ports (as you have none).

@janneke

Sergey Bugaev replied to Sergey

@civodul

The translator notices this and creates a new auth handle based on its idea of your effective uids/gids (see libfshelp/exec-reauth.c); and then the exec server gives the new task a fresh proc port. You cannot access the new task because of setuid/EXEC_SECURE, but as you created the executable you still control what it does.

@janneke

Sergey Bugaev replied to Sergey

@civodul

In particular it may send its proc/auth ports back to the original task, and the original proc port may then be recovered by a simple

proc_task2proc (other_proc, mach_task_self (), &my_proc)

The exact auth port I don't think can be recovered, but at least you now have another auth port with your effective uids/gids.

@janneke

Go Up