Live data from Hacker News

Kernel bugs hide for 2 years on average. Some hide for 20

pebblebed.com

21–30 of 186 posts

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#21
post #3

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/

Year of HURD on the desktop?

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#22
Before 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 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

#23

Before 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 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

#24

Earlier 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.

What do you meant by them sidestepping the HAL?

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#25
post #2

Firefox 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 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

#27

Earlier quoted context omitted.

Yeah cause windows is amazing Or maybe macos? Ignore their freebsd parts of course.

NT is actually a pretty good kernel. NTFS and the userland is what is shit.

Userland peaked in Windows 2000

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#28

Before 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…

Yeah, Rust gives you much better tools to write highly concurrent state machines than C does, and most of those tools are in the type system and not the borrow checker per se. This is exactly what the Typestate pattern (https://docs.rust-embedded.org/book/static-guarantees/typest...) is good at modeling.

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#29
post #16
post #6

Earlier 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.

Unless that corp is OSI, right?

Re: Kernel bugs hide for 2 years on average. Some hide for 20

#30

Earlier 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.

Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems. Fuchsia/Zircon have improved on the model further.

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.

Post reply on HN