question about the rings of protection

[conlonloi]

Hello,
so I understand the user/supervisor mode of the 4 rings like the spyware from website cannot turn on your webcam without notifying you since the device is at a lower level.
so other than the user/supervisor mode distinction, what else can I use these rings within the OS?

Thank you for your time

[Solar]

I strongly recommend the Intel manuals. You need to read them anyway if you want to write an OS, and they explain the details of the protection rings quite nicely. (And you do want to write an OS, are you? Because you are aware that if you just want to ask about security holes allowing to turn on webcams, you would be in the wrong place?)

In short (and oversimplified), only ring 0 code can execute certain opcodes, like setting up / modifying descriptor tables or page tables - so "user-space" (ring 3) code cannot hack those data structures (e.g. to read / modify memory not belonging to its own process).

Certain operating systems, however, have security holes that allow such modifications regardless.

[conlonloi]

i understand what you are saying, sorry if i didnt make myself clear.
the webcam thing is just an example i used as the supervisor/user mode.
what you are saying about the ring 0 can execute a certain opcode while ring 3 can't hack into is also the supervisor/user mode thing.
so i just want to ask other than the supervisor/user mode distinction that the rings provide, how can i use the additional rings? like ring 1 and ring 2

thank you!

[AJ]

Hi,

so i just want to ask other than the supervisor/user mode distinction that the rings provide, how can i use the additional rings? like ring 1 and ring 2

Basically, don't bother. The contemporary way to implement memory protection is through paging rather than segmentation. With paging, you get a User/Supervisor mode bit for each PML4/PDPT/PD/PT entry (depending on whether you are writing for IA32 or IA64) rather than the two privilege level bits that you find in the segmentation model. Unless you have a very good reason for using segmentation, stick with rings 0 and 3 and think of them as supervisor and user modes respectively.

Cheers,
Adam

[turdus]

Basically, don't bother. The contemporary way to implement memory protection is through paging rather than segmentation

Not so hurry to state that, there are many things you cannot protect by paging, like IO space and system sensitive instructions. As for the OP's question, one solution is to use
ring 0: microkernel
ring 1: drivers
ring 3: userspace apps
With IOPL=1, you would have drivers as normal userspace applications (you can reload or stop them without crashing your microkernel), but they can still access hardware directly (via in/out and their friends). In a monolithic kernel, this is useless of course, that's why mostly only ring 0 and 3 used.

And, as a matter of fact, x86_64 still uses segment descriptors (you cannot skip segmentation), but it doesn't care about base and limit fields, only privilege related bits.

[Combuster]

Segmentation is a form of address translation. Therefore if you are only switching between user and supervisor modes, and do not otherwise change the translation of addresses, there is no segmentation involved (or all systems would have segmentation).

And you can protect I/O permissions with paging and the IOPB for finer grained protection than rings. Even IOPL can be set on a per-thread basis for increased performance (using ring 1 is slow as you can't use the syscall instructions).

[gerryg400]

as you can't use the syscall instructions

I've always assumed that SYSENTER and SYSCALL would work from rings 1, 2 and 3. It seems that SYSEXIT and SYSRET force the PL to 3 so you would need to IRET to your ring 1 task but you should be able to enter the kernel from anywhere using SYSENTER and SYSCALL because they don't check anything.

Anyone tried it ?