Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kobzol.github.io

Post reply on HN
Print view View original

201–210 of 270 posts

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

#201

Post by pjmlp »

saghm wrote: post #155
tialaramex wrote: post #43

Earlier quoted context omitted.

A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the l…

Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills…

Too busy contributing to Symbian, Windows, macOS, BeOS...

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

#202

Post by kasey_junk »

tptacek wrote: post #194
mk89 wrote: post #165

Earlier quoted context omitted.

Not as a metric, but it basically becomes one, like with Fedramp. You need to fix also moderate/low CVEs within a certain time frame. So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is. It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed…

I don't do FedRAMP and will have to take your word for that, but none of SOC2, 27001, or HIPAA/HITRUST care about CVE counts.

PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.

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

#203

Post by tptacek »

kasey_junk wrote: post #202
tptacek wrote: post #194

Earlier quoted context omitted.

I don't do FedRAMP and will have to take your word for that, but none of SOC2, 27001, or HIPAA/HITRUST care about CVE counts.

PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.

Right, you can write a bad SOC2 control that cares about CVE counts too!

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

#204

Post by saghm »

f33d5173 wrote: post #171
saghm wrote: post #149

Earlier quoted context omitted.

Can you do that with a dynamic array? If not, it's pretty severely limited (unless you mean that literally forbidding dynamic memory is usually not done, which I guess it's true outside of some embedded code but not a particularly meaningful statement).

The syntax is rather confusing. This is not an array of length 1, but rather a pointer which points to a memory segment which is at least 1 integer long. In other words, any array of any length (>=1) would be a valid argument to this function. "static" here means "don't do the normal thing where you totally ignore the length of an array argument to a function (which is, like usual, really just a pointer)". "static" w…

I see. Can you use `static 0` for a non-null empty array, or does that run into issues around what it means to allocate 0 bytes? I feel like the distinction between "empty but safe to use" and "not safe to use, so you need to check first" is a pretty important part of what most of the solution look like in languages that don't have this problem. Being able to statically know that something is non-empty is nice, but it's not quite the same as being forced to check if it's valid.

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

#205

Post by tialaramex »

drysine wrote: post #179
tialaramex wrote: post #46

Earlier quoted context omitted.

> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Nev…

>ColdString and CompactString, which are way better than what's provided in C++ Could you elaborate on that?

Sure, to simplify lets assume a 64-bit CPU (this all works for 32-bit but that's less common these days and the actual numbers are different)

C++ std::string can contain up to 15 (other popular implementations) or 22 bytes (libc++ from Clang) of inline text, and the data structure itself is either 24 bytes (Clang again) or 32 bytes of storage. Here's Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=10...

CompactString is 24 bytes of storage with all 24 bytes as potential inline text. When the 24 bytes are valid UTF-8 text, then that's the content of the CompactString e.g. "https://example.org/cool", if they aren't the last byte will be invalid UTF-8, and this signals whether some of the other 23 bytes were inline UTF-8 (and if so how many) or whether they should be interpreted as a pointer, size and capacity.

ColdString is a radically different idea, it's 8 bytes of unaligned storage and it's one of three things: 1. 8 bytes of UTF-8 text, as before we can tell by whether it's valid UTF-8 text or 2. 0-7 bytes of UTF-8 text, prefixed by an invalid UTF-8 byte telling us how many of the remaining bytes are text or 3. An encoded pointer to a length-prefixed data structure, signalled by the presence of the UTF-8 continuation marker bits which should never be present in the first byte of a string.

I really like ColdString because it's so much in the "use the whole buffalo" spirit of these modern safe yet high performance types. UTF-8 has what are called "overlong prefixes" because it was invented before Unicode decided it would never grow beyond U+10_FFFF and these are often just a useless impediment, but ColdString uses those prefixes.

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

#206

Post by steveklabnik »

pjmlp wrote: post #197
josephg wrote: post #129

Earlier quoted context omitted.

> Until Rust has equal meta-programming support to C++ it's always going to be "slower". What metaprogramming does C++ have that rust is lacking? If you need more than traits + generics, rust also has proc macros. Proc macros are essentially portable compiler extensions. They take in a stream of symbols from the user's program at compile time and emit rust code that gets passed straight to the compiler. You lose out…

> What metaprogramming does C++ have that rust is lacking? Compile time execution, and compile time reflection, with the same syntax. Proc macros are still a kludge having to depend on syn crate, and some stuff used to depend on nightly, is that still the case, I don't keep track? Additionally type specialisation, and explicit templates.

Proc macros haven't depended on nightly things in a very, very very long time.

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

#207

Post by uecker »

1718627440 wrote: post #173
uecker wrote: post #142

There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument. And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explo…

A dereference in the final binary is not different from Rust. A dereference in the source code, that makes the whole program invalid, so the compiler doesn't emit a credentials check you wanted it to emit, is. For availability and stability concerns, the C approach is actually better, but for security and reproducibility, it is not.

The check is removed only if you already dereference the pointer before doing the check. But then, you also get the trap before the check. So the compiler eliding the check is not making this worse - as long as the zero page is not mapped.

In any case, you can also configure GCC to not do this, and you can also configure it to insert explicit null checks before dereferencing a pointer. So C can offer you security and reproducibility (in this aspect).

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

#208

Post by pjmlp »

steveklabnik wrote: post #206
pjmlp wrote: post #197

Earlier quoted context omitted.

> What metaprogramming does C++ have that rust is lacking? Compile time execution, and compile time reflection, with the same syntax. Proc macros are still a kludge having to depend on syn crate, and some stuff used to depend on nightly, is that still the case, I don't keep track? Additionally type specialisation, and explicit templates.

Proc macros haven't depended on nightly things in a very, very very long time.

Thanks for the update, outside some weekend experiments, or having to compile from source some specific tools, I don't have much reasons to write Rust, thus not keeping that much other than conference talks that pop up on my feeds.

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

#209

Post by uecker »

Ygg2 wrote: post #170
uecker wrote: post #142

There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument. And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explo…

> And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere. Which is what the parallel Perl(?) component was doing at the time. Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

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

#210

Post by pjmlp »

saghm wrote: post #156
Decabytes wrote: post #90

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…

> He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues. I'll believe this when he can actually point to non-trivial, real-world C++ codebases that have managed to avoid having memory unsafety following these techniques. "It's technically possible for this issue to be avoided" is a lot easier to say than it is to actually make work…

The recipe is tame C and C++ as much as possible, on the language level, toolchains and hardware memory tagging, following by writing new code in something else like Swift.

See Meet with Apple, security event.

Naturally they aren't going to throw away LLVM, DriverKit or Metal Shading Language, so there is a compromise there.

Post reply on HN