A bug is a piece of code that doesn't agree with requirements or architecture. The misalignment can not be attributed to code alone.
Kernel bugs hide for 2 years on average. Some hide for 20
61–70 of 186 posts
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#62Before 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…
No other top-level comments have since mentioned Rust[1] and TFA mentions neither Rust nor topics like memory safety. It’s just plain bugs.
The Rust phantom zealotry is unfortunately real.
[1] Aha, but the chilling effect of dismissing RIR comments before they are even posted...
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#63grsecurity project has fixed many security bugs but did not contribute back, as they're profiting from selling the patchset. It's not uncommon for the bugs they found to be rediscovered 6-7 years later. https://xcancel.com/spendergrsec
> as they're profiting from selling the patchset
Profiting from selling their patchset is not the whole story, though. grsec was public and free for a long time and there were many effects at play preventing the kernel from adopting it.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#64Millions of lines of code, all running in supervisor mode. One bug is all it takes to compromise the entire system. The monolithic UNIX kernel was a good design in the 60s; Today, we should know better[0][1]. 0. https://sel4.systems/ 1. https://genode.org/
How are SEL4 and Genode going for you in your day-to-day compute usage?
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#65[flagged]
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#66Before 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’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.
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#67Only tangentially related but maybe someone here can help me.
I have a server which has many peripherals and multiple GPUs. Now, I can use vfio and vfio-pcio to memory map and access their registers in user space. My question is, how could I start with kernel driver development? And I specifically mean the dev setup.
Would it be a good idea to use vfio with or without a vm to write and test drivers? How to best debug, reload and test changing some code of an existing driver?
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#68Before 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…
You're fighting air
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#69Earlier quoted context omitted.
> 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.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it a…
Maybe increase as a ratio, but not absolute. There are various benefits of Rust that affect other classes of issues: fancy enums, better errors, ability to control overflow behaviour and others. But for actual experience, check out what the kernel code developer has to say: https://xcancel.com/linaasahi/status/1577667445719912450
Re: Kernel bugs hide for 2 years on average. Some hide for 20
#70Before 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%.