Re: Broken dream of mine :(

[Bas Wijnen]

On Thu, Sep 17, 2009 at 04:20:16PM +0200, Michal Suchanek wrote:
> > Also, even if it's a suitable kernel for a desktop, that doesn't
> > magically create an entire desktop system on top of it. ;-)  With my
> > demands, the GNU system would need a lot of work before it would be
> > acceptable as well, so simply "supporting POSIX" doesn't really do what
> > I want either.
> 
> That's true but for my desktop I need Firefox (or equivalent), half
> dozen viewers, and unicode xterm.
> 
> That should not be too hard to port.

You may be right.  For Iris, once it is running decently, I shall likely
port it to x86 anyway, and it will have a POSIX library, so things which
don't need special drivers should just work (after compiling).  For
development I am more interested in exotic hardware, also because people
who use it are more likely to try such an exotic kernel. :-)

> > No, the current targets are two very specific devices, the mini-pc that
> > is called Trendtac here (and has many other names, such as Skytone alpha
> 
> I could not find much details about this device, not even a shop that
> sells them.

http://www.trendtac.nl is the importer's "support" site for it in the
Netherlands.  They can be bought here at Mediamarkt and Intertoys, but I
heard that they are hard to get by in other countries.  If you don't
intend to hack on them yourself, I wouldn't advise you to buy one
anyway.

> > 400, in other places), and the soon to be released open-hardware
> > micro-pc (currently more of a PDA, actually) called Ben NanoNote.  Both
> > use a mips processor.  Porting to other devices with the same "system on
> > chip" should be very easy, to other mips devices should be easy, to
> > other architectures should not be very hard.  However, I'll probably
> > keep my focus on the NanoNote at the moment, because I really like the
> > open hardware ideas behind it and want them to succeed. :-)
> 
> I am not impressed with the NanoNote hardware

The current version, which will release in or before november, has very
limited hardware indeed.  It is presented as a starting point, which
will be expanded on.  For the next version, there will at least be USB
host support.  That would already make it much more useful IMO.  There
are many more ideas; not all of them can be implemented, so they'll make
some choices.

For this version of the device the same thing is true: it is only usable
for people who want to hack on it; it's not something a shop with
finished devices would sell.

> and they do not even say how much the device will cost.

I think they don't know yet. ;-)

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

> I'm not particularly concerned about architecture. I have been running
> amd64 for some time which gives some feeling of a non-standard arch -
> binaries usually need emulation to run.

For the user, having a non-standard architecture doesn't mean much,
especially if you use free software everywhere, so you never need to run
non-native binaries.  For writing device drivers (and kernels), things
are of course different.  There too, it doesn't make too much
difference, but when it does (the assembly parts), I still see that x86
is a lousy architecture.

> This is the basic situation which allows giving certain amount of
> memory to each process and ensure it does not take more.

Yes.  Most systems have something like this, or at least try.

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

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

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.

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.

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?

Thanks,
Bas

signature.asc
Description: Digital signature