Rust not safe opinion

There is a guy that wrote criticism about rust on github and he was banned. He claims in a chat room that it was taken down because microsoft is a rust promoter and owns github

if you cannot see the link then I will put it here also:

the text

Why are Rust advocators like Alex Gaynor and Ryan Levick wrong?

You may wonder why Rust advocators are everywhere on the internet, even though very few actually use it. For example, they advocate that you must RIIR (rewrite it in Rust) or Python programmers must learn Rust because you have no jobs.

The problem is that the Rust community is the worst community I have ever seen. Unfortunately, the toxicity is not directly coming from the users of Rust; they come from Rust devs or Rust sec group, whatever. They keep attacking other languages (particularly C and C++, sometimes go or python). Like you should never create new projects in C or C++, whatever.

However, Rust is nowhere a perfect language. It has many defects, like binary bloat, slowest compilation speed (even exponentially worse than C++), unreadable code. There are new attempts that are trying to replace Rust, like Zig or V language. However, the V lang’s compilation speed benchmark shows that just compiling 20k lines of code can lead to OOM and get killed by the Linux Kernel OOM killer even without any optimization.

I am not going to talk about too much of the language issues themselves.
I have a video “Why I hate Rust programming language” that addresses them. You can watch them if you want. Why I hate Rust programming language? - YouTube

The most significant concern is its community and the minds of Rust devs. Rust publicly advocates, “Rust believes tech will and always be political.”

Please, do not get me wrong. I am not saying everyone in the Rust community is toxic. However, I would argue the majority of Rust users are toxic in general. Yes, they are the majority, not the minority, because the toxicity comes from the Rust devs themselves, and they do sell the language by toxicity.

Here, I want to refute the claims made by Alex Gaynor and Ryan Levick. First, I think a lot of people know Ryan Levick. He is the guy who sells Rust at Microsoft, despite he never writes code.

Who is Alex Gaynor? He is a guy in the Rustsec group. He made these false narratives in his blogs, and RESF folks kept spreading his lies everywhere. A typical example is “Modern C++ does not save us.” He argues that you can still create memory safety vulnerabilities even with modern C++ while claiming those memory safety vulnerabilities are not possible in Rust. But, of course, that is an entirely false claim.

Here are all his lies in his blogs.
On Safety Critical Software · Alex Gaynor

This is a typical lie made by Alex Gaynor (this may not be written by himself, but it basically contains everything that Alex Gaynor says in the past).
What is memory safety and why does it matter? - Prossimo
I want to make a detailed refute to this entire thread because it is so wrong and misleading.

First, the website itself. If you remove the /docs/memory-safety part, what you find is that this is a website that advocates Rust.

“Out of Bounds Reads and Writes”

“Under these circumstances, a language that is not memory safe may allow a programmer to read whatever memory contents happen to exist before or after the valid contents of the list.”

This is just wrong. In C++, all the C++ compilers and standard libraries provide options to enable bounds checking at runtime. For example, libstdc++ provides -D_GLIBCXX_ASSERTIONS.

However, why people do not use them? Because they do incur overhead, despite Rust advocates claim bounds checking are zero-cost abstraction whatever nonsense. There are no zero-cost abstractions.

Unfortunately, the bounds checking in Rust is extremely expensive since it will use panic. Godbolts show us the Rust bounds checking generates 10x more instructions than C++. This is even after -C panic=abort.
Compiler Explorer
Compiler Explorer

It is not uncommon to see Rust users use unsafe to avoid bounds checking.

An example is the Rust ORZ library, which uses unsafe for nearly every function to avoid bounds checking. Avoiding bounds checking makes your code run faster since bounds checking hurts optimizations, CPU instruction cache, and cache lines seriously.
orz/byteslice.rs at master · richox/orz · GitHub

Not mentioning bounds checking cannot be performed in SIMD, invoking syscalls or all sorts of drivers, or building your own data structures. Bounds checking can be very harmful too. A typical example is C++ 17 charconv, to_chars. The bounds checking makes the API extremely inefficient compared to its ryu source or dragon box or GitHub project fast_io since we cannot even know how much buffer it needs before running the algorithm.

There are a lot of reasons when bounds checking are not appropriate. To claim bounds checking always makes your code safer is out-of-context. That is not the case for every situation.

He also criticizes assembly language as being memory unsafe. However, why do people use assembly to write cryptography code (even rust folks do that) despite assembly is so memory unsafe? The problem is that our compilers are not smart enough to deal with high-level language abstractions; they cannot produce the optimal code compared to assembly programmers would typically write, particularly with stuff related to carrying flags. Not mentioning the fact potential side-channel issues with high-level languages compared to assembly. Rewrite those things in Rust is impossible, even though cryptography itself is crucial for security.

“In a memory safe language we will get an error at compile time or a crash at run time. Crashing the program may seem severe, but it’s better than letting users steal each others’ data!”

Of course, the worst part of the “crashing at runtime” for Rust is that it panics. I would agree if it just crashes, and maybe it is helpful in a lot of situations. However, Rust does not just do that; it invokes panic() and introduces many double-free and use-after-free CVEs. The worst part is that Rust’s panic() will continue executing even in drop traits. It is not even like C++, where you cannot throw EH in the destructors (unless you deliberately use noexcept(true), and the compiler would warn you for doing so). One of the worst CVE is the CVE-2021-31162. “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.” This CVE has a 9.8 CVSS 3.0 score, which is even worse than eternal blue’s vulnerability CVE-2017-0143, which is only an 8.1 cvss 3.0 score. How could Rust be so safe if its stdlib contains more serious security vulnerability than eternal blue? Rust stdlib is a security hazard. Rust stdlib has nine memory safety cves in one year than three mainstream C++ standard libraries (libc++, libstdc++, and msvcstl) combined in their entire lifespan, which is two memory safety cves.

I know there will be rust evangelists who claim “our language is easier to grep memory safety cves than C or C++.” However, we can make the opposite claim that “it makes the attacker’s life easier since they can grep memory safety issue more easily through source code.” It is not an excuse for the CVEs that Rust std and crates created during the past years.

Use After Free
Okay. But see how many use-after-free and double-free rust has? Surprise? Because Rust is a false safety net and does not change the reality, the world is unsafe.

Not mentioning the panic() double free issues i just mentioned in Rust code. Unsafe + unwrap abuse everywhere.
CVE - Search Results

“How common are memory safety vulnerabilities?”

“Extremely. A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues 1.”

If you check the vulnerabilities in https://cve.mitre.org/ , what you can find is that Rust has much more memory safety cves from statistics level compared to languages like go or Java or C# since these garbage collection languages do not need you for using unsafe to write data structures. C# can even invoke Win32 and NT APIs without any unsafe. That is not the case for Rust. Rust is the most dangerous one among all so-called “memory-safe” language in Rust’s terms.

How could Rust folks blame C or C++ for WannaCry (out-of-bounds write) when their stdlib has 9.8cvss of CVE which is even worse than Eternal Blue?

“These vulnerabilities and exploits, and many others, are made possible because C and C++ are not memory safe. Organizations which write large amounts of C and C++ inevitably produce large numbers of vulnerabilities that can be directly attributed to a lack of memory safety. These vulnerabilities are exploited, to the peril of hospitals, human rights dissidents, and health policy experts. Using C and C++ is bad for society, bad for your reputation, and it’s bad for your customers.”

This is the worst part of Alex Gaynor’s lie. You cannot blame the tool for violating human rights or people who use C or C++ violate human rights. What about those memory safety CVEs in Rust? Does that mean Rust devs are human rights violators too?

“Because languages that are not memory safe tend to allow for more bugs and crashes, application stability can be greatly impacted. Even when crashes are not security sensitive they are still a very poor experience for users.”

Said by the person who believes a crashing for memory safety issue is better than exploit.

“Unfortunately, multi-threading exacerbates the problems associated with a lack of memory safety, As a result, efforts to take advantage of multi-core CPUs are often intractable in C and C++. For example - Mozilla had multiple failed attempts to introduce multi-threading into Firefox’s C++ CSS subsystem before finally (successfully) rewriting the system in multi-threaded Rust.”

False. Rust’s multi-threading safety guarantee has nothing to do with memory safety. Chandler Carruth, the core leader of LLVM, said a thread-safety contract at the language level does make your code run slower since they hurt optimizations, even you are not using them. They said firefox is a successful example of Rust, but what about chromium? Firefox completely lost competition compared to chromium, a C++ project that bans exceptions and wrote those old legacy C style codes and OO abuse that completely violate so-called modern C++ would allow typical writing.

What about this memory CVE in firefox which is written by Rust? Bug List
⚙ D103999 Bug 1690718 - Update audioipc to 12349217. r?padenot,chunmin

CVE - Search Results
The CVE shows us Rust crates and stdlib have many thread-safety vulnerabilities, too; even Rust folks love to claim their language is perfect “memory” and “thread” safe.

What’s the right path forward?

"
Some practices which can lower the risk of using an unsafe language are:

Using some modern C++ idioms which can help produce more safe and reliable code
Using fuzzers and sanitizers to help find bugs before they make it into production
Using exploit mitigations to help increase the difficulty of exploiting vulnerabilities
Privilege separation so that even when a vulnerability is exploited, the blast radius is smaller
These practices meaningfully lower the risk of using an unsafe language, and if we’ve failed to convince you to change languages, and you are going to continue to write C and C++, adopting these is an imperative. Unfortunately, they are also woefully insufficient.

The people who are the forefront of developing modern C++ idioms, fuzzers, sanitizers, exploit mitigations, and privilege separation techniques are browser and operating system developers — precisely the groups we highlighted at the start with statistics about the prevalence of memory safety problems. Despite these teams’ investment in these techniques, their use of unsafe languages weighs them down. At pwn2own, a large hacking competition, in 2019 over half of vulnerabilities exploited in these products were due to a lack of memory safety, and with one exception, every successful attack exploited at least one memory safety vulnerability.
"

So you are arguing we do not need fuzzing or sanitizers in Rust? But you did say modern C++ does not save us. Can I say Rust does not save us either? It looks like all the CVEs show this way. Yes, Rust does not save us either.

“Is dropping C and C++ really practical?”

This part is basically you should RIIR part. But, of course, they are using the Linux Kernel to allow Rust code to be written as kernel drivers to justify their lie.
I would be happy if Rust can actually improve the code quality of Linux Kernel. However, look at the code they are writing.

linux/rc.rs at rust · Rust-for-Linux/linux · GitHub

The Rust code is basically unsafe hell and the worst Rust code iI have ever seen, even worse than Rust orz lib I previously mentioned. And the worst part of code is like this:

    /// Allocates an `RcBox<T>` with sufficient space for
    /// a possibly-unsized inner value where the value has the layout provided.
    ///
    /// The function `mem_to_rcbox` is called with the data pointer
    /// and must return back a (potentially fat)-pointer for the `RcBox<T>`.
    #[cfg(not(no_global_oom_handling))]
    unsafe fn allocate_for_layout(
        value_layout: Layout,
        allocate: impl FnOnce(Layout) -> Result<NonNull<[u8]>, AllocError>,
        mem_to_rcbox: impl FnOnce(*mut u8) -> *mut RcBox<T>,
    ) -> *mut RcBox<T> {
        // Calculate layout using the given value layout.
        // Previously, layout was calculated on the expression
        // `&*(ptr as *const RcBox<T>)`, but this created a misaligned
        // reference (see #54908).
        let layout = Layout::new::<RcBox<()>>().extend(value_layout).unwrap().0.pad_to_align();
        unsafe {
            Rc::try_allocate_for_layout(value_layout, allocate, mem_to_rcbox)
                .unwrap_or_else(|_| handle_alloc_error(layout))
        }
    }

    /// Allocates an `RcBox<T>` with sufficient space for
    /// a possibly-unsized inner value where the value has the layout provided,
    /// returning an error if allocation fails.
    ///
    /// The function `mem_to_rcbox` is called with the data pointer
    /// and must return back a (potentially fat)-pointer for the `RcBox<T>`.
    #[inline]
    unsafe fn try_allocate_for_layout(
        value_layout: Layout,
        allocate: impl FnOnce(Layout) -> Result<NonNull<[u8]>, AllocError>,
        mem_to_rcbox: impl FnOnce(*mut u8) -> *mut RcBox<T>,
    ) -> Result<*mut RcBox<T>, AllocError> {
        // Calculate layout using the given value layout.
        // Previously, layout was calculated on the expression
        // `&*(ptr as *const RcBox<T>)`, but this created a misaligned
        // reference (see #54908).
        let layout = Layout::new::<RcBox<()>>().extend(value_layout).unwrap().0.pad_to_align();

        // Allocate for the layout.
        let ptr = allocate(layout)?;

        // Initialize the RcBox
        let inner = mem_to_rcbox(ptr.as_non_null_ptr().as_ptr());
        unsafe {
            debug_assert_eq!(Layout::for_value(&*inner), layout);

            ptr::write(&mut (*inner).strong, Cell::new(1));
            ptr::write(&mut (*inner).weak, Cell::new(1));
        }

        Ok(inner)
    }

try_unwrap?? hmhm.

    #[inline]
    #[stable(feature = "rc_unique", since = "1.4.0")]
    pub fn try_unwrap(this: Self) -> Result<T, Self> {
        if Rc::strong_count(&this) == 1 {
            unsafe {
                let val = ptr::read(&*this); // copy the contained object

                // Indicate to Weaks that they can't be promoted by decrementing
                // the strong count, and then remove the implicit "strong weak"
                // pointer while also handling drop logic by just crafting a
                // fake Weak.
                this.inner().dec_strong();
                let _weak = Weak { ptr: this.ptr };
                forget(this);
                Ok(val)
            }
        } else {
            Err(this)
        }
    }

Typical Rust Evangelist told us you rarely need unsafe. However, anyone who seriously uses Rust would tell you the truth, unsafe and unwarp are everywhere.

One of my friends who read that code commented, “this is the C++ moment.” Dual error reporting. One for panic, one for error code. Exactly why C++ is terrible for writing an operating kernel; guess what, you see the same dual error-reporting hell in Rust.

mintsuki, the author of limine bootloader and a lot of operating systems including VINIX (which is written in V language), commented that “Linus Torvalds is brainwashed and now a puppet of google”

The truth is that, Linux Kernel is bloatware and getting worse and worse with year. Criticism of Linux - Wikipedia Wikipedia shows that “Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two percentage points at every release, for a cumulative drop of about 12 percent over the last ten releases.”

Do not trust people who told you Rust would make kernel faster; it won’t; nothing could change the fact Linux codebase is terrible, and rewriting it in any language does not solve any fundamental issue with Linux.

The problem is that Linux lacks competition, and Linus Torvalds himself no longer writes code. He retires. Just like GCC was stagnating 15 years ago, until clang comes out. I hope someone could write a new kernel to compete with Linux.

What about Ryan Levick?

He said Microsoft hates C++ right now, and Microsoft wants to RIIR.

The funny part is that he claimed he trains people C and C++ at Microsoft. However, if you look at his repository,

rylev (Ryan Levick) · GitHub

He did not clone any C++ projects. Just one cloned project is written in C. The funniest part is that all his rust projects are either cloned from other people or toys. It is hard to believe he trains people C and C++ at Microsoft. I seriously doubt his experience writing performance-critical Rust projects since his expertise does not match Rust code’s reality. He is typical language police while whining about how other people write code. He represents the distinct Rust community, complaining about unsafe or other people without writing code themselves. Think about the Actix-web drama.

Conclusion

Do not listen to the loud minority and fakes news who advocates Rust for the echo chamber. Most of them do not use Rust. You do not need to RIIR and real-world Rust code. You can start new C and C++ projects. You do not necessarily need to support Rust. They do not make your code better.

Of course, if you love Rust, you should use it. However, not because someone tells you that you must RIIR, or python programmers have no jobs if you do not learn Rust.

Here is an actually very good paper that describes memory safety issues in Rust, although I would argue it is getting old now.
Understanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs
https://songlh.github.io/paper/rust-study.pdf

Personally, I would never use Rust to write any serious projects. I do not like it, and I think the language is fundamentally broken for many reasons. The worst part is that the community around Rust and the developers of Rust are wrong and toxic.

2 Likes

All I see when I follow your link is a 403 error:

image

1 Like

I put it in a spoiler for you

1 Like

Very interesting. Thanks for posting as a spoiler … Don’t know why I was getting the 403 error. I suppose there are tradeoffs with any language. I only write little scripts in bash these days, so I’ve no clue about most of the complaints he raises.

From everything I’ve heard over the years here, it seems David is pretty happy with the move to Rust in terms of making the code more readable and reducing overall codebase (pre-compile). However, given the struggle maidsafe went through to move SN to Rust, I doubt there would be much criticism of Rust at this juncture even if maidsafe was having some difficulties with it.

1 Like