4 ms·

First Rust code shows up in the Windows 11 kernel

20 points by fork-bomber 3y ago

MuffinFlavored 3y ago
It'd be pretty to see like, with all of its borrow checking + memory safety features, how much unsafe {} were the people who worked on this able to avoid and can/will it still crash?
- mr_00ff00 3y ago
  Unsafe lines for sure would be great to see. If you use mostly unsafe, at that point you might as well use any systems language and wouldn’t expect a CVE decrease really. # of safe lines is key
  - von_lohengramm 3y ago
    What's more important the amount of `unsafe` is if it's sound `unsafe`. The problem with `unsafe` is that it's even harder to write correctly than it is to write sound C/C++/Zig/etc. The thing about Undefined Behavior is that it gives the compiler free reins to introduce bugs anywhere in the program, safe or `unsafe`, and the thing about Rust is that it has much stricter rules about what is well-defined than most languages fraught with UB. And due to the nature of UB, these bugs may not appear until the function with unsound `unsafe` is called in a specific context, or you update your compiler, or you add a new dependency, or you add a line of code in a different file, or you delete a line of code in a different file, etc.. There are nearly infinite things that can set off the nasal demons you've given home to in your "mostly safe" Rust codebase. Here[0]'s an article talking about just this. [0]: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
    - firstlink 3y ago
      > it's even harder to write correctly than it is to write sound C/C++/Zig/etc I have said very similar things in the past but I am beginning to realize that, just like with "zero-cost abstractions", this wording is highly misleading. Unsafe rust as a whole is easier to write correctly than, just to pick on the worst offender, C++. C++ has tons of footguns, like invisible effectful copy constructors and move constructors which must not invalidate their source and so on. Rust's strong type-safety features help rust avoid these kinds of issues, in all of the mentioned languages. What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! Now one can argue about the implication of the language rules changing, but the changes have somewhat tapered off in the past few years.
      - von_lohengramm 3y ago
        I wasn't trying to argue that C/C++/Zig/etc. would be a better or safer choice than Rust. All in all, the less surface area that you have for bugs, the better, and Rust does an exceptional job at this. However, I just dislike attempts to quantify "unsafety" by thinking in terms of # of `unsafe` lines. I would rather take 1,000 trivial `unsafe ` lines than a single `unsafe` line that plays too close to the edge between what's allowed and what's not. > To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat. In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though. > What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?" But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately... > Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there. [0]: https://doc.rust-lang.org/nomicon/index.html https://doc.rust-lang.org/nomicon/index.html
  - pornel 3y ago
    I don't think that's a given, unless you're talking about an untouched dump of c2rust code. In Rust even when using lots of unsafe, it's usually possible to compartmentalize/modularize it and build safer, harder-to-misuse interfaces on top of the unsafe code. With this you can test and fuzz one tricky thing at a time, instead of having to prove safety of the combined product. Plus Rust has other features that help with software reliability, like sum types with pattern matching, which are used to make non-nullable types and mandatory error handling, top-notch compiler warnings and lints, and types to describe thread safety. Check out Redox OS — it has lots of unsafe blocks, but mostly safe interfaces between them. Same in Rust for Linux — they're building higher-level building blocks for all the unsafe primitives that Linux requires.
  - firstlink 3y ago
    > If you use mostly unsafe, at that point you might as well use any systems language and wouldn’t expect a CVE decrease really. Most systems languages that are actually being used out there in the wild have weak type systems that must be thrown away at a moment's notice. C++ is a notable exception but it is a very complex language where errors can be extraordinarily subtle compared to other systems languages: This is the main reason people still use C even though it is essentially not type-safe at all. Unsafe rust avoids both of these pitfalls: unsafe rust is just as type-safe as safe rust, and it has RAII without C++'s strategic arsenal of footguns.
kinghajj 3y ago
This might make me finally upgrade to Windows 11.

20 points by fork-bomber 3y ago

It'd be pretty to see like, with all of its borrow checking + memory safety features, how much unsafe {} were the people who worked on this able to avoid and can/will it still crash?

mr_00ff00 3y ago
Unsafe lines for sure would be great to see. If you use mostly unsafe, at that point you might as well use any systems language and wouldn’t expect a CVE decrease really. # of safe lines is key
- von_lohengramm 3y ago
  What's more important the amount of `unsafe` is if it's sound `unsafe`. The problem with `unsafe` is that it's even harder to write correctly than it is to write sound C/C++/Zig/etc. The thing about Undefined Behavior is that it gives the compiler free reins to introduce bugs anywhere in the program, safe or `unsafe`, and the thing about Rust is that it has much stricter rules about what is well-defined than most languages fraught with UB. And due to the nature of UB, these bugs may not appear until the function with unsound `unsafe` is called in a specific context, or you update your compiler, or you add a new dependency, or you add a line of code in a different file, or you delete a line of code in a different file, etc.. There are nearly infinite things that can set off the nasal demons you've given home to in your "mostly safe" Rust codebase. Here[0]'s an article talking about just this. [0]: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
  - firstlink 3y ago
    > it's even harder to write correctly than it is to write sound C/C++/Zig/etc I have said very similar things in the past but I am beginning to realize that, just like with "zero-cost abstractions", this wording is highly misleading. Unsafe rust as a whole is easier to write correctly than, just to pick on the worst offender, C++. C++ has tons of footguns, like invisible effectful copy constructors and move constructors which must not invalidate their source and so on. Rust's strong type-safety features help rust avoid these kinds of issues, in all of the mentioned languages. What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! Now one can argue about the implication of the language rules changing, but the changes have somewhat tapered off in the past few years.
    - von_lohengramm 3y ago
      I wasn't trying to argue that C/C++/Zig/etc. would be a better or safer choice than Rust. All in all, the less surface area that you have for bugs, the better, and Rust does an exceptional job at this. However, I just dislike attempts to quantify "unsafety" by thinking in terms of # of `unsafe` lines. I would rather take 1,000 trivial `unsafe ` lines than a single `unsafe` line that plays too close to the edge between what's allowed and what's not. > To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat. In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though. > What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?" But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately... > Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there. [0]: https://doc.rust-lang.org/nomicon/index.html https://doc.rust-lang.org/nomicon/index.html
- pornel 3y ago
  I don't think that's a given, unless you're talking about an untouched dump of c2rust code. In Rust even when using lots of unsafe, it's usually possible to compartmentalize/modularize it and build safer, harder-to-misuse interfaces on top of the unsafe code. With this you can test and fuzz one tricky thing at a time, instead of having to prove safety of the combined product. Plus Rust has other features that help with software reliability, like sum types with pattern matching, which are used to make non-nullable types and mandatory error handling, top-notch compiler warnings and lints, and types to describe thread safety. Check out Redox OS — it has lots of unsafe blocks, but mostly safe interfaces between them. Same in Rust for Linux — they're building higher-level building blocks for all the unsafe primitives that Linux requires.
- firstlink 3y ago
  > If you use mostly unsafe, at that point you might as well use any systems language and wouldn’t expect a CVE decrease really. Most systems languages that are actually being used out there in the wild have weak type systems that must be thrown away at a moment's notice. C++ is a notable exception but it is a very complex language where errors can be extraordinarily subtle compared to other systems languages: This is the main reason people still use C even though it is essentially not type-safe at all. Unsafe rust avoids both of these pitfalls: unsafe rust is just as type-safe as safe rust, and it has RAII without C++'s strategic arsenal of footguns.

kinghajj 3y ago

This might make me finally upgrade to Windows 11.