Welcome to the Lounge

8-Sep-23 7:12

Windows XP and it’s predecessors did pretty good at recovering when an application went kaboom, however once every two or three application crashes the OS went down together with the app.

Multithreaded Windows is tougher, you probably can’t crash the OS even if you give it a try. Both 32 bit and 64 bit OS share the RAM with the app, the common dwelling means that the app can overwrite critical OS data, running on a separate thread shouldn’t make a difference. Does the 64 bit OS have some kind of memory backup in case things go wrong?

k50548-Sep-23 7:26

k5054

8-Sep-23 7:26

I would think that apps and OS run in their own virtual memory spaces, making it virtually (no pun intended) impossible for a non OS process to mess with OS memory space. Add to that different process execution rights, with user apps having no right to mess with OS memory, then the probability of a user application causing a crash by altering OS RAM contents approaches zero.

Keep Calm and Carry On

dandy728-Sep-23 8:10

8-Sep-23 8:10

k5054 wrote:
user apps having no right to mess with OS memory

This. User space vs kernel space. Drivers might still overwrite critical OS data, as they share memory with the kernel (that's why BSODs still occur), but a user-mode application should no longer be able to do that like they did back in the Windows 3.x/9x days.

honey the codewitch9-Sep-23 4:42

honey the codewitch

9-Sep-23 4:42

That all falls apart on embedded when you're dealing with primitive memory protection schemes and an RTOS at best. Frown | :(

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

dandy7210-Sep-23 4:10

10-Sep-23 4:10

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

jochance12-Sep-23 5:13

jochance

12-Sep-23 5:13

It's the goal that is basically unreachable for Windows as well and I think Linux has to necessarily be limited in how much better it can be in that regard.

At some point you're talking hardware and any OS is going to have the same problems/limitations.

I probably read about it from an article on here, but pretty much every modern Intel processor will give you whatever memory you want, maybe even let you write it (I can't remember), and they say you can patch this... I've no idea how you possibly patch this. Apparently, applying the patch can reduce performance by 50%.

IMO, some of these expectations of user vs kernel memory space are simply out of whack with the realities.

The whole TPM windows 11 debacle is kind of a highlighter pen at the heart of why expectations in this regard are misaligned with reality.

The hardly-oversimplification is that something, somewhere has to be the authority of what's right/ok. That authority essentially builds the walls to delineate user vs kernel memory. Right now, this is pretty much software with not so much hardware involvement aside from some limited specific things/use cases.

Maybe over the next decade we'll actually see things built at the hardware level that enable this to happen instead of just basically faking it at the software level. I think this will require something like FPGAs being able to dynamically build the interfaces between CPU and RAM for the application/software on demand (while also verifying against security permissions whether the structure should be allowed).

trønderen9-Sep-23 4:56

9-Sep-23 4:56

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

dandy7210-Sep-23 4:10

10-Sep-23 4:10

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

trønderen10-Sep-23 6:28

10-Sep-23 6:28

(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.

dandy7211-Sep-23 2:58

11-Sep-23 2:58

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.

trønderen11-Sep-23 3:58

11-Sep-23 3:58

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.

dandy7211-Sep-23 5:34

11-Sep-23 5:34

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) Smile | :)

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.

dandy7211-Sep-23 3:00

11-Sep-23 3:00

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ønderen11-Sep-23 3:19

11-Sep-23 3:19

"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.

dandy7211-Sep-23 5:29

11-Sep-23 5:29

trønderen wrote:
Signing is a different sort of trust.

Fair enough.

Calin Negru9-Sep-23 5:57

9-Sep-23 5:57

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

Matt Bond11-Sep-23 5:24

Matt Bond

11-Sep-23 5:24

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

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

jschell8-Sep-23 8:13

jschell

8-Sep-23 8:13

Calin Negru wrote:
Windows XP and it’s predecessors did pretty good at recovering when an application went kaboom

What do you mean?

Windows 3.1 would do a hard crash if the network went down.

Databases back then were always corrupting the actual data files due to hardware failures. Or even normal hardware operation. Forums were always filled with questions about how someone needed to attempt to recover their database files. This was true for all the databases I saw back then Oracle, SQL Server and MS Access.

Standard operating procedure in an editor was to manually save the file every couple of minutes, because if it crashed you lost everything. Editors at some point started adding a standard feature to automatically save the file because of that.

Calin Negru8-Sep-23 9:02

8-Sep-23 9:02

> Windows 3.1 would...

I’m not going to argue. When I said predecessors I had in mind mostly the later versions (Windows95 and Windows98). Things got gradually better, Windows XP was pretty good for an OS thought for single core processors. What I’m trying to say, and this is only an impression, I wasn’t around programming when people were running Windows 98 or XP on their PCs, is that if you were playing the role of a programmer and did not dispose things properly (leaving a mess behind in your app on exit) the OS would have been unforgiving. 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.

modified 8-Sep-23 15:26pm.

Amarnath S8-Sep-23 15:32

Amarnath S

8-Sep-23 15:32

In Win95, I remember having caused system crash by this single line, in my code:

C++

int *a = 0;

Not sure whether this problem was fixed in Win98.

It is precisely these kind of coding issues which got handled better in the Dotnet era.

modified 8-Sep-23 21:51pm.

Calin Negru8-Sep-23 22:16

8-Sep-23 22:16

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

jschell11-Sep-23 5:51

jschell

11-Sep-23 5:51

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.

trønderen8-Sep-23 8:38