[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Direction of GNU Hurd?

From: Olaf Buddenhagen
Subject: Re: Future Direction of GNU Hurd?
Date: Sun, 14 Mar 2021 18:57:09 +0100
User-agent: NeoMutt/20170609 (1.8.3)


On Thu, Feb 25, 2021 at 06:48:11PM +1100, William ML Leslie wrote:
> On Wed, 24 Feb 2021 at 03:22, Olaf Buddenhagen <olafbuddenhagen@gmx.net> 
> wrote:
> > 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.
> 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).

I see. Will have to think about whether this terminology makes sense for

> > > > 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...
> > 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?

I don't remember the specifics of how the user-space capability server
was supposed to work: but in my understanding, it would add a lot of
additional context switches -- on top of any handling done in the
capability server itself...

> 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.

Care to elaborate on these approaches? While I personally don't consider
it a priority to settle on a specific design for this, it certainly
wouldn't hurt to have some food for thought :-)

> 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).

I'm too lazy to dig through the archive (which BTW is also available on
the web): but from my recollection of events, it must have been around
2006 or 2007.

> 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.

Well, there is likely nothing we can really do with the system design
that could prevent others from creating and certifying a setup without
an almighty admin. Whether it's a good idea or not to provide this
ability by default is a different question... But actually mostly
orthogonal as far as I can tell from the question whether we want to
provide a privileged constructor mechanism.

Part of the problem with this discussion is that to a large extent, it's
actually a question of how we look at things. We inevitably do need the
ability to invoke privileged services, that deal with resources we don't
have direct access to; and in order to prevent DoS, we also inevitably
need the ability to furbish such privileged services with resources
provided by the invoker, but which the invoker can't access while they
are in use by the service. No matter what we think of this from a
philosophical standpoint: there is really no way around that. Also, most
likely we want to give the invoker (and its ancestors, at least up to
the user session) some amount of control, so they can abort the request,
and reclaim the resources provided.

Where things get contentious is how such privileged services are
implemented exactly; how they are presented to the user; and how much
the general system design builds upon this facility.

A privileged constructor, as far as I understand it, is really just a
type of privileged service, that creates a new child process to serve
each request, and makes that process appear as if it was a child of the
invoking process. (The Unix SUID mechanism is pretty much the same --
apart from the mess with the inherited client environment...)

The first issue is arguably that the creation of a process to service
the request is just a technical detail, that should be transparent to
the invoker. The invoker doesn't need the ability to see the process (or
even know whether there is one at all): it only needs the ability to
abort the request -- whether that involves killing a process or uses
some other mechanism.

More importantly though, I believe that it's a bad idea to make the
process appear as a child of the invoker: giving the impression that it
owns that process, when in truth it doesn't. It presents a false process
hierarchy, that doesn't reflect the actual ownership relations. Not only
is this misleading: but I feel that it encourages a system design that
relies on this mechanism more than it should, needlessly disempowering
the user.

When I'm talking about a strictly hierachical system, I guess what I
really mean is a system that strictly reflects the true ownership

(I'd have to dig up and re-read the original discussion to be sure: but
my guess would be that the point of Marcus's metaphor was simply to
illustrate that we don't really own a process, unless we have full
control over it...)

> > Excuse my ignorance: but isn't the single level store concept closely
> > related to orthogonal persistence?

I thought about it a bit more. In my understanding, "single-level store"
simply describes the concept of treating main memory as a cache for the
backing store.

Technically, of course you could forego the persistence, i.e. don't keep
the backing store (more or less) in sync with data in main memory --
though I'm not sure whether the term still means much in that case...

> 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.

I'm not convinced this would actually improve stability...

But more to the point: why would that be harder to implement with a
traditional filesystem? Unless I'm missing something, this seem like a
pretty simple change to make...

> 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.

I don't see a fundamental difference... Whether it's ext2, SLS, or some
sort of RAM disk: in each case you need a driver that can be loaded by
the bootloader?...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]