Introducing Iris

yajin yajinzhou at
Mon Jul 27 21:28:43 EDT 2009

Sounds interesting. :)

I do not dig into too much about Iris, but what's the main differences
between Iris and L4 family(such as pistachio and OKL4)? One of the
main disvantage is big IPC overhead? What about Iris?


On Tue, Jul 28, 2009 at 5:04 AM, Bas Wijnen<wijnen at> wrote:
> 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
>  It is a git repository with a
> local checkout, so you can use a browser or git to get it.  For
> building, see  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
> 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
> Version: GnuPG v1.4.9 (GNU/Linux)
> fy0AoPCNQuqMs9h89bBE4CptkKfxYSk5
> =il5H
> _______________________________________________
> Qi Developer Mailing List
> Mail to list (members only): developer at
> Subscribe or Unsubscribe:

More information about the discussion mailing list