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.
my zsh config spawns in ~90ms on my macbook air m2 while it takes 600ms in the m1 pro.
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.
I hate all the EDR nonsense on laptops. I wonder if the added cost for lost workhours and electricity wouldn't be more than the tiny chance of catching a malware.
Once I got new laptop due to some internal migration, it was blazingly fast. Well, not so much anymore. I literally don't install anything on it since receiving it, I simply can't (unless its just about copying to c: and it runs). Some colleagues have stuff like windows firewall running constantly on 50% cpu, nothing admins can fix apart from replacing ntb.
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.