Gregory's Server@jfmezei Could you explain how ebpf is going to crash the system
|
5 comments
@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 @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: @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. |
@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.