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

[Michal Suchanek]

2009/1/13  <olafBuddenhagen@gmx.net>:
> 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.
>

Sounds interesting, I will try to look at that when I have some time.

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

You could still hopefully use an online debugger as well, the offline
debugger is an additional option, albeit the only option for systems
that were not installed with debugging in mind.

I am not sure how hard it would be to install a bypass mechanism for
attaching debugger to processes that try to hide themselves. Last time
I looked at Coyotos it was about as advanced as the L4 ping-pong demo,
and would not even build on my system.

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

And again the full control is most likely a matter of configuration,
not the system in question.

You might not allow any application to use memory you cannot access.
If that is practically feasible on the actual Coyotos implementation
remains to be seen when such implementation is available.

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

Yes, it was Arne who said that. I got this confused, sorry.


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

The main selling point of Coyotos was that it is only an update to an
existing design. That is, it should be usable in short time with at
least some of the desired features (and some non-essential but useful
ones). Given how slow its development continues it  seems this
advantage was exaggerated.

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

In fact hundreds of millions of people are using the QWERTY keyboard
that was designed for mechanical typewriters not getting stuck, not
for typing.

It's just the established standard, and they are not all stupid or
ignorant for doing so. However, there is demand for different keyboard
designs, and different input devices, too.

And I do not think that the Coyotos design is perfect or the only
possible. It's just far better in some respects than the current POSIX
and POSIX-like systems.

>
> 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 do not know any functionality that is actually forsaken here
either then there might be no reason to stick to dbus at all.

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

But we are talking about adding (porting versus not porting) dbus
here, not about application integration.

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

I see integration in applications behaving in a similar way so that
people do not have to learn how to use basic controls for each
application separately, using similar menu layout or keybindings, etc.

The libraries and interfaces the application uses play little role here.

>
>> 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 :-)
>

However, our position fundamentally differs in that you want a system
built around legacy interfaces but I want a system with simple and
clean interface that is powerful enough to express the deprecated
legacy interfaces as compatibility layers when applications need them
or abandoning them if they are no longer necessary.

Thanks

Michal