5 ms·

We must not continue to develop media codecs in memory unsafe languages. Small, auditable sections can opt-out perhaps, but choosing default-unsafe for this typ

We must not continue to develop media codecs in memory unsafe languages. Small, auditable sections can opt-out perhaps, but choosing default-unsafe for this type of software is close to professional negligence.

fguerraz 5mo ago
Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.
- WhatIsDukkha 5mo ago
  Thank you for mentioning this. I wonder IFF Rust had an effects system that a Jasmin MIR transform (ie like SPIRV is for shaders) would be useful? https://github.com/jasmin-lang/jasmin https://github.com/jasmin-lang/jasmin
- astrange 5mo ago
  Video codecs just don't need to do dynamic allocations because it's not relevant to the problem. There's still certainly plenty of opportunities for memory bugs because there's a lot of pointer math.
- simonask 5mo ago
  What in the world do you mean by “non-deterministic”? C compilers, Rust compilers, and assemblers are all deterministic.
  - adgjlsfhk1 5mo ago
    > C compilers, Rust compilers, and assemblers are all deterministic. Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.
  - fguerraz 5mo ago
    In cryptography, you want operations to run in constant time, even if it’s wasteful, otherwise an attacker could guess information about the key or plaintext by measuring execution times. Modern compilers are extremely clever and will produce machine code that takes full advantage of modern CPU branch predictors, and reorder instructions to better take advantage of pipelining. This in itself will make the same code run at different speeds depending on the input data. Then there is the whole issue of compiler version roulette. As a developer you have no idea which version of compilers your users and distros will use, and what new and wonderful optimisation they will bring.
    - simonask 5mo ago
      I know that, but none of that makes the compiler output non-deterministic. Determinism does not mean “easy to predict”, it just means “predictable”.
- dcsommer 5mo ago
  How is this POV compatible with the exploitable vulnerabilities, caused by memory safety, found in openh264, x264, dav1d, and practically every video decoder out there?
  - izacus 5mo ago
    Easily. It's a tradeoff.
fishgoesblub 5mo ago
Of the 3 software AV1 encoders, the only one that is fully dead is the Rust encoder (rav1e). If people truly wanted memory safe encoders/decoders, they would fund and develop them.
- esseph 5mo ago
  > If people truly wanted memory safe encoders/decoders Really? How many codecs have your neighbors contributed money for the development of, just curious.
  - Telaneo 5mo ago
    Given Netflix's involvement with SV1-AV1, (not even that) indirectly, at least 1.
  - computerbuster 5mo ago
    I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.
    - esseph 5mo ago
      I'm more interested in the idea of general "people" (the commons) funding complex video encoders. I do wish that was the world we lived in, however :)
- vlovich123 5mo ago
  Fully dead in what sense? Seems like it still has active development to me.
  - fishgoesblub 5mo ago
    It hasn't had any proper quality/speed improvements in years. Only thing that has changed is updating deps and some bug fixes.
kllrnohj 5mo ago
For the codec itself, the majority of it is performance sensitive and often has a significant amount of assembly even, so a memory safe language doesn't change much. However for the container/extractor... those should absolutely be in a memory safe language, and those are were a lot of the exploits/crashes are, too, as metadata is more fuzzy. As a practical example of this see something like CrabbyAVIF. All the parser code is rust, but it delegates to dav1d for the actual codec portion
maxloh 5mo ago
Decoders written in Rust will be a lot slower than the equivalents in assembly.
izacus 5mo ago
Are you part of any codec development team to use "we" here?

fguerraz 5mo ago

Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.

WhatIsDukkha 5mo ago
Thank you for mentioning this. I wonder IFF Rust had an effects system that a Jasmin MIR transform (ie like SPIRV is for shaders) would be useful? https://github.com/jasmin-lang/jasmin https://github.com/jasmin-lang/jasmin
astrange 5mo ago
Video codecs just don't need to do dynamic allocations because it's not relevant to the problem. There's still certainly plenty of opportunities for memory bugs because there's a lot of pointer math.
simonask 5mo ago
What in the world do you mean by “non-deterministic”? C compilers, Rust compilers, and assemblers are all deterministic.
- adgjlsfhk1 5mo ago
  > C compilers, Rust compilers, and assemblers are all deterministic. Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.
- fguerraz 5mo ago
  In cryptography, you want operations to run in constant time, even if it’s wasteful, otherwise an attacker could guess information about the key or plaintext by measuring execution times. Modern compilers are extremely clever and will produce machine code that takes full advantage of modern CPU branch predictors, and reorder instructions to better take advantage of pipelining. This in itself will make the same code run at different speeds depending on the input data. Then there is the whole issue of compiler version roulette. As a developer you have no idea which version of compilers your users and distros will use, and what new and wonderful optimisation they will bring.
  - simonask 5mo ago
    I know that, but none of that makes the compiler output non-deterministic. Determinism does not mean “easy to predict”, it just means “predictable”.
dcsommer 5mo ago
How is this POV compatible with the exploitable vulnerabilities, caused by memory safety, found in openh264, x264, dav1d, and practically every video decoder out there?
- izacus 5mo ago
  Easily. It's a tradeoff.

fishgoesblub 5mo ago

Of the 3 software AV1 encoders, the only one that is fully dead is the Rust encoder (rav1e). If people truly wanted memory safe encoders/decoders, they would fund and develop them.

esseph 5mo ago
> If people truly wanted memory safe encoders/decoders Really? How many codecs have your neighbors contributed money for the development of, just curious.
- Telaneo 5mo ago
  Given Netflix's involvement with SV1-AV1, (not even that) indirectly, at least 1.
- computerbuster 5mo ago
  I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.
  - esseph 5mo ago
    I'm more interested in the idea of general "people" (the commons) funding complex video encoders. I do wish that was the world we lived in, however :)
vlovich123 5mo ago
Fully dead in what sense? Seems like it still has active development to me.
- fishgoesblub 5mo ago
  It hasn't had any proper quality/speed improvements in years. Only thing that has changed is updating deps and some bug fixes.

kllrnohj 5mo ago

For the codec itself, the majority of it is performance sensitive and often has a significant amount of assembly even, so a memory safe language doesn't change much. However for the container/extractor... those should absolutely be in a memory safe language, and those are were a lot of the exploits/crashes are, too, as metadata is more fuzzy. As a practical example of this see something like CrabbyAVIF. All the parser code is rust, but it delegates to dav1d for the actual codec portion

maxloh 5mo ago

Decoders written in Rust will be a lot slower than the equivalents in assembly.

izacus 5mo ago

Are you part of any codec development team to use "we" here?