1 stable 2 super stable

[Calin Negru]

Yeah, a tiny bit left or right from the prescription and doom looming.

[Nelek]

trønderen wrote:

There are lots of very good protection mechanisms available in the hardware (and in the software). The problem is to make developers use the available mechanisms (and to use them the correct way).

That's... that's the right question[^]

M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

[Calin Negru]

Ok, I think I understand

[Jacquers]

And yet we still sometimes get the BSOD due to driver / other issues.

[honey the codewitch]

That all falls apart on embedded when you're dealing with primitive memory protection schemes and an RTOS at best. :( I was just dealing with a buffer overrun this morning.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[honey the codewitch]

Hard to protect the OS against ill behaved drivers without introducing a nasty performance hit. Drivers basically need to operate in kernel space. Windows does have "user mode" drivers now, but not everything can be run that way. It would destroy your GPU performance, for example.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[trønderen]

Don't forget the ring protection. Drivers are not supposed to run in ring 0.

[trønderen]

Remember the ring protection. Drivers are not supposed to run in ring 0. The (hardware) ring protection is effective at all times; it is not turned on or activated. Making use of it does not affect performance. Then comes the questions of placing the various OS data structures in the appropriate ring. I wouldn't be surprised if there are essential data structures in ring 1 (/2) that really should be located in ring 0. But then the OS code referencing it must be located in ring 0 as well. If the OS wasn't originally architected with a ring protection in mind, cleaning it up later may be a rather nasty job. I've never been inside Windows source code, but my experiences, not the least with (but certainly not limited to) Windows Docker, seems to indicate that it "Everything is deeply intertwingled" (to quote Ted Nelson). Picking apart a crow's nest to put some of the stick in the "ring 0" pile, without breaking any of the other sticks, requires extreme care. Then learning Zephyr, seeing how it is possible to divide OS functionality into clear cut, small pieces so that you load exactly what you need and nothing more, was a revelation to me. It is the diametrical opposite to Windows. Of course: Zephyr and Windows targets (almost) completely different problem domains. Yet I am quite sure that a general OS like Windows could be built with much more of the Zephyr modular philosophy.

[honey the codewitch]

Maybe I misunderstand how things are laid out but I do know a driver can do a kernel wait without switching between "user mode" and "kernel mode" under windows. I assumed kernel mode was equiv to ring 0 but it sounds like the truth is more complicated.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[Calin Negru]

k5054, dandy72, tronderen that’s an interesting read guys

[Daniel Pfeffer]

Well, in OS/2 you had the following levels: Level 0: Kernel and (some) drivers Level 1: Most drivers Level 2: IOPL (In, Out instructions) for use programs Level 3: User programs I don't know much about the Windows kernel, but I assumed that it had a similar structure.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.

[trønderen]

You've got several different protection mechanisms: First, that of addressability. A process presents a logical address the memory management system, which will translate it to a physical address. The contents of the MMS tables switches when the CPU switches to another process, so each process will see a different selection of physical pages, even if the logical address is the same. No user process has page table entries pointing to OS data structures, so it cannot reference / modify them. The translation from logical to physical pages goes through another translation before getting to the page tables: The logical address space is split into segments. Each segment has a minimum privilege level (i.e. ring). On Intel CPUs, 0 is the highest privilege, 3 is minimum. Even if a driver runs in the same logical address space as OS code, some segments of that space could be marked as requiring level 0 (or 1 or 2) for access. Drivers usually run in ring 1 or 2, and if the OS data lies in a ring 0 segment, the driver cannot access it. A process in a given ring have access to all segments of lower (higher numbered) rings, so a ring 0 kernel process can access whatever it wants, as long as it has a page table entry to it. The segment descriptor tells the length of the segment: An attempt to go to a less restricted segment and address out of bounds, into another segment, will fail. The segment descriptor also indicates the type of segment, one of 16 values (4 bits): A "Read-Only" segment may not be modified, even it it can be read. Typically, the OS will make configuration and state information available to drivers this way, but the drivers cannot modify/corrupt this information. Also, the contents of the segment can not be executed as instructions. An "Execute-Only" segment cannot be read or written, but may be executed. Code segments may allow reading. (The OS may need write access to the data structures, so it constructs a different segment descriptor for its own use.) On the x86/x64 you can also restrict write access on the page level. Even if the segment generally is accessible, sensitive OS structures may be stored in pages that denies writing. (Both the segment and the page must allow writing.) There is another bit restricting code execution, if this bit is set in the page descriptor. The ring (also called Privilege Level) of the current process also can restrict access to I/O devices. E.g. the OS may allow users to write drivers to run in ring 2, to gain access to (at least some) OS structures, but do I/O

[honey the codewitch]

trønderen wrote:

hey may still have access to a lot of the OS data structures, a lot of it read only, that ordinary user processes can't access.

This must be why they can do things like enter a wait state without doing a switch.

trønderen wrote:

Simpler machines often have just two privilege levels, comparable to ring 0 and ring 3 on the x86/x64. Then, drivers usually have all the privileges of the OS, running in "kernel mode".

When I learned things, this is how it was done. I knew things had changed, but nevertheless that probably contributed to my misunderstanding.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[honey the codewitch]

tronden did a pretty good rundown in a reply to me. My information was woefully out of date.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[dandy72]

That *is* kernel mode (ring 0) vs usermode (ring 3), no?

[dandy72]

Granted, but this thread was started discussing Windows only, which tries a lot harder protecting itself than embedded systems.

[trønderen]

(Most) drivers are supposed to run in ring 1 or 2 - call that "driver mode" if you like. I guess that the OS kernel has some central drivers of its own running in ring 0. The borderline is fuzzy between drivers and code for manipulating CPU resources (such as the interrupt system or MMS). The OS may trust itself. It should not trust "foreign" drivers, e.g. those developed by manufacturers/vendors of "foreign" peripherals, to run in ring 0.

[pmauriks]

3 Super duper stable. :) Obligatory mention of Tannenbaum and Minix 3 ([Minix 3 - Wikipedia](https://en.wikipedia.org/wiki/Minix\_3))

[dandy72]

What (admittedly little) exposure I've had to this had led me to conclude that, for all practical purposes, there was no such thing as Ring 1 and Ring 2, at least when it comes to Windows. I think Mark Russinovich even said so himself, but don't quote me on that. Although it does make sense that this is where drivers ought to live.

[dandy72]

trønderen wrote:

The OS may trust itself.

That's a mistake if that's the case. I thought Windows these days only established trust by signing *every* file in the Windows folder (where practical).