Hello lists[0], I have written some things about Iris before, but didn't really introduce it yet. I'm doing that now. I'll first shortly summarize what Iris is and what it is not. Then I'll go into some detail about the design goals and what they mean for users of the system. Finally, I'll give a link to the source code, which includes building and testing instructions (including setting up a cross compiler).
----------------------
What is Iris?
----------------------
Iris is a new microkernel (licensed under GPL 3+) which I am writing for
the Trendtac minipc (AKA Skytone alpha 400 and many other names). Most
likely I will soon port it to also work on the Ben NanoNote, the smaller
(more PDA-size) device with very similar hardware[1].
Iris is a capability-based microkernel. As a kernel, its most important
function is to deliver messages between threads (IPC)[2]. Furthermore,
it manages physical memory for threads, and it does scheduling.
Finally, it receives interrupts, but it doesn't handle them. Instead,
it sends a message to a thread which must handle it. The rest of the
system, including all device drivers, is done by user space threads.
Being capability-based has many implications, some of which I write
about below, under design goals.
What I call "Iris" is really more than just the microkernel; it includes
the programs which are needed to make it a usable system, in particular
the device drivers. All these are together in one repository. It is
roughly the software which has an equivalent piece of code in the Linux
kernel.
-------------------------------
What is Iris not (yet)?
-------------------------------
Currently, Iris is not a usable system. It can boot and demonstrate
some device drivers, but it doesn't even have a shell, and can't "run"
anything.
It doesn't run on other systems than the ones mentioned before. That
should however be fairly easy to remedy; the code is written to allow
porting, but I don't think I'll be doing it soon.
Iris doesn't have the plethora of device drivers that Linux has. For
most devices, that is not a problem: they can't be connected to the
target machines anyway. But if you have a usb device that I don't have,
and which doesn't have a class driver, you will probably need to write
your own driver to make it work.
Iris is not POSIX compatible, and I'm not sure if it ever will be.
There will likely be a compatibility library at some point, but any
important piece of software should not use it. See below under the
design goals for the reasoning behind that.
-------------------------------------------------
Design goals and what they mean for users
-------------------------------------------------
I'm making this list up right now; I didn't have it written out before.
So it is possibly incomplete.
First and foremost, my main design goal is to make the computer do what
the user wants. That sounds simpler than it is. I currently do not
know of any operating system which follows this goal. In particular,
Linux certainly doesn't. To explain what I mean, I'll give an example:
If some programmer thinks it's a good idea that his window is always on
top, he can instruct the window manager to arrange this. Most window
managers will honour this request, because most programs only request it
if the user really wants it (or at least, that's the idea). However,
this is often not the case. And even if the window manager ignores the
request, the X11 protocol allows the program to raise its own window.
This is an example of allowing the programmer to think for the user.
The problem here is that the program is supposed to know what the user
wants, and that the user cannot override that. My design goal means
that the user must always be able to override everything. But at the
same time, it means that things must be right (and perhaps more
importantly, consistent) by default.
The main consequence of this goal is that there must be a standard
system for setting up the environment of a program (what it can and
can't do, what sort of window it has and how it's positioned, etc).
That system must be controlled only by the user (and not by programs,
except possibly if the user requested it; never by the programs which
are controlled), and it must be completely clear to the user when that
environment is entered.
Another goal, which is related, is that the computer must be trustable.
This means that even programs which are actively malicious (because they
were written that way, or because they have a bug and are taken over by
a cracker, for example) cannot do unreasonable damage to the computer.
"unreasonable damage" is destroying anything that the program doesn't
require write access to for its operation, or leaking anything that it
doesn't require read access to, or leaking anything at all if the
program doesn't require network access.
In Windows, people are warned not to click on untrusted files. This is
because they are so stupid to use the same operation (click on the file)
for "open with a trusted viewer" and "run as a trusted executable". But
even with GNU/Linux, where this is not (always) the case, the situation
"I have this executable from an untrusted source, and it might do
something cool" still means "do a lot of work (create a new user) or
don't try it". While it should be "Give it a try, and see what it
does". On Iris, the latter is possible. You simply don't give it
access to the network, or any of your data, and it cannot do any damage
at all. This is a direct result of using capabilities. Capabilities
are access rights for resources: each resource (such as "reading
/home/user/file.txt", but also "talk to the sound card", or "use this
network connection") has its own capability. Only threads which own
that capability can perform the operations. Mapping this scheme to
Linux, there is one capability per user, and it allows everything that
the user can do. This means that any program run by the user is trusted
with all resources that are trusted to the user. This is not a good
idea, as I hope I explained above.
Then there is another related goal, which is that the system
administrator must be needed as little as possible. For example, when I
have an ISO image file on Linux, I need the system administrator (or a
lot of extra software) to be able to mount it, and use "normal"
utilities (cp, ls, or a graphical file browser) on it. That doesn't
make sense: no extra rights are gained from doing that. I had access to
the file, I am allowed to do anything I can when it is mounted. But
still I need the system administrator, because the file system is so
deep inside the kernel, that "mounting" cannot be allowed without giving
up all security. Such situations must be avoided on Iris. This means
that everything is virtualizable. Since all communication works through
capabilities, it means that emulating or sniffing a program's
capabilities, it is possible to debug anything. For example, it is
possible to debug a device driver without access to any real hardware,
if you can emulate the device's capabilities. The driver cannot see if
it's talking to real hardware or an emulation, even if it wanted to.
For this sort of thing, you don't need a system administrator on Iris.
As I wrote above, Iris is not POSIX compatible. The main reason for
this is fork(). That call is very badly designed (for my design goals),
and I don't want it to take a central part in my system. The reason is
that I want to avoid programming errors, and one frequent source of them
is to forget to do something. I'm talking about capabilities here,
rights to do things. When creating a new thread, it is important that
it only receives the capabilities that it really needs. With fork(),
this is done by first copying all, then revoking the ones which are not
needed. If anything is forgotten, things will just work, but the
program has too many rights. This is a security bug, which will
probably be found after it has been abused. On the other hand, if the
program gets no capabilities by default, and then the ones it does need
are granted, forgetting something will mean that the program can't
function properly. That is a usability bug, which will be fixed before
the release. Never has the security bug of the fork() scenario been
waiting to happen. This is good.
I think this is enough about Iris. If you want to know more, please
check out a copy of the current repository (which is not kept up to
date; I'll post again when I have a permanent home for it) from
http://pcbcn10.phys.rug.nl/~shevek/iris/. It is a git repository with a
local checkout, so you can use a browser or git to get it. For
building, see README.build. For technical details, see
report/kernel.tex. For a story about writing it (so far), see
report/making-of.tex. For details on how to set up a cross-compiler (on
Debian), see report/cross-compiler.tex.
Any comments which are useful for others, please follow-up to the
list(s). Any other comments, please send to me personally.
Thanks,
Bas
[0] This is a cross-post because both lists may be interested. When
replying about one subject only, please remove the other list from
the receipient list.
[1] I'm cross posting to two mailing lists, one for each device. So if
you don't know the other list, it's for the device you're not
working on. ;-)
[2] This is where it gets its name from, Iris is an ancient Greek
messenger god.
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
