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

[olafBuddenhagen]

Hi,

On Fri, Jan 09, 2009 at 06:22:27PM +0100, Michal Suchanek wrote:
> 2009/1/3  <olafBuddenhagen@gmx.net>:

> >> Yes, the system provides a service out of the box that provides DRM
> >> memory which might be a step towards DRM content protection. I do
> >> not like the feature but I have not seen a secure system design
> >> without such feature, either.
> >
> > Well, as I explained, we believe that we can build a system
> > providing the kind of security *we* are interested in, without such
> > mechanisms.
> 
> Yes, I would like to see such system. As of now I do not feel
> capabable of deigning one myself nor has anybody designed one I am
> aware of.

I recently stumbled over a research system called Genode:

   http://genode.org/documentation/general-overview

I haven't looked at the details of the architecture; but it seems from
the overview that the hierarchical approach they are employing is very
similar to our ideas.

(May not be a coincidence, as Neal Walfield was at the same research
group for a while I believe...)

But it doesn't really matter whether such systems already exist or not.
The point is that this kind of design is what we are interested in; not
the design Coyotos is implementing. We believe that it can work, and
will persue it, unless someone proves otherwise.

> >> You can shut down Coyotos and look at the on-disk image.
[...]
> > More importantly, the fact that you can theoretically manipulate the
> > disk image of a Coyotos installation, doesn't mean it's actually
> > feasible in practice.
> >
> > This is a common theme in your arguments: You always say that this
> > is possible and that is possible, totally ignoring the question how
> > realistic things actually are. But as I already pointed out at the
> > beginning of the discussion, this is the only really interesting
> > question: because in theory, you pretty much can do anything you
> > desire on pretty much any system, if you invest enough effort.
> >
> > What really distinguishes designs is only *how hard* certain things
> > are with one design or the other. A good design is one that makes
> > the things we are interested in straightforward; the properties we
> > want to see natural.
> 
> I do not know if an offline debugger will be part of the Coyotos.
> 
> Only when the on-disk image format is set we can talk about how it
> does or does not make such debugger hard to write. However, it will
> probably not make it difficult because when the system is powered on
> it has to be reloaded from the on-disk image and later the on-disk
> image has to be updated with current snapshots.

You mean it is not difficult to examine the state in an image, because
EROS/Coyotos has to restore the state when booting?

Well, AIUI Coyotos doesn't really restore anything except the core
services when reloading an image. The state lives permanently in the
on-disk snapshots; during reboot, the necessary pages are simply faulted
in on demand, just like during normal operation.

I don't think there is any single component in Coyotos that has a full
understanding of the memory image (including data storage, capabilities
etc.) of individual processes. Rather, a process works by a combination
of several mechanisms.

The offline debugger has to implement all these mechanisms, to be able
to extract the state of individual processes. But this is not the hard
part. The hard part is extracting useful information from individual
processes' images.

The problem is that Coyotos doesn't know anything about how processes
represent their data. It just stores the image of a process; each
process represents it's data as it likes. This is simple and elegant,
but makes it really hard to extract any specific piece of information.
You have to understand the memory structure of each involved process
individually.

Doing this is hard enough with an online debugger, where you can study
the behaviour of the process -- especially if no source is available. It
is much harder with only an offline snapshot.

If a process uses protective measures, like self-modifying code, and
encrypting/decrypting pieces of code and data on the fly, this is very
tricky with an online-debugger; offline it's just nasty.

I'm not saying it is impossible to do for a really dedicated person. But
surely you don't want to claim that this is equivalent in practice to a
system where the user running an application has full control over it in
the first place?

To stress the point, most designs are equivalent in theory. In theory,
capability designs are equivalent to access control lists for example.
Yet you would certainly not argue that there is no relevant difference
in practice?...

> Still you are ignoring feasibility yourself. You say that since the
> Hurd has Scheme bindings you can write cross-platform customizations
> and fend off my reqeust that Hurd be completely rewritten in scheme
> for such customizations to become feasible with something like "the
> parts that people will like to customize will be eventually
> rewritten".

No, it wasn't me who said it.

It's not the first time you are misattributing statements like this.
Please pay more attention to who says what...

I for my part think that it is perfectly *feasible* to create
alternative implementations of most system services, in other languages.
I just have some doubts whether this really desirable in most cases,
forseeing some possible problems...

Anyways, this was on a side branch of the discussion, not related to any
of the fundamental points we are disputing here. I don't even remember
how it came up.

The fundamental points, you may have noticed, all revolve around the
fact that we have good reasons for doing certain things differently than
Coyotos. 

Shapiro has an impressive ability of dismissing other approaches, making
it appear like his design is the only sound one, and everyone else is
doing something wrong. I think that many people on the l4-hurd list fell
for that, and while Neal and Marcus seem to have "recovered" from it,
some others probably haven't...

Shapiro can't be always right. It's certainly not true that thousands of
people working on other systems are all stupid or ignorant. The truth is
that Coyotos is *not* the perfect design for each possible situation.
There are many many situations where different systems are more
appropriate, for all kinds of reasons.

We believe there are situations where ours is more appropriate.

> >> I do not know why dbus was created and what problems it is trying
> >> to solve. And I have no idea why a word processor would need to
> >> communicate with any other application for example. There are
> >> clipboards but these are not in dbus so I really don't know any use
> >> case for typical application communicating through dbus with
> >> another one.
> >
> > So you don't see the reasons. Great. "I don't see it, so it's not
> > there!"...
> 
> For me there is not. If you use your text processor in some different
> way that would require dbus integration then you can perhaps enlighten
> me.

I'm hardly ever using word processors, and have no idea whether any
actually use dbus as of now.

The word processor is just an arbitrary example you picked. Maybe it's
relevant, maybe not. But it's a fact that there are various applications
using dbus nowadays, and they certainly do not do it for the fun of it,
but to offer additional functionality.

Loosing functionality in "legacy" applications is not acceptable for us. 

(Some people might choose to forsake certain functionality for security
or other concerns -- but that's an individual decision. The system we
want to have shouldn't force it.)

> If you went on the "i do not need this but I imagine that somebody,
> somewhere might at some time ..." then you would include every
> function possible in every piece of software, and every piece of
> software would be an operating system on its own right with everything
> including the kitchen sink already packed in.

The point is precisely *not* to implement all possible system
functionality in each single application, but rather to integrate
applications with each other, so existing functionality can be reused in
all kinds of situations.

> That's why I say that before porting dbus I would consider what dbus
> buys me and if there is another way how I could get the same
> functionality.

Again, besides the point. The point is that existing applications use
dbus and other "legacy" interfaces for integration. Either you use these
interfaces, or you get no integration with existing applications. It's
as simple as that.

> However, even running a horrible UNIX application you still get
> improved security. The communication is really restricted to the
> single pipe, applications cannot write each others memory at random,
> and they should not get access to random files which you are not using
> either.

So you agree that it's possible to improve things, without forsaking
existing interfaces :-)

-antrik-