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

121–130 of 186 posts

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

#121

Post by tremon »

silver_sun wrote: post #26

Their section on "Dataset limitations" says that the study "Only captures bugs with Fixes: tags (~28% of fix commits)." Just worth noting that it is a significant extrapolation from only "28%" of fix commits to assume that the average is 2 years.

Why? A sample size of 28% is positively huge compared to what most statistical studies have to work with. The accuracy of an extrapolation is mostly determined by underlying sampling bias, not the amount of data. If you have any basis to suggest that capturing "only bugs with fixes tags" creates a skewed sample, that would be grounds to distrust the extrapolation, but simply claiming "it's only 28%" does not make it worth noting.

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

#123

Post by ryukoposting »

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 attention/maintenance." While it's hard to distinguish that correlation from "level of use," the fact that CAN is so far down the list suggests to me that hoopla matters; it's everywhere but nobody talks about it. If a kernel bug takes down someone's datacenter, boy are we gonna hear about it. But if a kernel bug makes a DeviceNet widget freak out in a factory somewhere? Probably not going to make the front page of HN, let alone CNN.

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

#124

Post by cogman10 »

turtletontine wrote: post #114
cogman10 wrote: post #95

Earlier quoted context omitted.

> IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority Not really true. A lot of very severe bugs have lurked for years and even decades. Heartbleed comes to mind. The reason these bugs often lurk for so long is because they very often don't cause a panic, which is why they can be really tricky to find. For example, use after free bugs are really dangerous. However…

> …lurked for years and even decades. Heartbleed comes to mind. I don’t know much about Heartbleed, but Wikipedia says: > Heartbleed is a security bug… It was introduced into the software in 2012 and publicly disclosed in April 2014. Two years doesn’t sound like “years or even decades” to me? But again, I don’t know much about Heartbleed so I may be missing something. It does say it was also patched in 2014, not just…

This may just be me misremembering, but as I recall, the bug of Heartbleed was ultimately a very complex macro system which supported multiple very old architectures. The bug, IIRC, was the interaction between that old macro system and the new code which is what made it hard to recognize as a bug.

Part of the resolution to the problem was I believe they ended up removing a fair number of unsupported platforms. It also ended up spawning alternatives to openssl like boring ssl which tried to remove as much as possible to guard against this very bug.

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

#125

Post by nobodyandproud »

WalterGR wrote: post #24
nobodyandproud wrote: post #19

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

Mind you I don't have access to Microsoft code, so this is all indirect, and a lot of this knowledge was when I was fledgling developer.

The Windows NT code was engineered to be portable across many different architectures--not just X86--so it has a hardware abstraction layer. The kernel only ever communicated to the device-driver implementation through this abstraction layer; so the kernel code itself was isolated.

That doesn't mean the device drivers were running in user-land privilege, but it does mean that the kernel code is quite stable and easy to reason about.

When Microsoft decided to compromise on this design, I remember senior engineers--when I first started my career--being abuzz about it for Windows NT 4.0 (or apparently earlier?).

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

#126

Post by dspillett »

immibis wrote: post #6
esseph wrote: post #4

Imagine 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?

North Korea is called a “democratic people's republic”. Just because one thing that really isn't is called by the people in coontrol of it, doesn't mean that it is or that incorrectly calling other things is correct.

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

#127

Post by nobodyandproud »

pjmlp wrote: post #60
nobodyandproud wrote: post #19

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

This is outdated since Windows Vista, and even more so in Windows 11.

Windows Vista isn't Windows NT 3.x. In the internal versioning, it's not even 4.0.

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

#128

Post by wordisside »

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]

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

#130

Post by wordisside »

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]
Post reply on HN