Millions of lines of code, all running in supervisor mode. One bug is all it takes to compromise the entire system. The monolithic UNIX kernel was a good design in the 60s; Today, we should know better[0][1]. 0. https://sel4.systems/ 1. https://genode.org/
Kernel bugs hide for 2 years on average. Some hide for 20
21–30 of 186 posts
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#22It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that interacts with DMA.
That said, if we eliminated the 70% of bugs that are memory safety issues, the SNR ratio for finding these deep logic bugs would improve dramatically. We spend so much time tracing segfaults that we miss the subtle corruption bugs.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#23Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
Rust is not just about memory safety. It also have algebraic data types, RAII, among other things, which will greatly help in catching this kind of silly logic bugs.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#24Earlier quoted context omitted.
If you include all the drivers too (which surely makes the comparison more accurate), is that still the case?
Windows NT 3.x was a true microkernel. Microsoft ruined it but the design was quite good and the driver question was irrelevant, until they sidestepped HAL. The Linux kernel was and is a monstrosity.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#25Firefox bugs stay in the open for that long.
“There’s a crash while using this config file.” Something more complex than that, but ultimately a crash of some kind.
Years later, like 20 years later, the bug was closed. You see, they re-wrote the config parser in Rust, and now this is fixed.”
That’s cool but it’s not the part I remember. The part I always think about is, imagine responding to the bug right after it was opened with “sorry, we need to go off and write our own programming language before this bug is fixed. Don’t worry, we’ll be back, it’s just gonna take some time.”
Nobody would believe you. But yet, it’s what happened.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#26Just worth noting that it is a significant extrapolation from only "28%" of fix commits to assume that the average is 2 years.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#27Re: Kernel bugs hide for 2 years on average. Some hide for 20
#28Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
> It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that interacts with DMA. Rust is not just about memory safety. It als…
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#29Earlier quoted context omitted.
Everything is open source if you're skilled with Ghidra. We call AI models "open source" if you can download the binary and not the source. Why not programs?
>We call AI models "open source" if you can download the binary and not the source. Why not programs? the weights of a model aren't equivalent to the binary output of source code, no matter how you try to stretch the metaphor. >why not because we aren't beholden to change all definitions and concepts because some guy at some corp said so.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#30Earlier quoted context omitted.
Yeah cause windows is amazing Or maybe macos? Ignore their freebsd parts of course.
Yes. As far as kernels go, NT was pretty damn good. So is Mach, by the way, if you can afford the microkernel performance overhead.
Someone will of course bring up XNU, but the microkernel aspect of it died when they smashed the FreeBSD kernel into the codebase. DriverKit has brought some userspace drivers back, but they use shared memory for all the heavy lifting.