9 ms·

It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely comp

It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages? Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3]. [1] -- https://code.videolan.org/videolan/dav1d https://code.videolan.org/videolan/dav1d [2] -- https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif [3] -- https://github.com/AOMediaCodec/libiamf https://github.com/AOMediaCodec/libiamf Yep. Keep writing these in C; surely nothing will go wrong.

Patrickmi 3y ago
[dead]
masklinn 3y ago
We all know that’s The Price Of Freedom. As they say, “give me exploitable trivial memory safety bugs or give me authoritarian dystopia” (https://news.ycombinator.com/item?id=27638940 https://news.ycombinator.com/item?id=27638940).
- ignoramous 3y ago
  Dystopia? Given a choice, you'd rather trust a compiler than a human given the billions already lost to buffer overflows, read after free, and other memory related bugs, surely?
EustassKid 3y ago
Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?
- LoganDark 3y ago
  ...What is a "safe C compiler"?
  - deusum 3y ago
    ...a textbook oxymoron?
  - ReptileMan 3y ago
    Check on the fiction section sir. Here is the CS one. Although I think all the C compilers are safe ish lately. I haven't seen exploits that target defects in output. Usually the error is ID10T located in the prekeyboard device.
  - littlestymaar 3y ago
    rustc /s
  - adrian_b 3y ago
    All decent C compilers have compilation options so that at run-time any undefined actions, including integer overflow and out-of-bounds accesses, will be trapped. The only problem is that these options are not the default and most C developers do not use them, especially for release versions. I always use them, including for releases. In the relatively rare cases when this has a performance impact, I disable the sanitize options only for the functions where this matters and only after an analysis that guarantees that events like overflows or out-of-bounds accesses cannot happen. Despite the hype, by default Rust is not safer than C compiled with the right options, because the default for Rust releases is also to omit many run-time checks. Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. For now, when safety is desired, both C and Rust must be compiled with non-default options.
    - planede 3y ago
      Do you release with `-fsanitize=address` or what?
    - 3y ago
WD40forRust 3y ago
[dead]
tannhaeuser 3y ago
[flagged]
- Ar-Curunir 3y ago
  Completely untrue. Servo was from the start a research project, but even then, big components like webrender and stylo are now parts of Firefox, and there's a whole list more here: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation
  - tannhaeuser 3y ago
    What is completely untrue? When the Rust team was let go in 2020, only a very minor part of Servo (Stylo) delivered and became part of FF according to [1]. Yet the Rust core team, already notorious for lone language decisions, engaged in what amounted to an epic risk of a publicity catastrophe for Mozilla. And even in their post mortem in [1], they care more about progressing Rust than about their employer or the (much more important) work they were paid for. [1]: https://news.ycombinator.com/item?id=24143819 https://news.ycombinator.com/item?id=24143819
    - steveklabnik 3y ago
      9.6% of Firefox is Rust as of today https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ That is 3.4 million lines. And frankly I am upset by the way you characterize my post there. First of all, as I said, it was in a personal capacity, not a statement from the team. Second, as I was not employed by Mozilla at the time, of course I care more about Rust than I do Mozilla. However, that does not mean that I did not care for those who were let go, we were all very upset at how unfortunate the situation was. And the broader community stepped up and hired everyone, as far as I know. And also language like "already notorious for lone language decisions," that is how both the Rust project and Mozilla wanted it! They actively did not control language decisions, even when Rust was small enough that the only folks who worked on it were at Mozilla. Nobody wanted Rust to be a single vendor technology, because of the exact risk of the situation that came to pass. Imagine if Rust were 100% Mozilla at that time, and they abandoned it. Instead of it being a bump in Rust's development, it would have been a catastrophe. And, your original post: "the entire fsking Rust team." Again, Mozilla employed a very small number of people that made up the overall team. Yes, they were critical people, who did a lot of important work, but "fired the entire team" is straightforwardly inaccurate.
lightedman 3y ago
If you think Rust is entirely memory-safe, I've got a bridge in Brooklyn to sell you. Man can make it, man can break it.
- quickthrower2 3y ago
  Does it have to be? Riding a bicycle with a helmet isn’t entirely safe, but I still prefer to wear one.
- acdha 3y ago
  That’s like saying we shouldn’t wear seatbelts or have airbags and antilock brakes because you can still die in a crash. If anything, that’s still underselling it: there are entire categories of bug which are widespread even in well-tested, heavily-fuzzed C codebases like Chrome but would not be likely or often possible in Rust.
lifthrasiir 3y ago
We don't have a very good mainstream [1] solution for critical and performance-hungry applications. I do think that they are limited in number (many applications are not that performance-hungry) and Rust is already good enough, but those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added. This particular bug could have been reasoned once you know where to look at, after all. [1] In my definition, this translates to "as popular and user-friendly as sanitizers".
- bennettnate5 3y ago
  > those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added There are actually already tools built for this very purpose in Rust (see Kani [1] for instance). Formal verification has a serious scaling problem, so forming programs in such a way that there are a few performance-critical areas that use unsafe routines seems like the best route. I feel like Rust leans into this paradigm with `unsafe` blocks. [1] - https://github.com/model-checking/kani https://github.com/model-checking/kani
  - lifthrasiir 3y ago
    Yeah, I'm aware of Kani, but it is not optimal for many reasons, including but not limited: hard to install in some cases, loop unrolling is mandatory and does not scale in general (this is a main issue with bounded model checkers, not just Kani), and hard to give hints for efficient verification and/or harness generation. And Kani makes use of CMBC, which is a model checker for C/C++, so Rust is not even special in this regard.
- irundebian 3y ago
  It should be possible with Ada/SPARK. It's focused on low level systems programming and compilable programs are free from run-time errors. In addition, the correctness of the program or key properties can be proven at compile-time.
- ignoramous 3y ago
  > "as popular and user-friendly as sanitizers" solution for critical and performance-hungry applications. Google just did enable Memory Tagging Extension (ARM's hardware accelerated sanitizers) on the Pixels last year. May be sanitizing ISAs offer hope?
alexvitkov 3y ago
We still don't have an alternative. No, you can't use Arc<HashMap<Whatever>> in the middle of a decoder routine. Some software to actually has to perform well.
- lifthrasiir 3y ago
  In this particular case Rust could have helped, because the table construction can use a normal Rust while the tight decoder loop can remain `unsafe` which can be justified more easily. But I demand more than the human-readable justification.
  - alexvitkov 3y ago
    What Rust brings to the table is static enforcement of its ownership rules, that's it. How does Rust deal with buffer overflows? Bounds checking. What an innovative solution, congratulations to the Rust people for this groundbreaking innovation. And they keep acting like they've fucking discovered hot water.
    - lifthrasiir 3y ago
      Rust is novel because it bundles lots of existing ideas into one usable package. Even the borrow checking is not new, it's adapted and improved from research languages like Cyclone.
    - delfinom 3y ago
      Yea but did anyone else market hot water first? I think not!
    - insanitybit 3y ago
      No one is saying that bounds checking is novel. It's really C and C++ that are novel, in that they are the only languages where bounds checking is not the default. But if you're having the "memory safe replacement for C/C++" conversation it shouldn't surprise you that people bring up Rust.
cookiengineer 3y ago
Stagefright was the point when I started to tell people to use a safe programming language. When they ask "Which one?" I am answering "I don't care, as long as it's a programming language that uses a VM". Every time I hear the discussions about how fast and perfect C is, people seem to miss the point that new programming languages try to avoid complexity, because they were using C/C++ themselves in the past and they fell on their noses more than once. It's not about what is faster. It is about how often you make mistakes, statistically. And chances are you make dozens of mistakes per day in C that you will never be aware of, whereas in other memory constrained languages they have hundreds of mechanisms implemented to catch those common mistakes.
- Filligree 3y ago
  You should allow Rust as well, at least.
  - cookiengineer 3y ago
    Yeah ofc. My view on programming languages is that both Rust and golang try to use VM methodologies wherever possible when it comes to memory safety and ownership. They just try to do as much as possible ahead of compile time rather than execution time.

Patrickmi 3y ago

[dead]

masklinn 3y ago

We all know that’s The Price Of Freedom. As they say, “give me exploitable trivial memory safety bugs or give me authoritarian dystopia” (https://news.ycombinator.com/item?id=27638940 https://news.ycombinator.com/item?id=27638940).

ignoramous 3y ago
Dystopia? Given a choice, you'd rather trust a compiler than a human given the billions already lost to buffer overflows, read after free, and other memory related bugs, surely?

EustassKid 3y ago

Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?

LoganDark 3y ago
...What is a "safe C compiler"?
- deusum 3y ago
  ...a textbook oxymoron?
- ReptileMan 3y ago
  Check on the fiction section sir. Here is the CS one. Although I think all the C compilers are safe ish lately. I haven't seen exploits that target defects in output. Usually the error is ID10T located in the prekeyboard device.
- littlestymaar 3y ago
  rustc /s
- adrian_b 3y ago
  All decent C compilers have compilation options so that at run-time any undefined actions, including integer overflow and out-of-bounds accesses, will be trapped. The only problem is that these options are not the default and most C developers do not use them, especially for release versions. I always use them, including for releases. In the relatively rare cases when this has a performance impact, I disable the sanitize options only for the functions where this matters and only after an analysis that guarantees that events like overflows or out-of-bounds accesses cannot happen. Despite the hype, by default Rust is not safer than C compiled with the right options, because the default for Rust releases is also to omit many run-time checks. Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. For now, when safety is desired, both C and Rust must be compiled with non-default options.
  - planede 3y ago
    Do you release with `-fsanitize=address` or what?
  - 3y ago

WD40forRust 3y ago

[dead]

tannhaeuser 3y ago

[flagged]

Ar-Curunir 3y ago
Completely untrue. Servo was from the start a research project, but even then, big components like webrender and stylo are now parts of Firefox, and there's a whole list more here: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation
- tannhaeuser 3y ago
  What is completely untrue? When the Rust team was let go in 2020, only a very minor part of Servo (Stylo) delivered and became part of FF according to [1]. Yet the Rust core team, already notorious for lone language decisions, engaged in what amounted to an epic risk of a publicity catastrophe for Mozilla. And even in their post mortem in [1], they care more about progressing Rust than about their employer or the (much more important) work they were paid for. [1]: https://news.ycombinator.com/item?id=24143819 https://news.ycombinator.com/item?id=24143819
  - steveklabnik 3y ago
    9.6% of Firefox is Rust as of today https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ That is 3.4 million lines. And frankly I am upset by the way you characterize my post there. First of all, as I said, it was in a personal capacity, not a statement from the team. Second, as I was not employed by Mozilla at the time, of course I care more about Rust than I do Mozilla. However, that does not mean that I did not care for those who were let go, we were all very upset at how unfortunate the situation was. And the broader community stepped up and hired everyone, as far as I know. And also language like "already notorious for lone language decisions," that is how both the Rust project and Mozilla wanted it! They actively did not control language decisions, even when Rust was small enough that the only folks who worked on it were at Mozilla. Nobody wanted Rust to be a single vendor technology, because of the exact risk of the situation that came to pass. Imagine if Rust were 100% Mozilla at that time, and they abandoned it. Instead of it being a bump in Rust's development, it would have been a catastrophe. And, your original post: "the entire fsking Rust team." Again, Mozilla employed a very small number of people that made up the overall team. Yes, they were critical people, who did a lot of important work, but "fired the entire team" is straightforwardly inaccurate.

lightedman 3y ago

If you think Rust is entirely memory-safe, I've got a bridge in Brooklyn to sell you. Man can make it, man can break it.

quickthrower2 3y ago
Does it have to be? Riding a bicycle with a helmet isn’t entirely safe, but I still prefer to wear one.
acdha 3y ago
That’s like saying we shouldn’t wear seatbelts or have airbags and antilock brakes because you can still die in a crash. If anything, that’s still underselling it: there are entire categories of bug which are widespread even in well-tested, heavily-fuzzed C codebases like Chrome but would not be likely or often possible in Rust.

lifthrasiir 3y ago

We don't have a very good mainstream [1] solution for critical and performance-hungry applications. I do think that they are limited in number (many applications are not that performance-hungry) and Rust is already good enough, but those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added. This particular bug could have been reasoned once you know where to look at, after all. [1] In my definition, this translates to "as popular and user-friendly as sanitizers".

bennettnate5 3y ago
> those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added There are actually already tools built for this very purpose in Rust (see Kani [1] for instance). Formal verification has a serious scaling problem, so forming programs in such a way that there are a few performance-critical areas that use unsafe routines seems like the best route. I feel like Rust leans into this paradigm with `unsafe` blocks. [1] - https://github.com/model-checking/kani https://github.com/model-checking/kani
- lifthrasiir 3y ago
  Yeah, I'm aware of Kani, but it is not optimal for many reasons, including but not limited: hard to install in some cases, loop unrolling is mandatory and does not scale in general (this is a main issue with bounded model checkers, not just Kani), and hard to give hints for efficient verification and/or harness generation. And Kani makes use of CMBC, which is a model checker for C/C++, so Rust is not even special in this regard.
irundebian 3y ago
It should be possible with Ada/SPARK. It's focused on low level systems programming and compilable programs are free from run-time errors. In addition, the correctness of the program or key properties can be proven at compile-time.
ignoramous 3y ago
> "as popular and user-friendly as sanitizers" solution for critical and performance-hungry applications. Google just did enable Memory Tagging Extension (ARM's hardware accelerated sanitizers) on the Pixels last year. May be sanitizing ISAs offer hope?

alexvitkov 3y ago

We still don't have an alternative. No, you can't use Arc<HashMap<Whatever>> in the middle of a decoder routine. Some software to actually has to perform well.

lifthrasiir 3y ago
In this particular case Rust could have helped, because the table construction can use a normal Rust while the tight decoder loop can remain `unsafe` which can be justified more easily. But I demand more than the human-readable justification.
- alexvitkov 3y ago
  What Rust brings to the table is static enforcement of its ownership rules, that's it. How does Rust deal with buffer overflows? Bounds checking. What an innovative solution, congratulations to the Rust people for this groundbreaking innovation. And they keep acting like they've fucking discovered hot water.
  - lifthrasiir 3y ago
    Rust is novel because it bundles lots of existing ideas into one usable package. Even the borrow checking is not new, it's adapted and improved from research languages like Cyclone.
  - delfinom 3y ago
    Yea but did anyone else market hot water first? I think not!
  - insanitybit 3y ago
    No one is saying that bounds checking is novel. It's really C and C++ that are novel, in that they are the only languages where bounds checking is not the default. But if you're having the "memory safe replacement for C/C++" conversation it shouldn't surprise you that people bring up Rust.

cookiengineer 3y ago

Stagefright was the point when I started to tell people to use a safe programming language. When they ask "Which one?" I am answering "I don't care, as long as it's a programming language that uses a VM". Every time I hear the discussions about how fast and perfect C is, people seem to miss the point that new programming languages try to avoid complexity, because they were using C/C++ themselves in the past and they fell on their noses more than once. It's not about what is faster. It is about how often you make mistakes, statistically. And chances are you make dozens of mistakes per day in C that you will never be aware of, whereas in other memory constrained languages they have hundreds of mechanisms implemented to catch those common mistakes.

Filligree 3y ago
You should allow Rust as well, at least.
- cookiengineer 3y ago
  Yeah ofc. My view on programming languages is that both Rust and golang try to use VM methodologies wherever possible when it comes to memory safety and ownership. They just try to do as much as possible ahead of compile time rather than execution time.