Re: Future Direction of GNU Hurd?

[William ML Leslie]

On Wed, 24 Feb 2021 at 03:22, Olaf Buddenhagen <olafbuddenhagen@gmx.net> wrote:
>
> Hi,
>
> On Sat, Feb 20, 2021 at 12:07:27PM +1100, William ML Leslie wrote:
> > On Sat, 20 Feb 2021 at 03:23, Olaf Buddenhagen <olafbuddenhagen@gmx.net> 
> > wrote:
>
> > > Is there a good generic term for a capability referencing the receive
> > > end of an IPC port, such as the receive right in Mach?...)
> >
> > I don't know if there's a generic term.  In Coyotos we have the
> > endpoint.
>
> Yeah, I was thinking of "endpoint"... Indeed that's how I stumbled upon
> the seL4 docs!
>
> > The seL4 team were smart enough to pilfer plenty of design and
> > terminology from Shap, so they have endpoints too.
>
> Here's the thing: it appears that in seL4, an "endpoint" is the IPC port
> itself -- with an endpoint capability referencing either the sender or
> the receiver end. (Or both.)
>
> However, if in Coyotos "endpoint" clearly denotes the receiver end, I
> guess that's good enough for me in terms of precedent :-)
>

Yes, but it's maybe not so clear.  An endpoint is the name for the
entity in the system for receiving messages and it is configured using
an endpoint capability, enabling you to listen on it.

The sender instead has an entry capability (although the object it
names is also the endpoint).

> > > The issue was that the cost of the user-space services that would be
> > > needed to properly run a Hurd-like architecture on top of the
> > > original L4 (without kernel capability support) turned out to be
> > > prohibitive...
> >
> > IME so far, you don't have to implement all of Mach IPC.
>
> That's never been the plan, to the best of my knowledge... That would
> remove most of the point of moving away from Mach.
>
> The idea was just to implement *some* sort of capability-based IPC. (And
> some sort of asynchronous communication ability...)
>

Oh. I'm not sure of what that cost might have been, then.  Do you remember?

> > Mach IPC may be a beautiful mostly-asynchronous channel supporting
> > large, sophisticated message types; but in practice the interfaces
> > that Hurd provides are not that ugly, and neither are those that GNU
> > Mach implements.
>
> The message typing is really the least important aspect of Mach IPC
> IMHO... What makes it pretty convenient for writing interfaces with
> little abstraction, is the way in handles senders/receivers,
> notification etc., in a way that feels very natural in most situations.
> Unfortunately, that pretty much depends on the kernel buffering, as far
> as I can tell -- so it's not really a good design in practice...
>

I am still hopeful that someone will figure out how to do async right
at some point.  The seL4 people haven't figured it out, and I've got
three different approaches, all with their own serious drawbacks.

> > There are definitely other impedance mismatches, but none of them are
> > scary.
>
> In my understanding, aside from the async communication question, the
> main point of contention was the use of protected constructors: Marcus
> ultimately concluded that they don't align with the GNU philosophy --
> proposing a strictly hierarchical structure instead. (Much like what
> Genode emerged with at around the same time, as I understand it...)
>

Not that this has anything to do with whether someone can port The
HURD to an L4 or Coyotos like architecture:

I am as convinced today as I was back when Marcus first ranted about
ownership and shopping trolleys that he was mostly wrong (12 years
ago? before I kept logs).

If you're running an operating system locally, you absolutely want
(and already technically have) the ability to subvert any software
protections, including factories.  You may as well reify this as a
capability so that programs you nominate can peek into attempts at
mutually secure collaboration.

If the computer you're operating on is some sort of shared hosting
situation, you probably want your provider to be audited /not/ to be
able to peek inside anything that you created using a factory.  Real
security actually improves user freedom; more so given just how broad
the sort of attacks that are not only possible but are exercised are
becoming.

> > The Single Level Store drivers in CapROS look like they have much more
> > predictable behaviour than an adaptive cache.
>
> Excuse my ignorance: but isn't the single level store concept closely
> related to orthogonal persistence? That would be a controversial choice
> for a Hurd-like system, to put it mildly...
>

Yes, not really, and also not what I was talking about.

Firstly, the tricky thing with accounting memory in Unix.

Let's assume you want to do hard memory accounting as a first pass.
This means a process can't go and map memory that you don't have swap
for.  If a process attempts to map a copy and the pages aren't
available in memory or swap, it will fail in the call to map.  Now
you've got reliable failures on memory limit problems.  This may break
some applications, but at least you get sensible error messages so
that you can fix the application or free memory.

The problem, however, is fork().  Fork is tricky because how much
memory do you account to the child?  If you need to account everything
mapped COW into the address space of the parent, then large processes
won't be able to start other processes, even if those children would
immediately exec.  If you don't account everything COW in the parent,
then you have a situation where a process can run out of memory
without explicitly allocating it.

What I would personally like is precise accounting by default (as in
the SLS), and lazy accounting on fork by request.  That way I could
still run firefox when needed, yet have a system that is much more
stable under memory load than anything traditional.

--

Also: running the hurd directly out of the SLS means I avoid the need
to bootstrap it the same way we do on Mach: dynamic linker needs the
filesystem, so filesystem must be statically linked.  TBF all my
programs so far are statically linked, but having a really simple
filesystem like SLS to strap from instead of ext2 is very convenient.

-- 
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.