3 ms·

Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if t

Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe. Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors. And unsafe in Rust is so difficult that many library authors throw their hands up, use Miri, and hope for the best. Even though Miri, all respect to it, has bugs, probability-based testing and other limitations and issues. UB in both user library and standard library: https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...

kllrnohj 4mo ago
> Nor if one of the soundness holes in the Rust programming language itself is encountered. imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.
- chilljinx 4mo ago
  Which definition of UB are you using regarding that? Behavior changing based on configuration does not seem like UB, at least if none of the configurations allow for UB.
- afdbcreid 4mo ago
  You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.
  - Groxx 4mo ago
    Supporting evidence for this: https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
  - kllrnohj 4mo ago
    No, that's exactly what I'm aware of, and is exactly the wrong behavior I'm talking about. "Sometimes crashes, sometimes two's compliment" are extremely different behaviors, and not meaningfully different from just saying it's UB. It should always panic, with no way to disable it. The wrap around in release mode is simply bad behavior. It can't be relied upon (because it panics in debug), and it's not useful behavior for nearly anyone's logic (wrap around almost never is logically correct behavior) It lets Rust claim to be UB free without delivering the actual value of being UB free. You still can't rely on a given behavior because it doesn't have one behavior, it has two, and the two behaviors are wildly incompatible with each other.
    - steveklabnik 4mo ago
      > and not meaningfully different from just saying it's UB. It is extremely meaningfully different, because the range of options of what can happen is bounded in one case (either two's compliment wrapping, or panic) and unbounded in the other case (literally anything is allowed to happen, including time travel). This is "implementation defined behavior" in C and C++'s terms, not "undefined behavior."
    - Dylan16807 4mo ago
      If you want guaranteed wrapping or panic you can choose one and then rely on it just fine. The default behavior helps you avoid wrapping without permanently bogging down your performance. It makes sense as an option.
    - Groxx 4mo ago
      It's surprising and potentially buggy behavior, but that's very different from undefined behavior. To such a degree that I think you honestly might not understand what it means, and what the risks are around undefined behavior, especially in the presence of an optimizing compiler. As a starter / refresher perhaps, both of these are perfectly permissible and happen in practice with UB, but never with "wrap or panic" / "implementation defined" behavior: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-In-Action/ https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-... This kind of thing is an example of the "time travel" stevekablanik is referring to, stuff that is literally impossible as written, that absolutely no human would consider to be a reasonable execution of the code, but occurs regularly with UB.
slopinthebag 4mo ago
> The fix for this bug is included in Rust 1.87.0 Am I missing something?
afdbcreid 4mo ago
> Unsafe is not necessary to trigger UB in case no_std is used I have no idea what are you talking about, no_std is just completely irrelevant here. > Nor if one of the soundness holes in the Rust programming language itself is encountered Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them. And this is also noted in a footnote. > Nor if there is UB in one of the libraries used as a dependency by the library you are using If we treat a Rust program globally, this is kinda true. A more true statement will be that UB cannot happen without unsafe code somewhere, including in dependencies (and the original statement can be interpreted as saying that). But the true power of unsafe is that it's local. If you've reviewed a library and its unsafe is sound, you can ignore it for the rest of the calculation. And of course, the more people review a library the more likely it is that it is sound. > Which has happened many times, since the Rust standard library is full of unsafe And here again the post's point stands: many CVEs in std are artificial, you can't exploit them without writing a program that is meant to be exploited. Such thing will never be a CVE in C/C++'s std. > Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors. That is true, that is in fact the post's point: that if they fail this, a CVE will be filled, even if exploitation is just not possible realistically. But there is a very simple solution for library authors: don't write unsafe code! You don't need to, the vast majority of times. And if you do not have the knowledge (which indeed is more complicated than in C/C++) how to not have an unsound API, then you just should not write unsafe code.
- chilljinx 4mo ago
  [flagged]
  - afdbcreid 4mo ago
    What? Absolutely not. May you explain why no_std is relevant?
  - pitaj 4mo ago
    Explain how it is relevant
Groxx 4mo ago
I'm caught somewhere between interpreting this as "C is all we need. git gud" and "rust hurt me and I'm still mad" and I'm struggling to see any other option. It's an unfocused rant that seems keyed off "rust" and little else. In broad strokes it's correct, this stuff happens and it's hard to be correct all the time. But are you trying to make a point? Or just ranting? Also that linked issue was considered a CVE and is fixed (as the article says).
- chilljinx 4mo ago
  [flagged]
  - fluffybucktsnek 4mo ago
    No, they are asking for clarification.
- IcyWindows 4mo ago
  I see his reply as "people say Rust is safe, but Rust just pushes it under a rug and pretends it's safe when it's still all there - just in a dependency"
sunshowers 4mo ago
If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe https://oxide.computer/blog/iddqd-unsafe I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).
- reallyinchaos 4mo ago
  [flagged]
  - sunshowers 4mo ago
    I'm a huge fan of Rust! I like to think my writing makes the Rust community better more than it annoys people :)
    - reallyinchaos 4mo ago
      [dead]
- aapoalas 4mo ago
  Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!
  - sunshowers 4mo ago
    Mostly chatted with some people and figured it out with their help.
  - sunshowers 4mo ago
    Updated https://oxide.computer/blog/iddqd-unsafe#what-about-formal-methods https://oxide.computer/blog/iddqd-unsafe#what-about-formal-m... with some notes.

kllrnohj 4mo ago

> Nor if one of the soundness holes in the Rust programming language itself is encountered. imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.

chilljinx 4mo ago
Which definition of UB are you using regarding that? Behavior changing based on configuration does not seem like UB, at least if none of the configurations allow for UB.
afdbcreid 4mo ago
You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.
- Groxx 4mo ago
  Supporting evidence for this: https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
- kllrnohj 4mo ago
  No, that's exactly what I'm aware of, and is exactly the wrong behavior I'm talking about. "Sometimes crashes, sometimes two's compliment" are extremely different behaviors, and not meaningfully different from just saying it's UB. It should always panic, with no way to disable it. The wrap around in release mode is simply bad behavior. It can't be relied upon (because it panics in debug), and it's not useful behavior for nearly anyone's logic (wrap around almost never is logically correct behavior) It lets Rust claim to be UB free without delivering the actual value of being UB free. You still can't rely on a given behavior because it doesn't have one behavior, it has two, and the two behaviors are wildly incompatible with each other.
  - steveklabnik 4mo ago
    > and not meaningfully different from just saying it's UB. It is extremely meaningfully different, because the range of options of what can happen is bounded in one case (either two's compliment wrapping, or panic) and unbounded in the other case (literally anything is allowed to happen, including time travel). This is "implementation defined behavior" in C and C++'s terms, not "undefined behavior."
  - Dylan16807 4mo ago
    If you want guaranteed wrapping or panic you can choose one and then rely on it just fine. The default behavior helps you avoid wrapping without permanently bogging down your performance. It makes sense as an option.
  - Groxx 4mo ago
    It's surprising and potentially buggy behavior, but that's very different from undefined behavior. To such a degree that I think you honestly might not understand what it means, and what the risks are around undefined behavior, especially in the presence of an optimizing compiler. As a starter / refresher perhaps, both of these are perfectly permissible and happen in practice with UB, but never with "wrap or panic" / "implementation defined" behavior: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-In-Action/ https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-... This kind of thing is an example of the "time travel" stevekablanik is referring to, stuff that is literally impossible as written, that absolutely no human would consider to be a reasonable execution of the code, but occurs regularly with UB.

slopinthebag 4mo ago

> The fix for this bug is included in Rust 1.87.0 Am I missing something?

afdbcreid 4mo ago

> Unsafe is not necessary to trigger UB in case no_std is used I have no idea what are you talking about, no_std is just completely irrelevant here. > Nor if one of the soundness holes in the Rust programming language itself is encountered Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them. And this is also noted in a footnote. > Nor if there is UB in one of the libraries used as a dependency by the library you are using If we treat a Rust program globally, this is kinda true. A more true statement will be that UB cannot happen without unsafe code somewhere, including in dependencies (and the original statement can be interpreted as saying that). But the true power of unsafe is that it's local. If you've reviewed a library and its unsafe is sound, you can ignore it for the rest of the calculation. And of course, the more people review a library the more likely it is that it is sound. > Which has happened many times, since the Rust standard library is full of unsafe And here again the post's point stands: many CVEs in std are artificial, you can't exploit them without writing a program that is meant to be exploited. Such thing will never be a CVE in C/C++'s std. > Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors. That is true, that is in fact the post's point: that if they fail this, a CVE will be filled, even if exploitation is just not possible realistically. But there is a very simple solution for library authors: don't write unsafe code! You don't need to, the vast majority of times. And if you do not have the knowledge (which indeed is more complicated than in C/C++) how to not have an unsound API, then you just should not write unsafe code.

chilljinx 4mo ago
[flagged]
- afdbcreid 4mo ago
  What? Absolutely not. May you explain why no_std is relevant?
- pitaj 4mo ago
  Explain how it is relevant

Groxx 4mo ago

I'm caught somewhere between interpreting this as "C is all we need. git gud" and "rust hurt me and I'm still mad" and I'm struggling to see any other option. It's an unfocused rant that seems keyed off "rust" and little else. In broad strokes it's correct, this stuff happens and it's hard to be correct all the time. But are you trying to make a point? Or just ranting? Also that linked issue was considered a CVE and is fixed (as the article says).

chilljinx 4mo ago
[flagged]
- fluffybucktsnek 4mo ago
  No, they are asking for clarification.
IcyWindows 4mo ago
I see his reply as "people say Rust is safe, but Rust just pushes it under a rug and pretends it's safe when it's still all there - just in a dependency"

sunshowers 4mo ago

If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe https://oxide.computer/blog/iddqd-unsafe I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).

reallyinchaos 4mo ago
[flagged]
- sunshowers 4mo ago
  I'm a huge fan of Rust! I like to think my writing makes the Rust community better more than it annoys people :)
  - reallyinchaos 4mo ago
    [dead]
aapoalas 4mo ago
Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!
- sunshowers 4mo ago
  Mostly chatted with some people and figured it out with their help.
- sunshowers 4mo ago
  Updated https://oxide.computer/blog/iddqd-unsafe#what-about-formal-methods https://oxide.computer/blog/iddqd-unsafe#what-about-formal-m... with some notes.