Brendan (btrotter.delete@this.gmail.com) on July 11, 2021 6:51 am wrote:
> Hi,
>
> Michael S (already5chosen.delete@this.yahoo.com) on July 11, 2021 6:01 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on July 11, 2021 1:54 am wrote:
> > > Hi,
> > >
> > > cqwrteur (euloanty.delete@this.live.com) on July 10, 2021 6:27 pm wrote:
> > > > Oh. Modern C++ does not save us. Neither C nor C++ are fixable. Using C or C++ will
> > > > destroy the earth and kill everyone. Using C or C++ violates human rights.
> > > >
> > > > Okay. That is exactly the Rust advocator like you's logic. Alex Gaynor, one of the Rustsec
> > > > evanglist (who is actually Rust dev) actively pushes Rust into Linux kernel because he
> > > > treats C and C++ as some kind of great evil like hitler who violates human rights.
> > > >
> > > > Right. Clearly Linus Torvalds is the worst human rights violator
> > > > in the world based on him and people like you's logic.
> > >
> > > Let's pretend that you are responsible for Linux and everyone blames you each time a new CVE
> > > is found; and you want Linux to improve and be the best/most secure kernel it can be.
> > >
> > > Let's pretend you started by investigating the causes of the last 200 CVEs, and
> > > found that there's lots of causes (CPU/hardware bugs that aren't the kernel's
> > > fault at all, overflows, etc) but "memory safety" is one of the top causes.
> > >
> > > Now; what could you do?
> >
> > But does it matter?
> > I mean, I believe that "memory safety" is one of the top causes, probably, in top 5 or even
> > top 3, but I don't believe that it accounts for, say, more than 1/5th of all CVEs.
> > I.e. it warrants attention, but very far from warranting such radical changes in methodology
> > as switch to Rust that very likely has uncountable disadvantages vs current set of tools.
>
> It depends a lot on when you look and how you classify (and if you apply weights based on severity); but...
>
> For the current most recent 10 CVEs (from https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2021/Linux-Linux-Kernel.html
> starting from "CVE-2021-34693 from 2021-06-14" in case it changes and you end up looking at newer list); it
> looks like 60% could be classified as "memory safety" (parts of a data structure are uninitialized, out-of-bounds
> reads, 3 x use-after-free, out-of-bounds memory write = 6/10).
>
> It could be a fluke (a larger sample would be better); but it's at least plausible
> to claim that "memory safety" the single largest cause of CVEs in Linux.
>
> Of course it's also plausible to classify differently, and possible to argue that Rust
> won't avoid (some? most? all?) the memory safety issues, or that Rust will create new
> problems, or that "found CVEs" are a lot less important than "not found CVEs".
>
> - Brendan
>

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

Same with Rust crates and std. You still see 80% of cves are memory safety cves.

Notice that this is only in crates. A lot of security vulnerabilities are not shown. Redox OS whatever.

https://bugzilla.mozilla.org/buglist.cgi?bug_id=1513519%2C1683439%2C1690169%2C1690718
https://phabricator.services.mozilla.com/D103999

Things like Linux kernel, a monolithic single address kernel, you need a lot of unsafe. You will still find a lot of cves.


If your argument is that parts of data structures are uninitialized, use-after-free, actually C++ reduces a huge amount of problem too, even you can add checks for preventing oob issues (that is what libstdc++ or C++ standard library is doing). Also unlike Rust, you can change existing C code to make them safer while Rust could only be used in new code.

However, linus torvalds clearly does not like it and reasonable about it. And yes, C++ EH is a huge issue in kernel.

So, Rust must prove it is superior to modern C++. However, Rust still requires a huge amount of runtime afaik, due to the bloat of rustfmt and all sorts of other stuffs. Clearly, using Rust is no better either.


Also recently I've found the stupidity like this:
https://github.com/Rust-for-Linux/linux/commit/c606d85a0d3c67b8221fee5fa67028bdebd4b0cc#diff-521fe5c9ece1aa1f8b66228171598263574aefc6fa4ba06a61747ec81ee9f5a3


Instead of doing this
void foo()
{
p[1].x().y() = p[2].x().y();
}


Now you have to do this. Who the fuck in rust team though this is a good idea.
///SAFETY: p has 5 elements
///XXXX
///XXXX
unsafe fn foo()
{
(unsafe{p.get_mut_unchecked(1)}.unsafe {x()}.unwrap().unsafe{y()?})? = (unsafe{p.get_mut_unchecked(2)}.unsafe {x()}.unwrap().unsafe{y()?})?;
}

Rust one is completely unreadable, wasting programmers time and probably even leading to slower compilation.


If the goal of Rust team is to make everything painful, why should I waste time to fight against the compiler? Instead of using that time to sanitize and fuzz? What's the benefit of using it?