1. 8
  1. 1

    Memory-unsafety mitigations are interesting, but I think unsafe Rust is probably not the main reason. Lots of programs contain a little unsafe Rust and an enormous amount of relatively unsafe C(++), and sometimes a mitigation can make it harder to, say, hijack control flow in safe code due to a wild write from the unsafe code. Rust already supports, for example, Windows’ control flow integrity for that reason. In general, I’d expect mitigations to get picked up in Rust if they’re especially beneficial in mixed safe/unsafe code like that or they’re simply really cheap.

    It’s not contradicted by the post, but bears repeating that Rust calls it a bug any time you can invent a way to write actually-unsafe ‘safe’ code (like here), not only when typical code is impacted. And even this legitimately spicy stdlib bug (via this ref in the post) would need you to make the target binary do something very specific (shrink a VecDeque’s reserved capacity by 1) as the first step of an exploit. Worth being aware of, but we shouldn’t confuse it with the routine discovery of memory unsafety (and exploits) in environments where the defaults are less safe.

    1. 3

      It’s not contradicted by the post, but bears repeating that Rust calls it a bug any time you can invent a way to write actually-unsafe ‘safe’ code (like here), not only when typical code is impacted. And even this legitimately spicy stdlib bug (via this ref in the post) would need you to make the target binary do something very specific (shrink a VecDeque’s reserved capacity by 1) as the first step of an exploit. Worth being aware of, but we shouldn’t confuse it with the routine discovery of memory unsafety (and exploits) in environments where the defaults are less safe.

      This is by the way what is called a soundness issue. https://docs.rs/dtolnay/0.0.9/dtolnay/macro._03__soundness_bugs.html

      Soundness issues are exempt from Rusts API stability guarantees and will be fixed.

      1. 1

        Yes, I wanted to describe it for folks not already familiar, but should have used the word “soundness” too.

        (Further confusing things, I wanted to mention both the VecDeque segfault, which is more like a run-of-the-mill concrete behavior bug, and things like the scoped situation where you’d practically have to try to trigger it and you primarily care because of the soundness implications, since the linked post refers to both sorts of problem.)

      2. 2

        Yes, Rust takes pride in soundness of the safety, so anything that even theoretically allows bypassing it is treated as a bug.

        When there was an uproar about Actix-web’s cavalier use of unsafe, one of the contentious issues was an unsound internal interface that didn’t enforce aliasing rules. People were filing bugs that “it could be used unsafely” and author responded “but it isn’t”.

        It’s very different from C/C++ where the bar is what the code actually does, and it’s accepted that if you write bad code, you get bad results.