OSNews

Because other platforms only had two modes, so OSes intended to be used cross-platform preferred to use only two of the four rings. Also, some parts of the IA-32 architecture don't distinguish 4 rings, but only two modes: system and user, where system means rings 0, 1 and 2, and user means ring 3. Page protection is like this, for example. And finally, adding extra rings just adds extra complexity that could probably be dealt with by using more comprehensive security methodologies, which is currently the case. In much the same way that it's better to avoid using x86 segmentation or TSS's for task switching in favor of a software solution that is portable and can be fine-tuned to the needs of the OS in general, or even at a particular point in time (such as under heavy load, etc.).

Rings 1 and 2 were invented to run code that is "less trusted than the kernel, but more trusted than user processes", such as system software and device drivers. Consequently, some of the special operations from ring 0 are allowed in ring 2, and even some more in 1, but still not all.

It was an early attempt to make the OS kernel resistant against faulty drivers. However, in the end it was too inflexible to support all the different security schemes from various OSes, and so developers started to ignore them and implement everything in ring 0.

Another reason is of course that Unix was designed with only two privilege levels in mind and was not able to make use of four without significant re-design during porting.

There are more parts of x86 design like this, parts that were designed to support OS implementation but in the end turned out to bee too inflexible. The article already mentioned call gates (for hardware-supported system call entry, and possibly inter-process communication) and task gates (hardware-supported context switching and also IPC). It did not mention that the x86 actually has a hardware-implemented process table. It was an attempt to implement half the OS in hardware, and was quickly forgotten when OSes were designed that behaved differently than the hardware implementation. Nowadays it's only there because of backwards compatibility.

I believe they are not used often / ever merely because of the overhead involved in mode switching.

One dread of programmers ( well, certain ones ) is dropping into kernel mode due to some incurred overhead.

IIRC, ring 1/2 are programmable with varying degrees of privelege. I know that Intel & AMD's virtualization technologies utilize specially configured Ring 1 so that a guest OS can load normally without interfering with the host OS's kernel.

I'd imagine ring 1 is programmed to match ring 0, but is merely segmented within the processor. I'd almost beat a nickel that ring 2 c/would, thusly, be programmed to match ring 3, and that ring 1/2 would be used for the guest OS, and 0/3 for the host. Either that, or some manner of tracking is used to segment the data and instructions of the two concurrent systems.

I don't know much ( yet ) on what accesses can be controlled with varying rings, though I have high hopes of using a ring to create a 'service-mode/space' which would act as an intermediary between kernel and user spaces/modes.

In my theoretical model, this service-mode would be able to READ data directly from certain shared areas of the kernel and devices, and READ/WRITE certain user-mode memory within applications which have created a shared memory area for this usage.

My idea is based on improving BeOS's model with its known issues due to lack of certain accesses and kernel-mode fall-backs ( certainly security flaws ).

Not to mention memory duplication in BeOS on the highest order: BBitmap, which has a copy in the application's memory space AND a copy in the app_server's memory space. The app_server cannot read or write into the app's memory directly ( it can fake it though, using ports-which is slower ), so it keeps a copy of the bitmap locally, while the app keeps a copy on which it can work.

Granted, there are some major locking concerns when it comes to using shared memory ( I'll keep using bitmaps as an example ). Currently, the app_server doesn't give a rats arse if the app has made changes to the bitmap, because it has its own local copy which is synced when the app-side bitmap is unlocked and dirty.

If you were to show a bitmap live, during its changes, you would likely see a great deal of artifacts while image processing is being performed. And, if you lock the bitmap from read access, the drawing will not be able to refresh that bitmap to the screen, causing flicker / delay.

Oh well.. before I run too much off topic...

Hope the ring info answers your questions.. or inspires you to do more research :-)

--The loon

Virtualization technologies like VMWare that have to run on hardware that doesn't have VT-x or Vanderpool or whatever they are calling it these days, they have to use ring 1 to load the guest OS, while the host still runs in ring 0 as normal and all usermode code, regardless of guest or host, runs in ring 3. This is a hack solution. With VT-x and friends, there's a sort of ring -1 that the hypervisor/virtualization software can run in, and then all the guests, as well as the host, run as normal in rings 0, with usermode code in ring 3.

Ring 2 is not meant to be almost like ring 3. It's basically another ring 0. Page-level protections apply to ring 2 in the same way that they apply to ring 1 and 0. In fact, it's only ring 3 that's truly different from the other rings.

I see, thanks for the clarification!

I guess I was hoping for a more useful configuration ;-)... or reading too many tech docs and confusing the intended audience

However, if ring 1 and 2 are basically identical, it seems fairly useless for 2 to exist at all. I'd expect more usage if the permissions in ring 2 were somewhat "user" - programmable, basically to set it up as a go-between, where certain instructions could be utilized to write data into specially flagged ring-3 memory, and instructions could provide read-only access to flagged ring-0/1 memory, w/ write access a possible grant-right as well.

Ring 2 would not be able to create or modify interrupts or communicate directly with hardware, however it should be able to hook onto an active interrupt to specify an 'observer.' In this way, a ring-2 application could be used for the emplacement of lesser-privileged networking, graphics, and sound subsystems, among others.

The kernel-mode driver would merely expose read, write, and control buffers for each device based on what should be accessible from/to ring-2, while otherwise providing a basic driver interface.

The ring-2 service would register an observer on an interrupt, and the driver would be the first to handle the interrupt, after-words the ring 2 observer would be executed, which would look at what the driver did, and re-act ( i.e.: copy directly from the kernel's buffer to a user-application's data buffer - or merely providing a notification of a keyboard state switch ).

Naturally, I'm thinking nano/micro kernel here, ala BeOS. It would certainly allow Microsoft to slim Windows down for when they finally ditch forcefully integrated backwards-compatibility in favor of a virtualization service.

I especially like the idea of direct kernel to user data copies for networking and real-time multi-media. Nothing like waking up in the morning and realizing that why your networking is 60% slower in one OS over the other has nothing to do with the driver, but with useless memory copies merely to satisfy an API which must carefully protect itself in fear of being hijacked.

I mean, down deep, there are too many networking stacks which first copy from the device to the stack/heap, then copy this out to the kernel, which then copies it to a "port", which then copies it into a buffer, which then copies it into a user-mode buffer, which then finally gets a chance to do something - most often copy it to the disk!!

I mean, driver->user is the shortest route here..

Not to mention a direct-to-disk (FS API, anyway) copy :-)

Just my opinion.

Hmm.. thanks again!

--The loon

P.S. Don't worry, my fingers will be all bloody and sore from typing at some point... or one of my alter-egos will slap me back to a different reality... hrm...

Of course, ring-2 of this type would be best served to provide the memory buffers in which the driver could write, skipping its own local buffers. This would depend on the device, naturally.

okay.. I'm going now...

You can actually have interrupts deliverable to any of the protection rings. But in practice, the OS configures it such that interrupts must be serviced by routines running in ring 0.

I highly recommend reading Intel's IA-32 documentation. They pretty much explain how you could do any of the things you suggest.

OS/2 used Ring 2.

According to Wikipedia, OS/2 used ring 0 for kernel code and device drivers, ring 2 for privileged code (user programs with I/O access permissions), and ring 3 for unprivileged code (nearly all user programs).

This is verified on many other places including the EDM/2 programming web magazine, various articles on OS/2 debugging, etc., and is one of the reasons why various virtual machines have issues booting/running OS/2.

Edited 2008-08-26 16:17 UTC