@mjg59 I you have code that runs in kernel mode (the...

@mjg59 I you have code that runs in kernel mode (the CPU mode) and there is a fault (invalid op code, memory access, divide by 0 etc), then the whole system crashes because there is no fault handler to just crash a process.

Like 20 July at 4:00 | Wall-to-wall | Open on mstdn.ca

4 comments

Matthew Garrett

@jfmezei Yes. How does ebpf code generate any of those things?

20 July at 4:03 | Open on nondeterministic.computer

Jason Haar :laserkiwi:

@mjg59 @jfmezei this is what happened with redhat. They apparently backported some ebpf code to their older rhel9 kernel and introduced a bug. Kernel bugs are normally a good way of crashing things. I would guess their testing didn't pick it up, but then third party crowdstrike loads it's complex ebpf ruleset and "goodnight nurse" ! We lost a bunch of servers that way. Thankfully grub made recovery vastly easier than the current windows nightmare

20 July at 6:06 | Open on mastodon.nz

Alex Haydock

@jhaar @mjg59 @jfmezei True, though I do think mjg’s point still stands since the crash there was really as a result of bugs in Red Hat’s backported kernel code for BPF handling, and not because of CrowdStrike’s actual BPF code.

It’s just extremely unfortunate timing for people making the “eBPF would solve this” argument that this BPF handling bug surfaced recently and of all things it was CrowdStrike that managed to trigger it. :blobcatfacepalm:

20 July at 9:39 | Open on infosec.exchange

Jason Haar :laserkiwi:

@alexhaydock Longer term Crowdstrike is probably doing eBPF a favor: giving it a strong workout - discovering bugs/etc. In fact, the same thing happened after Apple stopped allowing kext modules in MacOS. Crowdstrike flipped over to use the new Mac telemetry APIs and hit bugs there too, ...and then Apple fixed them.

21 July at 7:07 | Open on mastodon.nz