Re: Broken dream of mine :(

[Michal Suchanek]

2009/9/17 Bas Wijnen <address@hidden>:

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