When an operating system allows a single misbehaving program to take down the whole computer and leave it unbootable. I thought we left that behind with Windows 95.
I think this is part of the reason Apple is trying real hard to prevent people from loading third party drivers. While that means a lot of hardware simply won’t work on their machines, at least a bug can’t cause a kernel panic.
As long as third party software is allowed to be loaded into the kernel (drivers, HALs, filters) we’ll have bluescreens created by applications. You can go without third party drivers, you just won’t be able to game on your computer, or run any antivirus software that wasn’t made by your OS vendor, or use any USB peripheral more complicated than a keyboard, or use WiFi.
They are, but many if them don’t provide the same abilities or functionality that the kernel level interfaces did. For example, their network filtering/firewall API had (has?) a design flaw that allowed Apple’s software to bypass any attempts to block traffic.
Windows does the same, and Linux is slowly moving towards running more stuff in user space as well, but there’s no way to run something like CrowdStrike without low level access, at least not without crippling its capabilities.
Operating systems are moving as much software out of the low level kernel space as they can. On Windows, the entire GPU driver can crash and the OS will just flash a black screen and recover. Your games and browser probably go down with the driver, but that important Word document you had open in the background will survive.
In this case, there’s no way to implement the features at hand anywhere but deep down at the kernel level. It’s like anticheat but except for intercepting cheating software it’s intercepting all software that looks a bit suspicious. There are ways to protect against this (running applications in a virtual machine with a microkernel of their own for instance) but in practice this won’t work for the type of user Windows mostly serves.
As long as software like CrowdStrike is necessary, we run the risk of this stuff crashing. However, the impact doesn’t need to be this high; the reason everything went to shit is that every company installed this one piece of software onto their critical machines, rather than diversifying and having two different vendors. They probably don’t want twice the management overhead and twice the price, but they could’ve gone with a competitor on half their systems and only have half their services crash.
This isn’t a driver. It’s anti-malware. Nobody on Linux puts such software in kernel space (as far as I’m aware). Root service? maybe, but that’s still a user-space process.
It is a driver though, it runs at kernel level and intercepts system calls for logging, analysis, and potential blocking if malware type patterns are detected in the system calls.
When an operating system allows a single misbehaving program to take down the whole computer and leave it unbootable. I thought we left that behind with Windows 95.
I think this is part of the reason Apple is trying real hard to prevent people from loading third party drivers. While that means a lot of hardware simply won’t work on their machines, at least a bug can’t cause a kernel panic.
As long as third party software is allowed to be loaded into the kernel (drivers, HALs, filters) we’ll have bluescreens created by applications. You can go without third party drivers, you just won’t be able to game on your computer, or run any antivirus software that wasn’t made by your OS vendor, or use any USB peripheral more complicated than a keyboard, or use WiFi.
Apple is introducing a lot of user space frameworks to replace much of the kext level functionality though.
They are, but many if them don’t provide the same abilities or functionality that the kernel level interfaces did. For example, their network filtering/firewall API had (has?) a design flaw that allowed Apple’s software to bypass any attempts to block traffic.
Windows does the same, and Linux is slowly moving towards running more stuff in user space as well, but there’s no way to run something like CrowdStrike without low level access, at least not without crippling its capabilities.
That has been a thing forever. I doubt it will ever go away.
Operating systems are moving as much software out of the low level kernel space as they can. On Windows, the entire GPU driver can crash and the OS will just flash a black screen and recover. Your games and browser probably go down with the driver, but that important Word document you had open in the background will survive.
In this case, there’s no way to implement the features at hand anywhere but deep down at the kernel level. It’s like anticheat but except for intercepting cheating software it’s intercepting all software that looks a bit suspicious. There are ways to protect against this (running applications in a virtual machine with a microkernel of their own for instance) but in practice this won’t work for the type of user Windows mostly serves.
As long as software like CrowdStrike is necessary, we run the risk of this stuff crashing. However, the impact doesn’t need to be this high; the reason everything went to shit is that every company installed this one piece of software onto their critical machines, rather than diversifying and having two different vendors. They probably don’t want twice the management overhead and twice the price, but they could’ve gone with a competitor on half their systems and only have half their services crash.
Drivers usually run in kernel space, where a crash can bring the whole system down. This is not exclusive to Windows
This isn’t a driver. It’s anti-malware. Nobody on Linux puts such software in kernel space (as far as I’m aware). Root service? maybe, but that’s still a user-space process.
It is a driver though, it runs at kernel level and intercepts system calls for logging, analysis, and potential blocking if malware type patterns are detected in the system calls.
Yes but only in Windows land do you see jillions of (proprietary) drivers made by 3rd parties. Many of which self-update.