l4-hurd
[Top][All Lists]
Advanced

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

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


From: William ML Leslie
Subject: Re: Constructors vs. GNU (was: Future Direction of GNU Hurd?)
Date: Tue, 23 Mar 2021 08:23:21 +1100

There seems to be a bit of confusion about what EROS' notion of
constructors can do.  I'm certainly partly responsible for that.  Lets
see if I can start from the top, because it seems that constructors
are the exact opposite of what they have been described to be.

There's this really nice property of a non-persistent system in that
since programs live on disk, they don't usually carry any authority.
Programs are, for the most part, effectively immutable in that they
contain some program text and some initial data, and the only
authority that they have comes from the exec server (or unix kernel
etc).  The exec server grants them access to things like a filesystem
to run in, standard streams, a network namespace etc.  The question
is, how can we have the same assurance in a system built on live
objects, such as smalltalk or EROS?  How can we know that an object
does not have the ability to talk to any other objects, or write
access to anything?  The answer is, we know that an object is
effectively pure if it is a constructor.

A constructor contains only "sensory" capabilities, that is,
capabilities that do not affect the state of the system.  These are
normally its program text and its initial data.  When you run a
constructor, you provide it with other things it needs - some way to
get mutable pages, some way to receive input and send output etc.  A
constructor almost represents an immutable function, although there is
one caveat in that someone else may retain write access to their
read-only data and be able to perform updates etc. The point is,
however, that nothing the caller feeds to the program - authority or
data - may leak back to the manufacturer.

If you are wondering how anyone could have lept from "basically a
function" to "could be used to enforce DRM", the key observation is
that although they couldn't be used to connect to a proprietary
service, they *could* be used by one program of the system to hide
data or an algorithm from another.  That is, they could be used to
hide "proprietary algorithms" from other users (where "user" is very
abstract).  And to be sure, it's not constructors that make this
possible - it's another part of the system, which I'll break down in
another email - but the fact is, it's easy enough for us to work
around, because a constructor does not hide data from a user, but
between its caller and its manufacturer; and for the user it can be
trivial to subvert.

I'm not sure quite how the usual "abuse of constructors to enable DRM"
was supposed to go, so I'll tackle both sides of the constructor.

If someone is compelling you to *provide* a constructor, that is,
someone is compelling you to hand them a reference to a function that
the system can confirm is pure, note that the check is not some
irrefutable, mathematical analysis.  The system can flat-out lie.  For
existing security reasons, the output of the "is this a constructor?"
check is a boolean, so the one compelling you to provide a constructor
must rely on the system under your control to verify it.  And of
course in EROS variants operated by a person, it's usually reasonable
to give the person the ability to make it lie, that is, the user
should be in control.

If someone has provided you a constructor and is compelling you to
*use* it, we have to ask, how did they build it?  You can't "download"
a constructor, you can download some instructions for building a
program and that program could then be a constructor.  To do so, they
must use the tools you provide to build it.  So they should assume
that these tools are in cahoots with you.  Of course, they are and
should be in a GNU system.  I'll lay out the precise mechanism for
this in my next email, as it involves the part of the system that I
said "actually makes it possible" in the next email.

I'm running out of battery though, so it might not be this morning.
I'd like to address your points specifically too, but I thought it
best to clear the air and highlight what constructors actually do
first.

Shap:  if you have time to look over this one, can you please confirm
that I've not completely misunderstood you and Norm in new and
exciting ways?


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



reply via email to

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