Announcement

Collapse
No announcement yet.

Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    • A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c [...]
      This is actually C code
    • Deno is a runtime for JavaScript and TypeScript that uses V8 and is built in Rust [...]
      That's a logic bug in JavaScript import
    • An issue was discovered in the algorithmica crate [...]
      That's a logic error resulting in double-free
    • An issue was discovered in the rkyv crate [...]
      That's a logic error resulting in broken serialization
    • In the standard library in Rust before 1.52.0, a double free can occur in the Vec::from_iter function if freeing the element panics. [...]
      Double free if freeing panics
    • [the next 11 or something entries]
      Again double free if freeing panics
    • In the standard library in Rust before 1.52.0, the Zip implementation can report an incorrect size due to an integer overflow
      Not nice...

    So no, rust doesn't make your programs magically bug-free. But it usually eliminates one source of bugs.


    Comment


    • #22
      Originally posted by ultimA View Post
      Sure, and because it is not completely written in Rust, I am not expecting Firefox to be free of memory-related issues. But if it is 20% Rust, I do expect it to have almost 20% (or at least 10%) less memory-related issues, which is not the case at all.
      Well, one would need to analyze what actually happened here in order to properly comment on this. Did you do the analysis and can share it?

      Originally posted by ultimA View Post
      One might argue the reason is memory-related issues are not guaranteed to have the same occurrence rate in all parts of the code. But it is safe to assume that Mozilla didn't choose to rewrite exactly those parts in Rust that are the least likely to have security issues, so I'm pretty sure this doesn't explain it.
      Again, it would be important to know which security issues arose.

      Furthermore, how did you find out which of those firefox-CVEs are in rust code? Last time I checked I did it manually for a few bugs, which is a lot of work.

      Comment


      • #23
        Originally posted by ultimA View Post

        But is Rust's security really that much better? -O3 is irrelevant (I don't care about that either), but as for security, real world shows Rust's most advertised feature, its "better security compared to C++" is very limited and over-estimated. There is no shortage of memory memory-related CVEs in Rust crates, both double-drops/frees and dereference of invalid memory. See link below.
        Or even more shocking, Firefox has about 20% of its native code in Rust, yet the share of memory-related CVEs (percentage-wise) is basically still the same as in any other non-Rust project (about 70%).

        Sources:
        https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
        https://www.openhub.net/p/firefox/an...guages_summary
        https://www.cvedetails.com/product/3...?vendor_id=452
        Those are bindings for C libraries and the bugs occur at the Rust-C boundary dealing with C objects (buffers, structs etc.) which obviously Rust's lifetime and borrow checker cannot track. Yes, it will be the same in the kernel, wherever Rust is called from or calls into C code, you need to take care of memory management manually, that's true.

        Comment


        • #24
          Sorry, double-post.

          Comment


          • #25
            Originally posted by oleid View Post
            • A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c [...]
              This is actually C code
            • Deno is a runtime for JavaScript and TypeScript that uses V8 and is built in Rust [...]
              That's a logic bug in JavaScript import
            • An issue was discovered in the algorithmica crate [...]
              That's a logic error resulting in double-free
            • An issue was discovered in the rkyv crate [...]
              That's a logic error resulting in broken serialization
            • In the standard library in Rust before 1.52.0, a double free can occur in the Vec::from_iter function if freeing the element panics. [...]
              Double free if freeing panics
            • [the next 11 or something entries]
              Again double free if freeing panics
            • In the standard library in Rust before 1.52.0, the Zip implementation can report an incorrect size due to an integer overflow
              Not nice...
            The list was created by simply searching for Rust, so there is a small number of false positives there which aren't Rust. But if you take a look at that list under the original link (and you took), then you see it is overwhelmingly and mostly Rust code. So by selectively quoting one or two item of the 5% on that list which is not Rust, you are distracting from the facts by making the list look invalid when it is not.
            Last edited by ultimA; 05 July 2021, 04:54 AM.

            Comment


            • #26
              Originally posted by oleid View Post
              Furthermore, how did you find out which of those firefox-CVEs are in rust code? Last time I checked I did it manually for a few bugs, which is a lot of work.
              I didn't but no need. The point is if we assume that the part of C++ code that was rewritten in Rust had percentage-wise as many memory-issues before the rewrite as the non-rewritten parts (and this is a sound assumption because the main motivation for the rewrite is to get rid of such bugs), and the rewrite in Rust eliminated most if not all memory issues, then after the rewrite we should see that much less memory-issues as the percentage of code that was rewritten. And this is not what we see. In fact, we see no change at all. Or do you mean to imply that rewriting 20% of code in Rust automatically introduces 20% more safety-issues in other parts of the code? Surely not.

              Comment


              • #27
                Originally posted by ultimA View Post

                The list was created by simply searching for Rust, so there is a small number of false positives there which aren't Rust. But if you take a look at that list under the original link (and you took), then you see it is overwhelmingly and mostly Rust code. So by quoting one item of the 5% on that list which is not Rust, you are distracting from the facts by making the list look invalid when it is not.
                The first was not rust. The 2nd was already in rust code. But if you read what I wrote carefully, I'm not distracting from anything. I explicitly wrote:

                So no, rust doesn't make your programs magically bug-free. But it usually eliminates one source of bugs.

                Comment


                • #28
                  Imho there are several issues with rust:
                  - It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)
                  - For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
                  - (personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

                  Comment


                  • #29
                    Originally posted by ultimA View Post

                    I didn't but no need. The point is if we assume that the part of C++ code that was rewritten in Rust had percentage-wise as many memory-issues before the rewrite as the non-rewritten parts (and this is a sound assumption because the main motivation for the rewrite is to get rid of such bugs), and the rewrite in Rust eliminated most if not all memory issues, then after
                    Oh, you just assume those bugs are in rust code, but you actually don't know...

                    the rewrite we should see that much less memory-issues as the percentage of code that was rewritten. And this is not what we see. In fact, we see no change at all. Or do you mean to imply that rewriting 20% of code in Rust automatically introduces 20% more safety-issues in other parts of the code? Surely not.
                    Well, another explanation might be: the tools got better and there are more reports for the C++ code parts.

                    Or: the other code parts didn't generate many CVEs before and the amout of CVEs simply grow because the total LOC grew.

                    Please come back with solid claims on rust in Firefox without any dubious statistical FUD.

                    Comment


                    • #30
                      Originally posted by ShFil View Post
                      Imho there are several issues with rust:
                      - It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)
                      From what I've heard about the discussion in systemd on adding rust, it is hard to find C maintainers. Probably harder for the kernel.



                      Originally posted by ShFil View Post
                      - (personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,
                      It is a long time before this is going to be used. By then, dust has settled.

                      Comment

                      Working...
                      X