Userland components in Ring 1/2 (where kernel is in ring 0) to provide protection from less trusted components
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.
Hello
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
No, it does not. You may want to run software at the lowest privilege it can run and microkernel environments can effectively work at the lowest privilege ring.
What problem do you want to solve?
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.
On Fri, 18 Sep 2020 at 02:47, Isaac Beckett isaactbeckett@gmail.com 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.
Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
On 18 Sep 2020, at 10:35, William ML Leslie <william.leslie.ttg@gmail.commailto:william.leslie.ttg@gmail.com> wrote:
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.
Correct, for the basic reason that there is no benefit from running things in rings 1 or 2, you can just run them at ring 0. Also, you can safely expect poor performance (eg systenter/sysexit aren’t supported).
Gernot
On 9/17/20, William ML Leslie william.leslie.ttg@gmail.com wrote:
On Fri, 18 Sep 2020 at 02:47, Isaac Beckett isaactbeckett@gmail.com 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.
On Thu, Sep 17, 2020 at 8:35 PM William ML Leslie < william.leslie.ttg@gmail.com> wrote:
On Fri, 18 Sep 2020 at 02:47, Isaac Beckett isaactbeckett@gmail.com 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.
Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
-- William Leslie
Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
Thanks, that makes sense. Is there any risk to the system if a piece of userland code takes advantage of some hardware bug or other side channel to cause it to run in those higher privileged rings? Or any mitigation that should be applied on an x86 system to prevent such things?
On Thu, Sep 17, 2020, at 12:44 PM, 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.
Other people have commented on the least authority implications but I need to point out that rings 1 and 2 _don't actually do anything_ on modern x86 systems, and by modern I mean since the 386 - they are only used for segment-based protection, page table translation treats 1/2 as equivalent to 0. Since ring 1/2 code can freely overwrite ring 0 code, the IOPL is not relevant either.
-s
-
Andrew Warkentin -
Heiser, Gernot (Data61, Kensington NSW) -
Isaac Beckett -
Stefan O'Rear -
Vasily A. Sartakov -
William ML Leslie