3 ms·

> They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them. ... kernel maintainers (and maintainers of many ot

by dcow 6y ago

> They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them. ... kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands ...code going into the kernel is often not as well reviewed as we like to think. Sounds like there’s some room for improvement in the process of how lighter weight contributions are introduced, reviewed, and land in the kernel. Perhaps there is a technical solution that would help ease the load off maintainers and shift some of the burden to patch authors. — When I find myself in times of trouble / mother Mozilla speaks to me / whisper words of wisdom / don't use C. And in my hour of darkness / Rust is installed in my system tree / emitting tokens of wisdom / don't use C. And then the broken hearted people / maintaining kernel code agree / Rust's safety is the answer / don't use C. For though they may be parted / Rust will prevent Use After Fee / they will see the answer / don't use C. And when the code is cloudy / the borrow checker confronts me / thou shall specify reference lifetimes / don't use C. I wake up to the sound of safe code / not one vuln surrounding me / rust is in the kernel / no more C.

azinman2 6y ago
Rust doesn’t magically make your code bug free. The fixes/bugs you reference are highly unlikely to be all memory management related (eg use-after-free), and you can still do unsafe things in Rust even with memory.
- dcow 6y ago
  Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable. Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction. Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative. The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!
- operator-name 6y ago
  Rust and other languages with strong type systems don't magically make your code bug free but their type systems are more expressive. If used correctly this can make all sorts of states unwanted program states unrepresentable. Rust's shining feature is its linear types but that doesn't mean the only kinds of bugs it eliminates are memory management related.

by dcow 6y ago

azinman2 6y ago

Rust doesn’t magically make your code bug free. The fixes/bugs you reference are highly unlikely to be all memory management related (eg use-after-free), and you can still do unsafe things in Rust even with memory.

dcow 6y ago
Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable. Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction. Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative. The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!
operator-name 6y ago
Rust and other languages with strong type systems don't magically make your code bug free but their type systems are more expressive. If used correctly this can make all sorts of states unwanted program states unrepresentable. Rust's shining feature is its linear types but that doesn't mean the only kinds of bugs it eliminates are memory management related.