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.
_______________________________________________
Discuss mailing list
Discuss@driftwood.blu.org
https://driftwood.blu.org/mailman/listinfo/discuss
