The fix is preventing kernel mods, but MS legally cannot.
However, doing so is no easy feat. The first version of eBPF was released over 10 years ago.
Apple did not have to sign a settlement with the EU, which Microsoft did in 2009.
The terms of the settlement state:
"Microsoft shall make available to interested undertakings Interoperability Information that enables non-Microsoft server Software Products to interoperate with Windows Server Operating System on an equal footing with other Microsoft Server Software Products." [0]
"Microsoft shall ensure on an ongoing basis and in a Timely Manner that the APIs in the Windows Client PC Operating System and the Windows Server Operating System that are called on by Microsoft Security Software Products are documented and available for use by third-party security software products that run on the Windows Client PC Operating System and/or the Windows Server Operating System. These APIs will be documented on the Microsoft Developer Network, unless open publication would create security risks. In such circumstances, Microsoft will provide third-party security vendors with access to such APIs pursuant to a royalty-free license and on fair, reasonable and non-discriminatory terms." [0]
This means that by offering Microsoft Defender for Endpoint, Microsoft needs to give similar access to the underlying kernel to competing vendors like CRWD and S1.
> At the very least, it means there are safer ways to load third-party code in the kernel without allowing them to crash your entire system by mistake
An eBPF or a similar technology wouldn't necessarily enhance stability when probing kernel-land from user-land, as any interaction with a kernel can cause kernel panics.
Plenty of endpoint vendors have had issues with PTrace (MacOS), kprobes (Linux), eBPF (Linux, K8s), etc.
The reality is that $))&#( happens, and a lot of comments on HN about this bug are really dumb.
[0] - https://news.microsoft.com/download/archived/presskits/eu-ms...
Nothing is perfect, latest generation of Intel CPUs are unstable, bugs are part of all kernels, and so on and so forth. But eBPF does allow for less crashes than a kernel module and these crashes are usually sandboxing error rather than an error made by the third-party provider.
As a matter of fact, the eBPF Linux version of Crowdstrike did create kernel panics on some distros.
> This means that by offering Microsoft Defender for Endpoint, Microsoft needs to give similar access to the underlying kernel to competing vendors like CRWD and S1.
Absolutely, and that's a good thing. This doesn't seem to prevent them from moving Defender to another set of security APIs or from creating another set of security APIs for anyone to hook on.
Apple is also irrelevant in the corporate world, where the Crowdstrike shitshow happened, as they produce mostly consumer devices.
MacOS endpoints are a prominent market as well. There's a reason CRWD, S1, Tanium, and others offer MacOS protection as well.
And anyhow, it seems you are ignoring my point - the settlement with the EU tied MS's hands.
Everything is an API. This means they cannot restrict access to the underlying kernel.
> They had the choice to give Windows APIs that allow to implement such software in a safer way
An indirect method would still inevitably have a potential issue. If a third-party vendor made a mistake, it's the third-party vendor's fault - in this case CRWD.
Sure, it's safer if only a single vendor is allowed to do this but it's also unfair.
> that are called on by Microsoft Security Software Products
Nothing says that Microsofts Security Software needs to be implemented in a way that runs in the kernel, which is inherently more vulnerable. Other platforms have APIs for security software to hook into kernel actions without directly running in kernel space (Windows does too, but to my understanding more limited to logging, not intercepting activity, and hence limited in usefulness).
Hence the claim that it was impossible for Microsoft to prevent this is false. That doesn't mean they take all the blame for someone elses mistake, but it still means that they made a choice leading to it: Deciding that security software, whoever made it, running in kernel modules was the way to do it.
No it doesn't. It just means they should restrict their own products from doing so, too.