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

91–100 of 186 posts

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

#91

Post by speed_spread »

johncolanduoni wrote: post #31
speed_spread wrote: post #20

Earlier quoted context omitted.

NTFS is a beast of a filesystem and has been nothing but solid for 25+ years. The performance grievances ignore the warranties that NTFS offers vs many antiquated POSIX filesystems.

What warranties? I assume you’re comparing it to ext4 and not e.g. ZFS?

Here are a few

- mandatory byte-range locks enforced by the kernel

- explicit sharing modes

- guarantees around write ordering and durability

- safe delete-on-close

- first-class cache coherency contracts for networked access

POSIX aims for portability while NTFS/Win32 aims for explicit contracts and enforced behavior. For apps assuming POSIX semantics (e.g. git) NTFS feels rigid and weird. Coming the other way from NTFS, POSIX looks "optimistic" if not downright sloppy.

Of course ZFS et al. are more theoretically more robust than EXT4 but are still limited by the lowest common denominator POSIX API. Maybe you can detect that you're dealing with a ZFS backed volume and use extra ioctls to improve things but its still a messy business.

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

#92

Post by cogman10 »

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

I believe this is where that fact comes from [1]

Basically, 70% of high severity bugs are memory safety.

[1] https://www.chromium.org/Home/chromium-security/memory-safet...

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

#93

Post by tester756 »

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

That's the figure that Microsoft and Google found in their code bases.

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

#94

Post by steveklabnik »

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.

I didn’t say otherwise. Rust is not the point here.

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

#95

Post by cogman10 »

giamma wrote: post #81

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…

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

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

#96

Post by gjfr »

Interesting! We did a similar analysis on Content Security Policy bugs in Chrome and Firefox some time ago, where the average bug-to-report time was around 3 years and 1 year, respectively. https://www.usenix.org/conference/usenixsecurity23/presentat...

Our bug dataset was way smaller, though, as we had to pinpoint all bug introductions unfortunately. It's nice to see the Linux project uses proper "Fixes: " tags.

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

#97

Post by galangalalgol »

Someone wrote: post #72
oguz-ismail2 wrote: post #47

Earlier quoted context omitted.

> 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, y…

Swift is very slow relative to rust or c though. You can also cause seg faults in swift with a few lines. I Don't find any of these languages particularly difficult to read, so I'm not sure why this is listed as a discriminator between them.

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

#99

Post by galangalalgol »

staticassertion wrote: post #86
giamma wrote: post #81

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…

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

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

#100

Post by staticassertion »

galangalalgol wrote: post #99
staticassertion wrote: post #86

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