Microsoft Moves Antivirus Software Out of Windows Kernel To Prevent CrowdStrike-Style Crashes (zdnet.com)
- Reference: 0178195044
- News link: https://tech.slashdot.org/story/25/06/26/1650259/microsoft-moves-antivirus-software-out-of-windows-kernel-to-prevent-crowdstrike-style-crashes
- Source link: https://www.zdnet.com/article/microsoft-rolls-out-windows-security-changes-to-prevent-another-crowdstrike-meltdown/
The new Windows endpoint security platform is being developed in cooperation with CrowdStrike, Bitdefender, ESET, Trend Micro, and other security vendors. David Weston, Microsoft's vice president of enterprise and OS security, said dozens of partners have submitted papers detailing design requirements, some hundreds of pages long. The private preview will allow security vendors to request changes before the platform is finalized.
[1] https://www.zdnet.com/article/microsoft-rolls-out-windows-security-changes-to-prevent-another-crowdstrike-meltdown/
[2] https://it.slashdot.org/story/24/07/19/0943232/global-it-outage-linked-to-crowdstrike-update-disrupts-businesses
The smaller critical s/ware is the better (Score:2)
The smaller it is:
* the easier it is to audit
* the less often it will need to be updated
This means that it will be less likely to break.
It is a step in the right direction (Score:2)
Maybe the approach can also be used to move other 3rd party kernel mode drivers into a more protected/isolated sandbox.
Advanced Windows users take note (Score:1)
[1]You have the option of additional security by moving additional services out of the Windows kernel [linuxmint.com].
[1] https://www.linuxmint.com/
this begs the question... (Score:3)
"why was it in the kernel to begin with?"
kernel changes should be tightly controlled. Not pushed out anytime a vendor has a (poorly tested) update they want to blast to the masses.
Keep outside party code out of the kernel !
Re: (Score:3)
Speed. It's why Windows uses the kernel for graphics and Linux tried httpd acceleration for a while. [1]http://www.fenrus.demon.nl/ [demon.nl]
[1] http://www.fenrus.demon.nl/
Wrong reason... (Score:3)
It has nothing at all to do with speed. It has to do with visibility. Being part of the kernel was the only way for security products to have the level of visibility they required into the OS operation to do their job.
Re: (Score:2)
> Being part of the kernel was the only way for security products to have the level of visibility they required into the OS operation to do their job.
Nope. It was the cheap solution. Linux did it with eBPF for CrowdStrike all along, no vendor kernel module needed.
Re: Wrong reason... (Score:1)
Clownstroke said they didn't use the same functionality on Windows because it wasn't mature, though it has been there for a while. Does this seem true or like an excuse?
Re: (Score:2)
Clownstroke could have at the very least used their own hardened kernel module. Instead they made cheap crap and then they messed up using it right.
Re: (Score:3)
Simple: That was the _cheap_ solution. Engineers do not call the shots at Microsoft, MBAs do.
Re: (Score:5, Interesting)
Finally, I hate it how third-party AVs casually help themselves into the kernel (via a kernel driver that patches the kernel) as if we are still running XP 32-bit and PatchGuard isn't a thing. Microsoft leaving holes in PatchGuard for AV vendors to use is and has always been downright evil.
Dang it! (Score:3)
This means I won't get another [1]Uber Eats gift card. [pcmag.com]
[1] https://www.pcmag.com/news/crowdstrikes-big-apology-for-the-massive-outage-is-a-10-uber-eats-gift
Finally (Score:2)
The fuckups at MS should have done that from the beginning. But solid systems engineering is not done at MicroShit.
Would that be nice if they did that for games ? (Score:1)
Can they do the same thing with 3rd party Kernel Anti-Cheat System ?
Just asking for a friend :D
So, yeah for microkernels? (Score:2)
So, we have an example of the advantage of a microkernel approach over a monolithic kernel? Of in general monoliths are more prone to exploitation since they do so much in the kernel?
Re:So, yeah for microkernels? (Score:5, Interesting)
That just about sums it up. Moving drivers into user land definitely reduces the attack surface. As it stands, antivirus software in most cases is essentially a rootkit, just one we approve of because that low level access allows it to intercept virus activity at the lowest level. With a microkernel, nothing gets to run at that level anyways, so microkernels are inherently more secure.
Traditionally the objection to microkernels was they were slower, since message passing has a processing cost in memory, IO bandwidth and CPU cycles. In the old days where may you had a couple of MB of RAM, or even 8 or 16mb of RAM (like my last 486), with 16 bit ISA architecture and chips that at the high end might run at 40-60mhz, a microkernel definitely was going to be a bit more sluggish, particularly where any part of that bandwidth was being taxed (i.e. running a web stack), so Windows and Linux both, while over time adopting some aspects of microkernel architecture (I believe Darwin is considered a hybrid), stuck with monolithic architecture overall because it really is far less resource intensive.
But we're in the age when 16gb of RAM on pretty high end CPUs where even USB ports have more throughput that an old ISA bus, that I suspect it may be time to revive microkernels.
Re: (Score:2)
That's all well and good. You understand that. So do I. And probably so do the engineers at Microsoft. But that's not the problem. Let's be real, this is no longer the Swiss-cheese-security Microsoft from the NT/XP. As much as it pains me to admit it, their engineers, at least, have a clue. Moving AV out of the kernel was likely in their backlog. But I'm sure you're as aware as well as I am that engineering teams often have more work than time on their plates, and "nice to have" has a tendency to become "If
How About Graphics Drivers? (Score:4, Interesting)
As you correctly point out, passing messages between kernel space and user land consumes resources, which is why Microsoft moved graphics drivers inside the kernel back in the 90's. That led to a decade of "replace your graphics driver with the generic Microsoft one" advice to solve Windows crashes. The graphics vendors eventually got their act together, but I'm pretty sure graphics drivers still have kernel acccess. Maybe they can be next for banishment to user land?
Re: (Score:3)
Vista moved graphics drivers back into userspace. It was only from NT4 to Server 2003/XP x64 Edition that they were in the kernel. They also made it so Windows can restart a crashed graphics driver - the screen will temporarily go black but the system will keep running. That's part of the reason you can reinstall/upgrade/downgrade graphics drivers without a restart now.
Still a full context switch (Score:2)
Microkernel architectures still always involve doing a full context switch when moving between processes. All the registers need to be reloaded, importantly including the entire page table. The page table flush is particularly painful.
Actually may avoid a full context switch (Score:2)
> Microkernel architectures still always involve doing a full context switch when moving between processes. All the registers need to be reloaded, importantly including the entire page table. The page table flush is particularly painful.
It works both ways. If the operating system service is reimplemented outside of the kernel then we now avoid a context switch.
Re: (Score:3)
I wouldn't call it microkernel, but the idea is vaguely similar. Linux, considered monolithic, implements eBPF which is used by Cloudstrike and others to do their threat detection on Linux. Glad to see Windows finally getting a similar, safer mechanism.