4 ms·

Didn't CRWD cause a similar issue with Debian/RHEL a little while ago? It sounds to me that the problem lies with CRWD and not with whatever OS it's installed

by Saris 2y ago

Didn't CRWD cause a similar issue with Debian/RHEL a little while ago? It sounds to me that the problem lies with CRWD and not with whatever OS it's installed on.

rbanffy 2y ago
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.
- okanat 2y ago
  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.
  - rbanffy 2y ago
    > 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.
  - aenis 2y ago
    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.
    - rbanffy 2y ago
      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.
  - __MatrixMan__ 2y ago
    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.
    - rbanffy 2y ago
      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.
      - okanat 2y ago
        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.
      - __MatrixMan__ 2y ago
        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.

by Saris 2y ago

Didn't CRWD cause a similar issue with Debian/RHEL a little while ago? It sounds to me that the problem lies with CRWD and not with whatever OS it's installed on.

rbanffy 2y ago

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.

okanat 2y ago
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.
- rbanffy 2y ago
  > 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.
- aenis 2y ago
  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.
  - rbanffy 2y ago
    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.
- __MatrixMan__ 2y ago
  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.
  - rbanffy 2y ago
    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.
    - okanat 2y ago
      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.
    - __MatrixMan__ 2y ago
      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.