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

141–150 of 186 posts

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

#141

Post by pixl97 »

a3w wrote: post #90
dpc_01234 wrote: post #41

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

The kernel this speaks of is probably linux. Does windows have a similar round time?

I mean, yea.

Here is a device driver bug that was around 11 years.

https://www.bitdefender.com/en-us/blog/hotforsecurity/google...

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

#142

Post by pixl97 »

ryukoposting wrote: post #123

This is fascinating stuff, especially the per-subsystem data. I've worked with CAN in several different professional and amateur settings, I'm not surprised to see it near the bottom of this list. That's not a dig against the kernel or the folks who work on it... more of a heavy sigh about the state of the industries that use CAN. On a related note, I'm seeing a correlation between "level of hoopla" and a "level of a…

There is a general rule on bugs is that the more devices they are on, the more apt they are to trigger.

A CAN with 10,000 machines total and relatively fixed applications is either going to trigger the bug right off the bat and then work around it, or trigger the bug so rarely it won't be recognized as a kernel issue.

General purpose systems running millions and millions of units with different workloads are an evolutionary breeding ground for finding bugs and exploits.

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

#143

Post by john01dav »

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…

Rust has more features than just the borrow checker. For example, it has a a more featured type system than C or C++, which a good developer can use to detect some logic mistakes at compile time. This doesn't eliminate bugs, but it can catch some very early.

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

#144

Post by wordisside »

john01dav wrote: post #143
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…

Rust has more features than just the borrow checker. For example, it has a a more featured type system than C or C++, which a good developer can use to detect some logic mistakes at compile time. This doesn't eliminate bugs, but it can catch some very early.

[dead]

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

#146

Post by redleader55 »

I don't think the problem is the kernel. Kernel bugs stay hidden because no one runs recent Kernels.

My Pixel 8 runs kernel a stable minor from 6.1, which was released more than 4 years ago. Yes, fixes get backported to it, but the new features in 6.2->6.19 stay unused on that hardware. All the major distros suffer from the same problem, most people are not running them in production

Most hyperscalers are running old kernel versions on which they do backports. If you go Linux conferences you hear folks from big companies mentioning 4.xx, 3.xx kernels, in 2025.

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

#147

Post by aw1621107 »

wordisside wrote: post #128
jmyeet wrote: post #113

The lesson here is that people have an unrealistic view of how complex it is to write correct and safe multithreaded code on multi-core, multi-thread, assymmetric core, out-of-order processors. This is no shade to kernel developers. Rather, I direct this at people who seem to you can just create a thread pool in C++ and solve all your concurrency problems. One criticism of Rust (and, no, I'm not saying "rewrite it in…

[dead]

> The implementations of sort in Rust are filled with unsafe.

Strictly speaking, the mere presence of `unsafe` says nothing on its own about whether "it" is easier in C++. Not only does `unsafe` on its own say nothing about the "difficulty" of the code it contains, but that is just one factor of one side of a comparison - very much insufficient for a complete conclusion.

Furthermore, "just" writing a sorting algorithm is pretty straightforwards both in Rust and C++; it's the more interesting properties that tend to make for equally interesting implementations, and one would need to procure Rust and C++ implementations with equivalent properties, preferably from the same author(s), for a proper comparison.

Past research has shown that Rust's current sorting algorithms have different properties than C++ implementations from the time (e.g., the "X safety" results in [0]), so if nothing substantial has changed since then there's going to be some work to do for a proper comparison.

Edit: forgot to add the reference [0]: https://github.com/Voultapher/sort-research-rs/blob/main/wri...

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

#148

Post by aw1621107 »

wordisside wrote: post #130
jmyeet wrote: post #113

The lesson here is that people have an unrealistic view of how complex it is to write correct and safe multithreaded code on multi-core, multi-thread, assymmetric core, out-of-order processors. This is no shade to kernel developers. Rather, I direct this at people who seem to you can just create a thread pool in C++ and solve all your concurrency problems. One criticism of Rust (and, no, I'm not saying "rewrite it in…

[dead]

> Also, the Linux kernel developers turned off strict aliasing in the C compilers they use, because they found strict aliasing too difficult.

I'm not sure "they found strict aliasing too difficult" is an entirely correct characterization? From this rather (in)famous email from Linus [0]:

    The fact is, using a union to do type punning is the traditional AND
    STANDARD way to do type punning in gcc. In fact, it is the
    *documented* way to do it for gcc, when you are a f*cking moron and
    use "-fstrict-aliasing" and need to undo the braindamage that that
    piece of garbage C standard imposes.

    [snip]

    This is why we use -fwrapv, -fno-strict-aliasing etc. The standard
    simply is not *important*, when it is in direct conflict with reality
    and reliable code generation.

    The *fact* is that gcc documents type punning through unions as the
    "right way". You may disagree with that, but putting some theoretical
    standards language over the *explicit* and long-time documentation of
    the main compiler we use is pure and utter bullshit.
[0]: https://lkml.org/lkml/2018/6/5/769

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

#149

Post by aw1621107 »

wordisside wrote: post #144
john01dav wrote: post #143

Earlier quoted context omitted.

Rust has more features than just the borrow checker. For example, it has a a more featured type system than C or C++, which a good developer can use to detect some logic mistakes at compile time. This doesn't eliminate bugs, but it can catch some very early.

[dead]

> But unsafe Rust, which is generally more often used in low-level code, is more difficult than C and C++.

I think "is" is a bit too strong. "Can be", sure, but I'm rather skeptical that all uses of unsafe Rust will be more difficult than writing equivalent C/C++ code.

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

#150

Post by wordisside »

aw1621107 wrote: post #147
wordisside wrote: post #128

Earlier quoted context omitted.

[dead]

> The implementations of sort in Rust are filled with unsafe. Strictly speaking, the mere presence of `unsafe` says nothing on its own about whether "it" is easier in C++. Not only does `unsafe` on its own say nothing about the "difficulty" of the code it contains, but that is just one factor of one side of a comparison - very much insufficient for a complete conclusion. Furthermore, "just" writing a sorting algorith…

[flagged]
Post reply on HN