[Discuss] CrowdStrike Fiasco (eBPF)

[kentborg at borg.org (Kent Borg)]

On 7/30/24 12:04, Dale R. Worley wrote:
> My experience is that my opinion of the quality of proprietary software
> vs. the quality of open source software varies depending on what major
> software I've had to deal with recently

I figure for software where someone is willing to let others see the 
source code, that means it isn't completely embarrassing. Open source 
software is software where someone is willing to risk that shame. This 
logic votes for open source being better. And I have certainly seen some 
proprietary software that is?ugly.

But there is no reason proprietary software can't be good, just that 
that one pressure for quality is reduced when sources are kept secret.


Slight change of topic: I've seen people talking about the dangers of 
letting third parties inside the MS Windows kernel, and then today I ran 
across "eBPF", that it is in the Linux kernel (I've heard of "BPF"). And 
it will soon be in the MS Windows kernel. (What?)

Further, using it would have prevented this fiasco.

THAT got my attention, I've heard of "Berkeley Packet Filter", but that 
has that got to do with commercial security products running on Windows??

:read-read:

Interesting, in the form of "eBPF" (extended), BPF has morphed into a 
general purpose virtual assembly language. A bit like WASM, but not 
quite the same.

Where WASM is interpreted in a rather sterile sandbox, eBPF gets safety 
verified on-the-fly, just-in-time compiled into native code, and then 
run at full speed, with only a few runtime checks having been inserted 
as part of the JIT compilation. (People are at least playing with JIT 
compiling WASM, donno whether main browsers do so yet, but I guess these 
differences will fuzz.)

The safety guarantees get, um, interesting in what various Linux 
subsystems choose to expose to eBPF, and which of those a given program 
is allowed to access, and whether that all adds up to something secure, 
and for what purposes, will in practice to be a bit messy

But WASM isn't useful until it is allowed some access to the outside 
world, and there are going to be tricky things there, too.


I suppose the real surprise is that this is by no means just a "packet 
filter", using it for other purposes is *not* a hack, it is general 
purpose, and designed to be really fast. It can be used in places that 
have nothing to do with Linux (such as MS Windows) and apparently can be 
used in circumstances that have nothing to do with OS kernels at all.


Another thing: The safety of eBPF can be "extended" into the C code of 
the kernel. Huh?

For this Linux C example:

> # define __rcu BTF_TYPE_TAG(rcu)

Supposedly:

> normal C: for debug kernel and for sparse tool to warn
>
> extended C: access is enforced by the verifier.? Cannot do RCU
> dereference outside of RCU critical section.? rcu_read_unlock()
> invalidates the pointers.? Use-After-Free is prevented.

That second part sounds like what Rust brags about. Cool.


Oh, and eBPF is in LLVM's backend, so eBPF code can be written in 
various languages (including Rust).


Interesting. Computers aren't over.


-kb, the Kent who knows he gets out of date, but then he sometimes 
catches up.