nowadays i work at a place that uses a different solution and guess what: it's also a f-ing cpu (and i/o) hog -- it makes my m1 pro macbook slow to a crawl and there's no way to disable it.
Except where Apple does not allow vendors loose in key places like the kernel. One of the interesting questions here is whether Microsoft could possibly do that: Windows users would be better if the kernel was restricted to first-party code, things like AV used the same kind of interface which macOS has, and third-party code was forced into more moderated channels (malware uses many of the same techniques) – but there’s a security industry with revenue measured in tens of billions of dollars annually who would be running to the regulators if there was anything which could remotely be seen as favoring Defender over their products. I still think it’d be possible but hard enough that I’m not surprised they’ve slowly been letting awareness of the downsides build, especially on the enterprise IT side.
I was wondering whether this debacle might push them to have a roadmap for restricting kernel drivers in favor of the Windows eBPF implementation which has been approaching production grade. Sometimes you need a huge blowup to remove support for the status quo.
Though as this article and its Red Hat respondents admit eBPF isn't a perfect solution either because it is still a somewhat Turing Complete scripting language and bad vendors will find ways to get kernel panics out of eBPF scripts no matter how hardened the eBPF driver gets.
Microsoft is probably in a good position to use this debacle to push more vendors to Windows' implementation of eBPF. It doesn't solve the crisis that a vendor like CrowdStrike exists that is "beloved" by Enterprise Solution Architects for all the compliance boxes it checks, but is run as a terrible software company with bad standards and has multiple "accidents" in recent weeks.