2009/9/17 Bas Wijnen <[email protected]>: >> They offer the designs for download (haven't tried looking at them) >> but getting a single device manufactured is very impractical, >> especially when it includes custom plastic parts and mechanics (ie >> keyboard, case). > > Of course. This is just one point where they show how open they are, > and that is not of much value to everyone. But I know it would be very > nice to have schematics and chip numbers for some devices: it would save > a lot of work figuring out how to drive them.
Yes, having more hardware documented would be nice. Not necessarily to the point of PCB design and plastic mold design but developer documentation (hardware and software) for the components used is missing for most PC hardware, unfortunately. >> However, if the process has access to a system service or a driver it >> might use system resources through this service. > > Exactly. That is something which is not solved by Linux, for example. > >> To prevent this the system services should act as an extension to the >> kernel and require any process to pay for any services they provide. > > Right. > >> So the process should be able to enter a contract with the (system) >> service in which it lends part of its resources to the service but >> retains the right to relinquish them when the service is performed or >> it is no longer interested in the service. > ... >> Even in this model writing services such that the user memory can be >> revoked without impact on the service is somewhat problematic. Other >> systems do not guarantee revocation and require administrator >> intervention in case a service keeps resources in possession >> indefinitely. >> >> Is this somehow solved in your system? > > Yes, IMO it is, but judge for yourself. The problem on Coyotos in fact > comes from constructors, which don't exist on my system. Here's why > this creates the problem: Your system is basically equivalent for the purposes of being "drm capable" but loses some functionality. > > Without constructors, every process has a parent. That parent provides > it with everything it needs to start: memory, its initial code, and its > capabilities. This means that a child can never do anything that the > parent could not have done itself. It also means that a child must > always trust its parent. It is not trivial that this is a good thing, > but I think it is (you have probably seen the discussion on this list > about it). > > The Basic process layout is as follows: > > root of memories > + driver 1 > + driver 2 > + other system service > + user 1 session manager > -- application from user 1 > -- other application from user 1 > --- plugin for application > + user 2 session manager > -- application from user 2 > etc. > > Here + means it's a system-trusted process, which the users cannot > debug. - means a process untrusted by the system (but they may be > trusted by others, for example the plugin trusts its parent > application). I would expect that the user on Coyotos is free to run any session manager because it needs not be trusted by the system. On the other hand, an administrator would typically instantiate the session so it would run a standard process anyway, and you can make the top level session manager minimal with possibility of running different user shells, just like Windows'. > > First, let's see about rogue drivers (which don't return resources, for > example). If its about a system driver, you are in big trouble. Not > returning resources is not a problem now: a critical part of the system > is misbehaving, meaning the entire system is no longer stable. This is > something that should not happen, and there is no point to try to defend > against it. > > The other option is a driver which is run by the user. For example, I > can run my own filesystem and let a process use that. Would it be > acceptable if the process must trust the driver that it will not "steal" > its memory? I think it is. The process isn't the one with the problem > in that case; the user is. And the user is still capable of killing the > driver, because it's just another process under the user's control. There are drivers that are neither critical system services nor user drivers. For example, a driver for an USB camera is not critical for proper system operation yet it should be usable by any user of the system. So the driver cannot run in each user's session, there is one camera and multiple users. Should the driver fail the users should be able to recover from this failure although administrator (= user with capabilities that allow privileged access to that particular part of the system) intervention may be required to restart the driver. It might be theoretically possible to terminate the driver every time a different user wants to use the camera and this option is reasonable for a single purpose device like a webcam but it might require administrator intervention when one user does not terminate the driver but other user wants to use the device. And this is not possible for all drivers. Similar situation arises in a TCP stack but this component has to be used by all users in parallel to be reasonably effective (eg ports are allocated from a shared space). If you have local access to a computer then a TCP stack is a non-vital disposable component. It is more important for a networked system but it still can be restarted occasionally if it fails to perform reasonably well without serious disruption of the whole system. You can use SSL which cannot be broken by the TCP stack any more than by any other man-in-the-middle if done properly. > > Further, the user's session is a trusted program, which will behave > properly. So if a program wants to provide "opaque" memory to a system > driver, it will do this by telling its session to give that driver some > memory. The system driver trusts the session, the session trusts the > driver, and all is well. If possible I will try to avoid this scenario, > but I don't have a problem to use it when needed. > > If a program wants to provide "opaque" memory to an unstrusted driver, > it also asks its session. Its session sends memory to the driver, but > does allow its owner (that's the user, not the requesting process) to > debug it (that's different with the system driver case). This means the > user will remain in control. So all that is needed for performing drm is installing (part of) a media player as a trusted system driver. Needless to say, users that have that privilege do that daily, and users that don't demand that it be done for them. But you cannot use services that are shared between users and are not trusted, not without creating a quite direct communication path between all the processes using the service, and possibly further disrupting the service by allowing all users to modify its state. > > This also means that it is impossible for a user to give undebuggable > opaque memory to a driver which is owned by a different user. This is > intentional. It would be trivial to implement it (it will effectively > already be done for the system drivers), but I don't want that. This is > a social choice, based on a discussion on this list which I think you > followed (your question seems to be based on it). > > Note that all this is based on things which are not yet implemented, so > it may still change. > > Does this answer your question? In a way, yes. This is not a solution in my view. You only removed unwanted features without changing the technical facilities that allow implementing them yet these features removed seem vital for a working system with resource management. It may be that opaque memory is not in itself sufficient for a working system or it may not be necessary at all but only seeing a detailed system design decides this. Until then opaque memory seems to be a promising building block in such a system. It also seems to emerge naturally in systems that attempt to approach resource management better than "best effort", it's not specific to the coyotos lineage of systems. Thanks Michal
