OSDev.org

Can someone explain this to me in slightly greater detail:

(From http://wiki.osdev.org/GDT)

If 1 code in this segment can be executed from an equal or lower privilege level. For example, code in ring 3 can far-jump to conforming code in a ring 2 segment. The privl-bits represent the highest privilege level that is allowed to execute the segment. For example, code in ring 0 cannot far-jump to a conforming code segment with privl==0x2, while code in ring 2 and 3 can. Note that the privilege level remains the same, ie. a far-jump form ring 3 to a privl==2-segment remains in ring 3 after the jump.

This seems to be at odds with my understanding of x86 privilege levels, 0 being the highest privileged, 3 lowest. I assumed that code from ring 0 could jump wherever the heck it liked, while ring 3 could only jump to another ring 3 conforming segment, rings 1 and 2 to various levels in between.

Were the opposite true as the above suggests, would this not mean that userland processes could access kernel mode code, but not the other way around?

duran wrote:Were the opposite true as the above suggests, would this not mean that userland processes could access kernel mode code, but not the other way around?

You couldn't implement a kernel in a conforming code-segment. Things like interrupt-handlers, API-entry-points and similar has to reside in ring 0 (non-conforming code segment). Originally, conforming code-segments where designed to share library code. The idea was that kernel and userland could share library code. I've not found this a useful feature though, and I'm not aware of any other OS-project that has either.

Conforming code segments do not violate the ring protection schemes. They have no inherit ring assigned to them, and thus CS RPL-fields (which is the current ring) does not change as control is passed to a conforming code segment.