Re: [seL4] Userland components in Ring 1/2 (where kernel is in ring 0) to provide protection from less trusted components

On 9/17/20, William ML Leslie wrote:

On Fri, 18 Sep 2020 at 02:47, Isaac Beckett wrote:

...

Hey all,

I was wondering if it makes sense for someone building a system on seL4 to run certain drivers or other critical components in a more privileged environment, but still outside the kernel. Does using a different CPU mode in this context make sense? My hunch is that the case is no, because x86 has those extra rings, but ARM only has two modes, Supervisor/System and User mode, which would make it hard to provide any mechanism for the kernel to manage privileged components, because of the differences between platforms.

To keep in mind:

One of the benefits of capabilities over rings is that not only can IO ports used by drivers be protected from applications, but now applications can also be protected from drivers, and ports are protected from other drivers. You can't really get POLA with a strict hierarchy, which is why capabilities allow you to build a graph representing how authority is really distributed to each component. Since we have a strictly more powerful way to distribute authority to drivers, there isn't anything to gain by using rings 1 and 2.

Not to mention that the multics driver rings are a fairly dark corner of the processor these days, since no operating system appears to make use of 1 and 2, so nobody is inspecting them for hardware bugs.

And If you really want an OS with more than two rings, they could just be implemented on top of kernel capabilities. The OS I'm writing will kind of do that because its root server will manage capabilities in such a way that all access to kernel APIs other than endpoints and notifications will go through it, giving an architecture with ring 0 (kernel), "ring 2.5" (root server), and "regular" ring 3 (user processes). Of course, everything but the kernel will actually be running in ring 3 from a hardware standpoint though, since seL4 only uses ring 0 and 3, and the security model that user processes see will not be based on rings at all. Also, the root server will be entirely statically linked, meaning all extensibility will be through normal user processes. And as a few other people have said, there wouldn't really be any good reason to write an OS with a security model based on multiple user-extensible rings on top of seL4 rather than implementing something more fine-grained though.