4 ms·

Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in

Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.

uecker 10mo ago
Was it? It seems more a fantastic demonstration how the same type of errors can also occur in Rust code.
- jrimbault 10mo ago
  In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
  - uecker 10mo ago
    This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
    - Certhas 10mo ago
      Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... But don't take my word for it, you can hear about the benefits of Rust directly from GKH: www.youtube.com/watch?v=HX0GH-YJbGw There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
      - bgwalter 10mo ago
        [flagged]
        0dayz 10mo ago
        What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
        deleted 10mo ago
        [deleted]
        bgwalter 10mo ago
        [flagged]
        0dayz 10mo ago
        So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
        bgwalter 10mo ago
        [flagged]
        inejge 10mo ago
        > Why don't they use qmail as an example? Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation. Android is probably more representative of large C (or C++) projects one may encounter in the wild.
        AlotOfReading 10mo ago
yourdetect 10mo ago
[flagged]
- uecker 10mo ago
  That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
  - yourdetect 10mo ago
    I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises. One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly. The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
    - uecker 10mo ago
      It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
      - johncolanduoni 10mo ago
        And the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.
      - 10mo ago

uecker 10mo ago

Was it? It seems more a fantastic demonstration how the same type of errors can also occur in Rust code.

jrimbault 10mo ago
In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
- uecker 10mo ago
  This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
  - Certhas 10mo ago
    Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... But don't take my word for it, you can hear about the benefits of Rust directly from GKH: www.youtube.com/watch?v=HX0GH-YJbGw There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
    - bgwalter 10mo ago
      [flagged]
      - 0dayz 10mo ago
        What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
        deleted 10mo ago
        [deleted]
        bgwalter 10mo ago
        [flagged]
        0dayz 10mo ago
        So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
        bgwalter 10mo ago
        [flagged]
      - inejge 10mo ago
        > Why don't they use qmail as an example? Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation. Android is probably more representative of large C (or C++) projects one may encounter in the wild.
      - AlotOfReading 10mo ago

yourdetect 10mo ago

[flagged]

uecker 10mo ago
That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
- yourdetect 10mo ago
  I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises. One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly. The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
  - uecker 10mo ago
    It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
    - johncolanduoni 10mo ago
      And the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.
    - 10mo ago