OSDev.org

I am soon going to move from my monolithic kernel to a microkernel. Thus, I have to implement device drivers, as far as I understand, in either rings 1 or 2 so I can give them I/O permissions through IOPL.

What's the actual difference between rings 1 and 2 in terms of permissions? Which instructions can ring 1 execute that ring 2 cannot? I've searched the internet and found no result, I have even skimmed through the Intel developer's manual and found nothing. It does say the following:

In a typical protection ring model, access to the I/O address space is restricted to privilege levels 0 and 1. Here, the kernel and the device drivers are allowed to perform I/O, while less privileged device drivers and application programs are denied access to the I/O address space. Application programs must then make calls to the operating system to perform I/O.

But this doesn't answer entirely my theoretical question.

Does anybody here know the answer? Thanks a lot!

The difference is whatever you choose it to be.

iansjack wrote:The difference is whatever you choose it to be.

Really? Cool. I think both ring 1 and ring 2 can access privileged pages, right? But I assume they cannot run common ring 0 instructions (lidt, mov to cr* registers...), am I wrong?

jlxip wrote:I am soon going to move from my monolithic kernel to a microkernel. Thus, I have to implement device drivers, as far as I understand, in either rings 1 or 2 so I can give them I/O permissions through IOPL.

Or you can implement them in ring 3 and give them I/O permissions through IOPB in the TSS.

Octocontrabass wrote:

jlxip wrote:I am soon going to move from my monolithic kernel to a microkernel. Thus, I have to implement device drivers, as far as I understand, in either rings 1 or 2 so I can give them I/O permissions through IOPL.

Or you can implement them in ring 3 and give them I/O permissions through IOPB in the TSS.

Big brain time. I will do that, thank you!!!

Keep in mind that most x86 OSes don't use rings 1 and 2 at all (I'm not sure if they are even accessible in Long Mode, or if they were some of the legacy cruft which AMD decided to omit), and most modern CPU architectures only have user and supervisor (and maybe hypervisor) modes. This is largely due to the influence of Unix, since that has a binary user/root division; most later OSes agreed that multiple security levels weren't necessary, so both OS devs and hardware manufacturers started to ditch them by the early 1980s.

Multiple security modes were mainly a thing on older mainframes and minis, and even there it began fading by the time the 80286 came out. Most of the significant microprocessors have either had two-level security, or none at all.

The 80286 only introduced the current 4-level system used on the x86 because Intel were using it as a testbed for features meant for use in the still-unfinished iAPX 432 (a completely unrelated microprocessor design which was proving too ambitious to be practical with the IC processes of the time), and even by then two-level hardware system instruction protection was the norm (for systems which had any; most microprocessors still didn't in 1982).

Whether this is a good thing or a bad one is left as an exercise for the reader.

However, it does mean that any OS which is meant to be ported to other architectures should avoid using rings 1 and 2, or at least not depend on them.

jlxip wrote:

Octocontrabass wrote:

jlxip wrote:I am soon going to move from my monolithic kernel to a microkernel. Thus, I have to implement device drivers, as far as I understand, in either rings 1 or 2 so I can give them I/O permissions through IOPL.

Or you can implement them in ring 3 and give them I/O permissions through IOPB in the TSS.

Big brain time. I will do that, thank you!!!

Or perhaps provide a system call to do port I/O? Expensive for single I/O operations, but you could batch them, perhaps even provide some conditional sequencing.

Or provide a device file, and read/write to the offsets of the port you want to access.

The rationale being that a lot of devices these days just use MMIO, which can be done easily from user mode with a kernel controlled mapping, so for many devices you simply won't need port based access. And MMIO is portable between CPU architectures, so you can have architecture independent drivers in usermode without worrying about the processor.

And some machines that use legacy AT devices, map those AT device ports to MMIO. Think something like PowerPC PReP platforms.

Having said what I had earlier, if you do mean to use those rings, and want something you can back out of relatively easily when porting a system, a few possible uses of rings 1 and 2 are

• isolating the interrupt handlers from the kernel, so that the kernel doesn't necessarily have to handle interrupts directly, and conversely, so that interrupts for user processes don't have to have full supervisor privileges;
• a sandbox for modular drivers (which was always one of the main ideas behind the extra levels, since it lets the drivers to run with a specific subset of the system instructions without as much risk as you have running them in ring 0);
• a sandbox for untrusted code (basically the opposite of using it for drivers, though these days you would be more likely to use a virtual machine for that instead); or
• as a way of isolating soft-real-time processes from those using features which don't work as real-time such as virtual memory. While this isn't really needed for this sort of RT sandboxing, it might be something you could use as an organizing principle - if something is running in ring x, you know it has to be a RT process and so you can't swap it out or perform certain other actions on it. (I specify 'soft' real-time because any 'hard' real-time requirements are generally incompatible with a general-purpose OS, but instead would need dedicated Real-Time Systems to ensure consistency.)

Note that for each of these, better (or at least simpler) solutions exist which don't lock you into a multi-level security scheme. Of them, the driver isolation one is the most typical use, and probably the one which makes the most sense, especially when the OS is a Microkernel design (as the drivers are themselves separate processes), irnoically enough (since the whole point of a microkernel originally was that it could make it easier to secure a system on hardware without any hardware security and protection).

Rings 1 and 2 work fine, and I have thought about using them. There is one problem: portability. They are very unportable. For example, take OS/2. OS/2 used rings 1 and 2. Not only was not it not portable with MIPS, ARM, and other RISC processors that have only two protection rings, a lot emulators (namely, Virtualbox) have issues using OS/2 without VT-x or AMD-V, a lot of the reason being these rings. It is portable with 64 bit, from what I gather, but there are a lot of portability issues with these rings. Hopefully all this makes since, but bottom line: this is your OS, make it how you wish. But keep the portability problems in mind.