Re: Constructors vs. GNU (was: Future Direction of GNU Hurd?)

[William ML Leslie]

On Sun, 21 Mar 2021 at 05:08, Olaf Buddenhagen <olafbuddenhagen@gmx.net> wrote:
> Now the user is dealing with a piece of software they don't control:
> that they can't inspect or modify; that requires trusting third parties
> to follow the desires of the user -- supposedly for their own good...
> Software that they can't fix for bugs, annoying behavious, missing
> functionality etc.; and that could also have any number of intentional
> anti-features: be it backdoors, cryptominers or other trojan horses;
> adware; or digital restrictions management. Literally everything that
> Free Software is supposed to protect users from.
>

So here's my thinking on the subject, and how Coytotos provides what I want.

If I am given a program to run on my personal system - whether I
download it from the internet or get it from some other source - I
want it to be confined.  I don't want it to have access to any of my
stuff.  However, I don't want it to be confined *from me*.  If I want
to debug a program I'm handed, I should be able to.  I should be able
to inspect and modify its memory, make requests on its behalf etc.
Thankfully, in the capability model, there's nothing strange about
this.  The program doesn't have access to anything other than what I
have handed it.

It's actually pretty easy to get this behaviour in Coyotos.  Coyotos
only provides functionality and isn't very prescriptive about how you
use it.  Part of building a system on Coyotos is adapting your system
model to the primitives it provides.  For example, Coyotos has
Processes (somewhat akin to Mach threads), GPTs (a completely
different level of abstraction to, but still somewhat like, a Mach
task's vm map), process constructors, scheduler capabilities etc.
Building something that looks and feels like a GNU process on top of
these primitives is absolutely possible, and it doesn't have to have
the same constraints.  For example, there may be no need for a process
to have direct access to its process capability, GPT, or the process
constructor.  Instead we have servers that implement the interface
that GNU programs expect.

By the same token, it's feasible to implement Coyotos in Coyotos and
even be able to debug Coyotos-native applications.  It's mechanism and
not policy; it's capabilities all the way down.

Part of implementing the system you want using these primitives is
implementing memory allocation and management using the existing
Coyotos spacebank.  It's true that spacebanks do not automatically
grant the ability to access pages granted in a child bank to the
holder of the parent bank, which is a good thing.  However, the memory
manager that the system uses to provide applications with the mappings
they need is free to manage its bank hierarchy and the pages it
provides as it seems fit.  This won't help when communicating outside
the system - communicating to a process that requires a real space
bank, such as the native process creator - but it means that within
the higher-level system, you are free to implement whatever security
model for memory you like.

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