Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[olafBuddenhagen]

Hi,

On Tue, Dec 23, 2008 at 12:19:26PM +0100, Michal Suchanek wrote:
> 2008/12/22  <olafBuddenhagen@gmx.net>:

> > Well, *we* don't find EROS-like persistence useful for our purpose.
> > I never found it useful, as you might remember; and Marcus, who was
> > advocating it for a while, finally came to the very same conclusion.
> > (After stumbling over some site with various articles explaining the
> > issues much better than I can.)
> >
> > I'm not sure about Neal's current stance.
> 
> I am sure that I do find it useful.

And this is relevant, how?...

I told you that Coyotos is not useful for us; you asked why; I was nice
enough to explain. Your preference for a different system design doesn't
even come into play here... Coyotos is not useful for us, period.

> The user session is not the top process in any system I know. It is
> started by another system service.

What do you mean by "top process"?

The user session is obviously not the parent of all processes -- that
just wouldn't work in a multi-user system. But all processes *of the
same user* are descendants of the user session.

Now in Coyotos this doesn't mean much, as the parent doesn't directly
create a process, but rather just invokes the constructor. This way the
child process can have authority that the parent process doesn't have.
And the spacebank mechanism ensures that even though the resources are
usually supplied by the parent, it still has no access to the child's
memory contents.

In the hierarchical system we proposed the situation is very different
however. Processes are created directly by the parent, so they can't
have any additional authority; and the process handing out memory always
has full access to it. The user session has full control over all its
descendants, and thus all the user's processes.

> The 'drm memory' service is an addon which is possible to add to any
> system that implements memory protection.

In Coyotos, it's not an addon. Any memory can be used for implementing
secure DRM; the system provides and relies on the necessary mechanisms
throughout. This is precisely my point.

> For example, on Linux all the applications running as the same user
> can access the memory of each other and root can access all memory. So
> on Linux you would need a suid executable and a modification that does
> not allow the root user access to all memory. Given that several
> extensions for limiting the root account privileges exist (such as
> selinux) it should not be too difficult to add this feature somewhere.

I don't know much about SElinux etc. However, AFAIK they only limit the
power of the traditional root account, but *not* the power of the actual
admin.

Coyotos on the other hand is designed in such a fashion that once the
system is installed, nobody -- not even the admin -- has full control
over all parts of it.

But I wasn't even talking about that. Even if it *was* possible in
Coyotos for the admin to defeat a DRM mechanism, it would still require
active intervention to break it; while in the system we proposed it
require active intervention by the admin to install it in the first
place.

> However, security involving hardware encryption and verification of
> system integrity by means of hardware cryptography device can enforce
> the 'drm protection'. Some applications might refuse to run on system
> that is not known to implement effective protection.

As I already said, this is precisely why TPM (remote attestation to be
precise) is so dangerous, and why we need to fight it tooth and claw.

> > What I want is a system with only one integral part -- being mostly
> > UNIX-compatible and UNIX-like be default, and yet offering many new
> > possibilities; more generally, giving the user much more control
> > over the environment.
> >
> > This is what the Hurd provides.
> 
> Thus I find the Hurd unsatisfactory.

Yeah, we already gathered this much. In fact, I said myself that in view
of your expectations, the Hurd is obviously not the right system for
you.

I wonder, what exactly are you trying to achieve by prolonging this
discussion?

> It provides only the ancient broken interface with many inconsistent
> APIs to both legacy and native applications, and only allows
> introducing new features by manipulating something 'behind the
> scenes', outside of the advertised POSIX personality.

"allows"? "behind the scenes"? What are you talking about? It is
perfectly possible, allowed, *and encouraged* to create alternative
interfaces in the Hurd. This is what the Hurd design is all about!

As I already said, it should be perfectly possible to create a
completely new personality, if that's really what you want. It might
even become part of the standard Hurd, if it proves useful -- although
the main personality will most likely always be the one built around
POSIX.

It's all about focus, not about possibilities.

> Since the new applications should run isolated there should not be
> much difference between running a native applications and a POSIX
> application inside an isolated POSIX environment once you find out
> what support configuration and tools POSIX applications typically
> expect.

We are talking about different kinds of "isolation".

Obviously appliactions need to be protected against harmful
interference. However, that does *not* mean total isolation. They still
can, and should, uses common mechanisms, common interfaces, common
services -- integration between different applications is a must. And
this is just not realistic if different applications run in completely
different environments. Only applications using more or less the same
personality can be properly integrated; and if we care about POSIX
applications -- which we do -- this personality must be based on POSIX.

This is not what you want? That's fine: we can live with that; and I'm
pretty sure you can do so as well. We have our priorities, you have
your's. It's not our fault that these don't match. Stop telling us we
are doing something wrong.

-antrik-