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

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

211–220 of 272 posts

Re: Memory safety absolutists

#211

Post by pornel »

blurgrin wrote: post #19

> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Unfortunately, I've never seen a version of this data targeting modern C++ (>=11, with smart pointers, already 15 years old).

Chromium is 17-20 (excluding some features they think are footguns) and even has its own MiraclePtr.

There's no True Scotsman C++. All C++ codebases would be perfectly safe, except the ones that people actually wrote.

Note that Rust has been created after C++ already had smart pointers. Rust treated "modern" C++ as safety failure to be replaced, not as an unrealized competitor. This is still a problem with the C++ WG today: their most ambitious safety ceiling is aiming below Rust's floor.

Re: Memory safety absolutists

#212

Post by pizlonator »

drogus wrote: post #149
pizlonator wrote: post #63

The problem with this post is the extent to which it shows that its author has an unhealthy obsession with me personally. It’s weird but also oddly flattering. I don’t dislike Rust, and when I point out that Rust is not fully memory safe, it’s because I find the details here super interesting. It’s interesting that Rust deliberately chooses to have an unsafe subset. It’s interesting how that leaks out to the rest of…

I don't have an obsession with you. I haven't read the entirety of your social media presence, but almost every time I see a discussion about Rust on Twitter, especially involving Fil-C, I see your criticism of Rust, without much nuance. To be honest, seeing your replies emphasizing Rust's memory unsafety under pretty much every tweet I've seen about the subject felt like an obsession with Rust, to me. The problem I…

Before I started talking about Fil-C, discussions about Rust’s memory safety lacked nuance: folks claimed that if you just compiled your code in Rust then it would be memory safe.

I have added the nuance. Folks now understand that there are limits to Rust’s memory safety.

What have you added to the conversation? Nothing.

Re: Memory safety absolutists

#213

Post by mirashii »

tptacek wrote: post #76

Once again, people are grappling with an axiomatic definition of "memory safety" and avoiding the fact that it's a term of art with a very specific meaning: comprehensive protection from The Memory Corruption Vulnerabilities, which include overflows, the lifecycle vulnerabilities like UAF and type confusion, and uninitialized variables. To the extent Fil-C and Rust both address these vulnerabilities, and don't includ…

The really silly thing is that Fil-C and Zig here have chosen a definition of memory safety that specifically excludes a bunch of overflow vulnerabilities and type confusion. At least it’s been specifically defined, but such a narrow definition makes the end result to me almost wholly uninteresting. UAF no longer turns into a RCE, but your average parsing packet code is still just as likely to be a buggy mess.

Re: Memory safety absolutists

#214

Post by satvikpendem »

dns_snek wrote: post #126
consumer451 wrote: post #23

Earlier quoted context omitted.

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. However, I should probably pipe down, as I would not call myself either one.

> memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. I wouldn't go that far, what matters is the finished whole. Memory safety of the finished program is a critical factor and using a memory safe language makes it easier to achieve that goal. However simply using a memory safe language doesn't make you a "Software Engineer" any mor…

Necessary versus sufficient condition, as they say in philosophy.

Re: Memory safety absolutists

#215

Post by mpweiher »

"Turnabout is fair play"

Or as the poster put it

> When seeing the title of this post, I bet in some people's minds, the first thought was "Rust devs!". This connection is not unfounded.

Exactly. The Rust community has been very holier-than-thou on the memory safety front and quite absolutist ("how dare you code in non-Rust, don't you care about memory safety? You must be a bad person").

Now that it turns out that there is an alternative that is even safer, we suddenly get "well, it's a bit more complicated, memory safety isn't everything, you have to look at the broader context and requirements"

Excellent!

Glad you've come around to that point of view, dear Rust community. Now let's have civilized discussions about trade-offs.

Re: Memory safety absolutists

#216

Post by sirwhinesalot »

pjmlp wrote: post #188
sirwhinesalot wrote: post #150

I don't particularly care about Rust vs Fil-C shit flinging, I don't even see them as competing since they have effectively near opposite tradeoffs. You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution. What I do care about are C…

C++ has had bounds checking in standard library for ages, and on compiler specific frameworks like MFC and OWL, however plenty of devs apparently never read the compiler manuals on how to improve safety and related compiler settings. It is also relatively strange that many devs use the lacks of standardisation as an excuse to not adopt safety features in C and C++, while at the same time rush out to adopt cool toys t…

For std::string and std::vector yes, but not for std::span (until C++26) for reasons I cannot understand.

Re: Memory safety absolutists

#217

Post by debugnik »

noelwelsh wrote: post #6

Good article. Not much to add to it, other than I think more people should look at modal type systems like found in Scala 3 and OxCaml. If you want safe arena allocation they are a lot more ergonomic than Rust's approach.

I'm familiar with OxCaml, but in what sense does Scala have modalities?

Re: Memory safety absolutists

#218

Post by mikewarot »

What drives me nuts is the fact that memory safety actually has little bearing on Computer Security at large. If we had multi-level secure OSs*, with capabilities based facilities available to the user, a lost pointer would just crash the program in question, and that's it... zero side effects, ever.

I'm hoping that the next release of Sculpt, Genode's user-facing OS release, will offer this, as promised in their road map for their realse 26.08.[1] I'm hopeful that we can finally drop all these stupid layers of cruft trying to patch fundamentally insecure operating systems.

Tannenbaum was right, in the end, and Linus was wrong.[2]

[1] https://genode.org/about/road-map

[2] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...

[*] "Multi-level secure operating system" is the required magic phrase to allow finding articles on this subject through search engines.

Re: Memory safety absolutists

#219

Post by mikewarot »

bloaf wrote: post #11

As long as rowhammer is still out there, aint none of your memory safe. Fixing rowhammer is the memory safety absolutism I want to hear more about.

Amen, any RAM that is subject to bitflips, regardless of how it's arranged, should be rejected as a defective design. It's insane that we permit this crap to happen in the first place.

Re: Memory safety absolutists

#220

Post by pjmlp »

sirwhinesalot wrote: post #216
pjmlp wrote: post #188

Earlier quoted context omitted.

C++ has had bounds checking in standard library for ages, and on compiler specific frameworks like MFC and OWL, however plenty of devs apparently never read the compiler manuals on how to improve safety and related compiler settings. It is also relatively strange that many devs use the lacks of standardisation as an excuse to not adopt safety features in C and C++, while at the same time rush out to adopt cool toys t…

For std::string and std::vector yes, but not for std::span (until C++26) for reasons I cannot understand.

That is standardese, you get them all bounds checked by using specific compiler flags.

Here is for VC++

https://github.com/microsoft/STL/blob/2a62bf7b4079f0a3e33ec8...

You just have to define the proper iterator level for enabling bounds checking.

Other compilers have similar approaches.

I chose VC++ on purpose, because it is what I know better, and is famously trailing behind C++26 features.

Then there are the Tclass, Cclass, Qclass, from all those C++ frameworks pre C++98.

However plenty devs seem allergic to learn about how to use their compilers.

Post reply on HN