Re: How to add confinement to the Hurd?

[Marcus Brinkmann]

At Sun, 30 Apr 2006 20:29:28 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> We have so far two different confinement types discussed, that I will
> continue to call trivial and non-trivial confinements. To some of us, at
> least to Marcus (who shall expose us at long the arguments in the
> future), there is an ethical issue in implementing non-trivial
> confinement.

I can even tell you why there is an ethical issue.  The reason is that
non-trivial confinement separates ownership of digital content into a
party that has access and modification right and a party which has the
right to decide durability.  If these two parties are different,
ownership is diversed, and immediately raises matters of political
nature (when applied to any real-world scenario).

> So my questions are:
> 
> 1) Do anyone knows, even remotely, what would be needed to implement
> this confinement in the Hurd? Particularily, what would be needed for
> the implementer to do, and what could prevent him to do it in the Hurd
> design?

The underlying mechanism is, at the hardware level, a "trusted
computer" chip, which is a chip that contains a cryptographic key
which _nobody_ can read out and which is certified by the manufacturer
of the hardware.

At the operating system level, the mechanism is the kernel-supported
confinement check and a bunch of supporting user space servers (at
least the space bank and the meta-constructor, plus the actual
constructors used for program instantiation).

You can read all about it in the mailing list archive from last
october and november, plus in the EROS papers.

> 2) If someone implements this, will it be integrated in the Hurd, even
> if disabled by default?

This doesn't even make sense if the issue were not contentious.

> 3) What will I eat now?

Pizza :)

Marcus