“In a sufficiently complex system, malfunction or even total non-function may go undetected for long periods, if ever”
John Gall, The Systems Bible
Kernel bugs hide for 2 years on average. Some hide for 20
171–180 of 186 posts
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#172Earlier quoted context omitted.
Only serious if you care about protecting from malicious actors running code on the same host.
you dont? I would imagine people that runs for example a browser would have quite an interest in that
Browsers are sandboxed, and working on the web browsers themselves is a very small niche, as is working on kernels.
Software increasingly runs either on dedicated infrastructure or virtual ones; in those cases there isn't really a case where you need to worry about software running on the same host trying to access the data.
Sure, it's useful to have some restrictions in place to track what needs access to what resource, but in practice they can always be circumvented for debugging or convenience of development.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#173Earlier quoted context omitted.
Indeed, it is something better, Windows NT 6.0. And it is irrelevant anyway, given that this comment was written from 10.0.26100.
Oh, I see. You’re saying they improved the design. I know they added user-privilege device driver support for USB (etc).; did they revert the display compromise/mess as well?
Yes, now graphics drivers are mostly in userspace, with only a tiny driver in kernel space, miniport.
Hence why graphics usually no longer crash Windows, after a small black screen pause, everything continues as usual.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#174Earlier quoted context omitted.
> It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) While the bugs you describe are indeed things that aren't directly addressed by Rust's borrow checker, I think the article covers more ground than your comment implies. For example, a significant portion (most?) of the article is simply analyzing the gathered data, like groupin…
It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release buil…
> It’s also worth noting that Rust doesn’t prevent integer overflow
Add a single line to a single file and you get that enforced.
https://rust-lang.github.io/rust-clippy/stable/index.html#ar...
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#175Earlier quoted context omitted.
you dont? I would imagine people that runs for example a browser would have quite an interest in that
Browsers are sandboxed, and working on the web browsers themselves is a very small niche, as is working on kernels. Software increasingly runs either on dedicated infrastructure or virtual ones; in those cases there isn't really a case where you need to worry about software running on the same host trying to access the data. Sure, it's useful to have some restrictions in place to track what needs access to what resou…
Browsers are sandboxed by the kernel, and we're talking about bugs in the kernel here...
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#176Earlier quoted context omitted.
> Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems. As opposed to Mach, which is not used in any actual systems
I mentioned XNU below. It doesn’t really count as a microkernel if you, you know, don’t actually use the microkernel part. At least for the 30 years between the FreeBSD collision and the introduction of DriverKit, which does most of its IPC through shared memory (because the mach ports are not efficient enough, I would assume).
Yes, but a lot of other things use Mach messages.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#177Earlier quoted context omitted.
Browsers are sandboxed, and working on the web browsers themselves is a very small niche, as is working on kernels. Software increasingly runs either on dedicated infrastructure or virtual ones; in those cases there isn't really a case where you need to worry about software running on the same host trying to access the data. Sure, it's useful to have some restrictions in place to track what needs access to what resou…
Browsers are sandboxed by the kernel , and we're talking about bugs in the kernel here...
Even if modern browsers lean more on kernel features, initially the sandboxing in browsers is implemented through a managed runtime.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#178Before 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…
> 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.
You are right about that, but even just using sum types eliminates a lot of logic errors, too.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#179Earlier quoted context omitted.
I mentioned XNU below. It doesn’t really count as a microkernel if you, you know, don’t actually use the microkernel part. At least for the 30 years between the FreeBSD collision and the introduction of DriverKit, which does most of its IPC through shared memory (because the mach ports are not efficient enough, I would assume).
Yes, but a lot of other things use Mach messages.
All the major OSes have components of the larger operating system that run in userspace and communicate via IPC, including Linux. But userspace drivers and basic system services (VFS, network stack, etc.) are very limited in their use of userspace/IPC. If macOS is a microkernel in the sense of those built on L4, then so are Windows and Linux, and the word doesn't have any meaning anymore.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#180Earlier quoted context omitted.
> It’s hilarious that you feel the need to preemptively take control of the narrative in anticipation of the Rust people that you fear so much. > Is this an irrational fear, I wonder? Reminds me of methods used in the political discourse. In a sad sort of way, I think its hilarious that hn users have been so completely conditioned to expect rust evangelism any time a topic like this comes up that they wanted to get a…
I don’t think evangelism is necessary anymore. Rust adoption is now a matter of time.
Rust feels a lot like Ruby (fancy/weird with a fanatical user base). Fil-C is a far more practical route to memory safety (a la Python in this analogy).