On Fri, Sep 18, 2009 at 12:01:36PM -0400, Alan Grimes wrote: > William Leslie wrote: > > I like L4, I really do, and I think it would be a good base for a rather > > fault tolerant > > and performant operating system. But it's not something I would work > > on myself, because I would *like* to be able to confine applications. > > To me confinement has two aspects. > > A. Is the process confined to its address space? (Yes for L4). > B. Are there any "back door"/unintentional IPC mechanisms? (On L4, no), > > Therefore, applications are confined on L4.
Not sure if it's what Willian was asking for, but there are groups within which "confinement" is a technical term with a precise meaning. The following provides a brief explanation: http://www.erights.org/elib/capability/confinement.html L4 does *not* provide confinement under this definition. I believe that seL4 does, and most of its safety proofs are predicated on it. In layman terms, it's similar to getting memory-safety in a programming language where the benefit is that you can start to reason about the side-effects of executing a piece of code. It's such a nice property that Google went to reasonable effort to get it inside Windows and Linux for Chrome. It's only partial and slower than it needs to be, but quicker than emulating a whole computer. It's why "Critical" bugs[1] are going to be pretty rare, while other browsers that don't use its "sandboxing" (i.e. confinement) high and critical are pretty much the same. Confinement allows you to write large complicated chunks of code (i.e. the renderer and JavaScript interpreter in a web browser) and not have to worry that when it breaks it's going to result in the compromise of your whole account. Individual tabs can crash in Chrome, but the rest stay alive and well. If confinement was generally supported and encouraged by the OS I'd expect to see considerably more reliable software being written. -- Sam http://samason.me.uk/ [1] http://dev.chromium.org/developers/severity-guidelines
