Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pebblebed.com

Post reply on HN
Print view View original

71–80 of 186 posts

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

#71

Post by josefx »

snvzz wrote: 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/

Of course by now processor manufacturers decided that blowing holes into the CPUs security model to make it go faster was the way to go. So your micro kernel is stuck on a hardware security model that looks like swiss cheese and smells like Surströmming.

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

#72

Post by Someone »

oguz-ismail2 wrote: post #47
rjzzleep wrote: post #46

Earlier quoted context omitted.

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.

Apple claims Swift can be used for systems programming, and is (partly) eating its own dogfood by using it in FoundationDB (https://news.ycombinator.com/item?id=38444876) and by providing examples of embedded projects (https://www.swift.org/get-started/embedded/)

I think they are right in that claim, but in making it so, at least some of the code loses some of the readability of Swift. For truly low-level code, you’ll want to give up on classes, may not want to have copy-on-write collections, and may need to add quite a few some annotations.

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

#73

Post by MarleTangible »

jackfranklyn wrote: post #65

[flagged]

One of the iOS 26 Core Audio bug (CVE-2025-31200) is about synchronizing two different arrays with each other and the assumption mistakes that were made trusting dimensional information which could be coming from the user.

https://youtu.be/nTO3TRBW00E

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

#75

Post by nibman »

Fiveplus wrote: post #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 int…

[dead]

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

#77

Post by Xss3 »

nurettin wrote: post #45
steveklabnik wrote: post #25

Earlier quoted context omitted.

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.

But that take ruins all the intrigue of their comment... But youre spot on. They fabricated a story.

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

#78

Post by burnt-resistor »

Speaking of nasty kernel bugs although on another platform, there's a nasty one in either Microsoft's Win 11 nwifi.sys handling of deadlock conditions or Qualcomm's QCNCM865 FastConnect 7800 WCN785x driver that panics because of a watchdog failure in nwifi!MP6SendNBLInternal+0x4b guarded by a deadlocked ndis!NdisAcquireRWLockRead+0x8b. It "BSODs" the system rather than doing something sane like dropping a packet or retransmitting.

Am I the only unreasonable maniac who wants a very long-term stable, seL4-like capability-based, ubiquitous, formally-verified μkernel that rarely/never crashes completely* because drivers are just partially-elevated programs sprinkled with transaction guards and rollback code for critical multiple resource access coordination patterns? (I miss hacking on MINIX 2.)

* And never need to reboot or interrupt server/user desktop activities because the core μkernel basically never changes since it's tiny and proven correct.

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

#79

Post by nibman »

mgaunard wrote: post #70
Fiveplus wrote: post #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 int…

I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.

[dead]

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

#80

Post by pjc50 »

Fiveplus wrote: post #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 int…

> race condition in unsafe logic that interacts with DMA

It's worth noting that if you write memory safe code but mis-program a DMA transfer, or trigger a bug in a PCIe device, it's possible for the hardware to give you memory-safety problems by splatting invalid data over a region that's supposed to contain something else.

Post reply on HN