13 ms·

I'll bite. C++ has quite a few powerful features that Rust doesn't have, including better platform support, but Rust has a lot of things going for it that wou

I'll bite. C++ has quite a few powerful features that Rust doesn't have, including better platform support, but Rust has a lot of things going for it that would make it well suited to kernel development: * no exceptions, and language features and a type system that is set up for explicit error handling - the kernel would need to disable C++ exceptions anyway, making error handling just as cumbersome as in C. * the ML inspired type system helps to write correct code (eg sum types) * the language is not riddled with UB and legacy C support induced cruft. You can opt in to unsafety with `unsafe` blocks, but these can be tightly scoped to where it's necessary and can be especially scrutinized Especially in the context of a kernel, the increased safety guarantees are worth a lot.

majewsky 7y ago
On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. We're still pretty early in Rust's lifecycle, and there is still a lot to be learned about what `unsafe` can really break, especially at-a-distance. The UCG WG is doing this work in [1], but I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. [1] https://github.com/rust-lang/unsafe-code-guidelines https://github.com/rust-lang/unsafe-code-guidelines
- nindalf 7y ago
  In my uninformed opinion, it's fairly simple to write Rust code that's easy to review. Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I think it might be at least half a decade before Rust starts being used in more central parts of the kernel (if at all) because adding a second language significantly complicates the build process. Also, it is blocked on Rust supporting all the platforms that Linux supports just as well. It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms.
  - majewsky 7y ago
    > Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I don't have links at hand, but there were already instances where a bug in an `unsafe` block had effects in completely different (and seemingly random) places. Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. > It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms. Which is why driver modules are a good place to start. Drivers are specific to certain pieces of hardware which are oftentimes only used with CPUs of a specific ISA.
    - masklinn 7y ago
      > Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. unsafe blocks can cause UB period, UB means the program is broken but the UB can manifest anywhere. C or C++ don't make this any better, they just make the entire program into a source of UB.
      - majewsky 7y ago
        Exactly. But many Rust proponents do not communicate that clearly. They often make it sound like unsafe blocks contain the undefined behavior and prevent it from spreading to the rest of the program, which they don't.
        masklinn 7y ago
        That's very true. The value of unsafe blocks is that they restrict the number of places you need to inspect / audit for UBs. They're just places where you're telling the compiler "I know what I'm doing", once an unsafe blocks has created an UB thing can break anywhere.
        renox 7y ago
- StreamBright 7y ago
  If this is true, how come we have this many security bugs?
  - snaky 7y ago
    Security was never high in priority list of Linux kernel development actually.
- moosingin3space 7y ago
  > On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. I believe the kernel core developers are good programmers and good at code reviews. That said, a huge proportion of Linux CVEs are memory-safety problems -- use-after-free, race conditions, out-of-bounds access, etc -- which do not exist in safe Rust. > I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. I can understand this too! It takes time for large communities to change, and the only real research we have on `unsafe` is the RustBelt paper, which demonstrates that the concepts of the borrow checker are sound provided that `unsafe` code respects its invariants. The way this framework has been pitched, though, is for building optional modules. If everyone takes this seriously, I think it'll result in wins all around -- Linux benefits from memory-safety improvements, Rust benefits from kernel developers' experience, and the world benefits from having more secure code running in ring-0. I'm looking forward to this.

majewsky 7y ago

On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. We're still pretty early in Rust's lifecycle, and there is still a lot to be learned about what `unsafe` can really break, especially at-a-distance. The UCG WG is doing this work in [1], but I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. [1] https://github.com/rust-lang/unsafe-code-guidelines https://github.com/rust-lang/unsafe-code-guidelines

nindalf 7y ago
In my uninformed opinion, it's fairly simple to write Rust code that's easy to review. Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I think it might be at least half a decade before Rust starts being used in more central parts of the kernel (if at all) because adding a second language significantly complicates the build process. Also, it is blocked on Rust supporting all the platforms that Linux supports just as well. It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms.
- majewsky 7y ago
  > Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I don't have links at hand, but there were already instances where a bug in an `unsafe` block had effects in completely different (and seemingly random) places. Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. > It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms. Which is why driver modules are a good place to start. Drivers are specific to certain pieces of hardware which are oftentimes only used with CPUs of a specific ISA.
  - masklinn 7y ago
    > Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. unsafe blocks can cause UB period, UB means the program is broken but the UB can manifest anywhere. C or C++ don't make this any better, they just make the entire program into a source of UB.
    - majewsky 7y ago
      Exactly. But many Rust proponents do not communicate that clearly. They often make it sound like unsafe blocks contain the undefined behavior and prevent it from spreading to the rest of the program, which they don't.
      - masklinn 7y ago
        That's very true. The value of unsafe blocks is that they restrict the number of places you need to inspect / audit for UBs. They're just places where you're telling the compiler "I know what I'm doing", once an unsafe blocks has created an UB thing can break anywhere.
        renox 7y ago
StreamBright 7y ago
If this is true, how come we have this many security bugs?
- snaky 7y ago
  Security was never high in priority list of Linux kernel development actually.
moosingin3space 7y ago
> On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. I believe the kernel core developers are good programmers and good at code reviews. That said, a huge proportion of Linux CVEs are memory-safety problems -- use-after-free, race conditions, out-of-bounds access, etc -- which do not exist in safe Rust. > I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. I can understand this too! It takes time for large communities to change, and the only real research we have on `unsafe` is the RustBelt paper, which demonstrates that the concepts of the borrow checker are sound provided that `unsafe` code respects its invariants. The way this framework has been pitched, though, is for building optional modules. If everyone takes this seriously, I think it'll result in wins all around -- Linux benefits from memory-safety improvements, Rust benefits from kernel developers' experience, and the world benefits from having more secure code running in ring-0. I'm looking forward to this.