Hi, On Fri, Jan 09, 2009 at 06:22:27PM +0100, Michal Suchanek wrote: > 2009/1/3 <olafbuddenha...@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-
