Might be obviously, but there is definitely a lot of biases in the data here. It's unavoidable. E.g. many bugs will not be detected, but they will be removed when the code is rewritten. So code that is refactored more often will have lower age of fixed bugs. Components/subsystems that are heavily used will detect bugs faster. Some subsystems by their very nature can tolerate bugs more, while some by necessity will need to be more correct (like bpf).
Kernel bugs hide for 2 years on average. Some hide for 20
41–50 of 186 posts
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#42Earlier quoted context omitted.
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.
What do you meant by them sidestepping the HAL?
I think the biggest one is that the whole GDI library was moved into the Kernel in 3.5x because the performance was terrible at the time.
I don't think they ever intended to keep all drivers strictly userland, though. Just the service side.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#43Imagine if no one outside a select circle ever got to examine the code.
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?
Binaries and AI models can be inscrutable. They're meant to be interpreted by machines.
We want human readable, comprehensible, reproducible and maintainable sources at minimum when we say open source.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#44Earlier 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.
XNU monolith-ized itself over time, even over some microkernel-esque boundaries.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#45Firefox bugs stay in the open for that long.
One of my favorite Firefox bugs was some I don’t quite remember the details of, but went something like this: “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…
To be fair, any rewrite could have fixed it, didn't have to wait for Rust.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#46Earlier quoted context omitted.
It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release buil…
> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with.
Which is also why in my opinion Zig is much more suitable, because it actually addresses the readability aspect without bring huge complexity with it.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#47Earlier quoted context omitted.
> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it a…
> Zig is much more suitable, because it actually addresses the readability aspect
How? It doesn't look very different from Rust. In terms of readability Swift does stand out among LLVM frontends, don't know if it is or can be used for systems programming though.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#48[deleted]
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#49Before 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) While the bugs you describe are indeed things that aren't directly addressed by Rust's borrow checker, I think the article covers more ground than your comment implies. For example, a significant portion (most?) of the article is simply analyzing the gathered data, like groupin…
> Furthermore, the 19-year-old bug case study is a refcounting error
It always surprised me how the top-of-the line analyzers, whether commercial or OSS, never really implemented C-style reference count checking. Maybe someone out there has written something that works well, but I haven’t seen it.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#50Earlier quoted context omitted.
> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it a…
I would expect the opposite. C requires you to deal with extreme design complexity in large systems because the language offers nothing to help.