Hacker News Reader

Comment by giamma | Hacker News Reader

Is the intention of the author to use the number of years bugs stay "hidden" as a metric of the quality of the kernel codebase or of the performance of the maintainers? I am asking because at some point the articles says "We're getting faster".

IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good. Unless the time represents how long it takes to reproduce and resolve a known bug, but in such case I would not say that "bug hides" in the kernel.

View on HN

> 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, in most code, it's a pretty safe bet that nothing dangerous happens when use after free is triggered. Especially if the pointer is used shortly after the free and dies shortly after it. In many cases, the erroneous read or write doesn't break something.

The same is true of the race condition problems (which are some of the longest lived bugs). In a lot of cases, you won't know you have a race condition because in many cases the contention on the lock is low so the race isn't exposed. And even when it is, it can be very tricky to reproduce as the race isn't likely to be done the same way twice.

> …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 discovered then.

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.

Maybe you are thinking of ShellShock

https://en.wikipedia.org/wiki/Shellshock_(software_bug)

The bug was introduced into the code in 1989, and only found and exploited in 2014.

> IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good.

It doesn't seem to indicate that. It indicates the bug just isn't in tested code or isn't reached often. It could still be a very severe bug.

The issue with longer lived bugs is that someone could have been leveraging it for longer.

Worst case is that it doesn't even cause correctness issues in normal use, only when misused in a way that is unlikely to happen unintentionally.

I guess because I work in security the "unintentionally" doesn't matter much to me.

But it matters for detection time, because there's a lot more "normal" use of any given piece of code than intentional attempts to break it. If a bug can't be triggered unintentionally it'll never get detected through normal use, which can lead to it staying hidden for longer.

That's not really contested? The statement was that longer detection time indicates lower severity.

Reply on news.ycombinator.com