1 stable 2 super stable

[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]

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

[dandy72]

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

[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).

[trønderen]

"Trust" in the sense "May allow its own components write access to data structures that noone else trusted to modify". If it didn't trust itself to set up segment/paging tables, interrupt handlers etc., nothing could ever work. Signing is a different sort of trust.

[Calin Negru]

> super duper stable I don’t think that is out yet. Who knows, maybe Windows 12 will fit the requirements. Although some might say there’s not much space for improvement left.

[trønderen]

The hardware offering certainly is there. A specific OS is not obliged to make use of it. The 386 segment system looks like it was hand crafted to Windows of the day. But MS made attempts to make Window the universal OS for all sorts of processors (such as MIPS, Alpha, PowerPC, Itanium, ...). Since they do not all provide the same hardware support, MS chose to limit themselves to the bare minimum available on all processors and do their own software simulation, identical for all of it. The same goes for the protection system: They ignored all advanced mechanisms. All users shall have the same offering; we cannot give x86/x64 users a protection mechanism unavailable to users on other platforms. Of course they could have designed a hardware abstraction layer that modelled both segment and ring mechanisms that could very easily be mapped to Intel hardware, but required far more software emulation on other processors (giving them a competitive disadvantage). Maybe they would have done that, if they had known at that time how other processors would dwindle away anyway. They didn't. A major factor may be that they picked up OS experts from other architectures that didn't provide such things, major design architects simply unfamiliar with how such mechanisms are used, so they ignored them. I am quite sure that at least you were right, that Windows ignored the intermediate privilege levels (along with the segment mechanisms). I thought that in order to make a more robust kernel, they started pushing external drivers down to ring 1 a while ago. I may very well be wrong. Maybe what I have read is unfounded speculations, and I found it such a natural thing to do that I took for granted that the change was carried through. If the OS code is structured like a crow's nest it might be very difficult to realize, though. I have strong suspicions that the current state of the Windows implementation is not quite what you would use as a model system if you were teaching a university level course in well-designed OS implementation.

[Matt Bond]

"Intend your puns, weaklings" - Old Fire Emblem game.

Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere

[dandy72]

trønderen wrote:

Signing is a different sort of trust.

Fair enough.

[dandy72]

trønderen wrote:

I thought that in order to make a more robust kernel, they started pushing external drivers down to ring 1 a while ago.

That could very well be the case, my knowledge on this topic is years old. And Microsoft has since been spending resources on trying to re-architect at least some parts of Windows in the name of security (to what degree of success, is a matter for another discussion) :-)

trønderen wrote:

I have strong suspicions that the current state of the Windows implementation is not quite what you would use as a model system if you were teaching a university level course in well-designed OS implementation.

How very true. Software that old, with so many layers that have been added over the years decades, cannot be optimally clean.

[sasadler]

It's not frequent but I've had my Win 10 system crash. No BSOD, just acts like I'd pushed the reset button. I'm pretty sure it's only been when I was gaming (which I do frequently now that I'm retired!). I do use the latest and greatest drivers for my GPU so possibly a driver issue.

[jschell]

Calin Negru wrote:

and did not dispose things properly (leaving a mess behind in your app on exit) the OS would have been unforgiving

I don't remember anything like that. For example pipes did not exist. So certainly no way to leave one of those around. Files were closed when the app exited. Memory was returned when the app exited. Pretty sure sockets were closed when the app exited. Not sure about UI 'handles' but I think they were returned too, probably because they were actually virtual and handled in memory (see above.) Now all of that is true. Except it is possible to leave a named pipe hanging around but that is pretty much exactly the point (the programmer, not the OS, is responsible for the lifetime.) Keep in mind of course that right now, because of the way sockets are defined, when the app exits the sockets are not immediately closed. The protocol must be respected. But now and then if you have an open client socket and either unplug (hardware) from the network, crash the computer or power off the computer then the socket is, by definition, still open.

Calin Negru wrote:

On Windows 10 if you leave a mess on exit the OS won’t say a thing no dialog boxes or messages telling you about corrupted memory, or that the app has exited with errors.

As stated that is not possible. Regardless of how the application exits the memory is returned to the OS. Even if you overwrite the application stack and/or code space the memory will still be returned. With older OSes it was easier to write into spaces where one shouldn't. Which is not the same as saying it was easy. Nor is one absolutely precluded from doing it now.