Live data from Hacker News

How memory safety CVEs differ between Rust and C/C++

kobzol.github.io

91–100 of 270 posts

Re: How memory safety CVEs differ between Rust and C/C++

#91

Really annoying when people take 50 year old C code and modern C++ code and just drop them into the same bucket and refer to them as if they're the same thing. The CURL example they give has multiple modern C++ solutions that accomplish the same thing without UB.

I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into "rewrite every single thing now in Rust" but one component at a time when the project justifies it.

So, tell me what compiler option disables non-modern C++ code? Is there one that enforces that every single variable including stack ones work like unique_ptrs without paying the price?

How about safety checks in std; is there an opt-out style safety checks where I can ensure that I'm not adding random things to a map with the [] operator, the library checks size of vector when I access elements in non-performance-critical code, anybody can use iterators safely without being able to write code that can change contents of a container?

How about std::thread? Is there an enforcement switch that I can only pass in things that work exactly like trivially_constructibles, unique_ptrs or shared_ptr>s and nothing else?

Is there a compiler switch that completely goes against https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines... and ensures that no unchecked pointer access happens without explicit approval from the developer?

If those all exist, is there a movement to port many of the core building block libraries to that special compiler including std without being afraid of breaking ABI?

Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler. A lot of "modern" C++ code still contains and, by design, cannot avoid creating unintended and unlimited UB.

Re: How memory safety CVEs differ between Rust and C/C++

#92

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

[flagged]

Re: How memory safety CVEs differ between Rust and C/C++

#93
post #61
post #52

I'm not sure i think those situations are comparable. If a rust func is taking an Option , its essentially advertising that it can handle None values. That feels quite a bit different from giving a c function a null pointer and having it freak out.

Ye, sure, but Rust won’t compile a `foo(std::ptr::null())`, if the function is defined as `fn foo(b: &Baz)`. C doesn’t get that luxury. That is the point of the article.

  $ gcc -Wall -Werror -x c - :1:37: error: null passed to a
      callee that requires a non-null argument
      [-Werror,-Wnonnull]
    1 | void f(int x[static 1]){}int main(){f(0);}
      |                                     ^ ~
  :1:12: note: callee declares array
      parameter as static here
    1 | void f(int x[static 1]){}int main(){f(0);}
      |            ^~~~~~~~~~~
  1 error generated.
It can be done, though it usually isn't.

Re: How memory safety CVEs differ between Rust and C/C++

#94

Bjarne Stroustrup was recently interviewed by Ryan Peterman^1 1. https://youtu.be/U46fJ2bJ-co?t=2780 and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either 1. Being written in C style C++ and not using "Modern C++" 2. Being written in C He then goes on to say say that Modern C++ and where it is necessary, hardened libraries…

> I'm not a C++ guy, so how much of this is true?

You can see comments on /r/cpp here: https://www.reddit.com/r/cpp/comments/1tgtllt/bjarne_stroust...

There is a significant discussion about it.

However, there are also a number of other threads on /r/cpp where you can read about people's opinions. https://www.reddit.com/r/cpp/comments/1rsmw5j/c26_safety_fea... is one sort of recent (three months ago) thread that I remember having quite the discussion.

My take (which is, given that I worked on Rust, a bit biased, but I intend to be truthful regardless) is that there are some folks who agree with Bjarne, but also many who do not.

Time will tell.

Re: How memory safety CVEs differ between Rust and C/C++

#95

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

[flagged]

interesting links

> Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but *those claims are entirely unsubstantiated*

huh

> The guy that tried to SWAT me was extremely enthused about Rust: never shut up about it.

hm. the guy was also ostensibly a male. should we ban all men from HN? maybe they should be fired and shunned and cast out of society.

Re: How memory safety CVEs differ between Rust and C/C++

#96

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

[flagged]

yeah this is absurd and a brand new account pushing it too.

Re: How memory safety CVEs differ between Rust and C/C++

#97
post #52

I'm not sure i think those situations are comparable. If a rust func is taking an Option , its essentially advertising that it can handle None values. That feels quite a bit different from giving a c function a null pointer and having it freak out.

But it isn't different, that's Tony Hoare's Billion Dollar Mistake.

It is different. Handling `None` in a way that crashes your program is well defined in a Rust function. If you're using `unwrap` or `expect`, the program will crash with a stack trace and an error, instead of running into undefined behavior.

Re: How memory safety CVEs differ between Rust and C/C++

#98

Memory safety is a concern, but there are many solutions that don't include Rust. Rust is certainly one solution, though. However, Rust seems to trade memory safety vulnerabilities for supply chain risk.

> supply chain risk how is rust special in this regard?

It really isn't and AFAIK there has been little if any supply chain compromise in Rust code as of now

Re: How memory safety CVEs differ between Rust and C/C++

#99
post #95

Earlier quoted context omitted.

[flagged]

interesting links > Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but *those claims are entirely unsubstantiated* huh > The guy that tried to SWAT me was extremely enthused about Rust: never shut up about it. hm. the guy was also ostensibly a male. should we ban all men from HN? maybe they should be fi…

[flagged]

Re: How memory safety CVEs differ between Rust and C/C++

#100
post #95

Earlier quoted context omitted.

[flagged]

interesting links > Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but *those claims are entirely unsubstantiated* huh > The guy that tried to SWAT me was extremely enthused about Rust: never shut up about it. hm. the guy was also ostensibly a male. should we ban all men from HN? maybe they should be fi…

[flagged]
Post reply on HN