A kernel driver can, definitely, take down a Linux machine.

The question is whether someone should implement something like this as a kernel module when there are better ways.

Windows also has better ways such as filter drivers and hooks. If everybody used Linux, Crowd Strike would still opt for the kernel driver since the software they create is effectively spyware that wants access to stuff as deep as possible.

If they opted for an eBPF service but put that into early boot chain, the bootloop or getting stuck could still happen.

The only long time solution is to stop buying software from a company that has a track record of being pushy and having terrible software practices like rolling out updates to the entire field.

I think the only real solution is for MSFT to stop allowing kernel level drivers, as Apple has already (sorf of, but nearly) done. Sure, lots and lots of crap runs on windows in kernelspace, but what happened today cost a sizable fraction of world's GDP. There won't be a better wake up call.

I hope that, in the future, we have better robot firmware validation protocols in place when pushing OTA updates.

Maybe Skynet didn't mean any of that - it was just a botched update.

But would the Linux sysadmins of the world play along in the way that the Windows sysadmins of the world did? I think they might've given Crowd Strike the finger and confined them to a smaller blast radius anyhow. And if they wouldn't have... well they will now.

Third-party blobs running in kernel space being delivered through their own channels without anyone in the company signing them off?

I don’t think I ever met a Unix person with whom that idea would fly.

Once it gets popular, I think it would happen. The business people and C-suite would request quick dirty solutions like Crowd Strike's offerings to check boxes when entering new markets and go around the red tape. So they'll force Unix people to do as they say or else.

Agreed. It's a safer culture because it grew up in the wild. Windows, by contrast, is for when everybody you're using it with has the same boss... places where sanity can be imposed by fiat.

If Microsoft is to be blamed here, it's not for the quality of their software, it's for fostering a culture where dangerous practices are deemed acceptable.

> If they opted for an eBPF service but put that into early boot chain, the bootloop or getting stuck could still happen.

If the in-kernel part is simple and passes data to a trusted userland application the likelyhood of a major outage like the one we saw is much reduced.