[HN Gopher] Memory Safety for Skeptics
___________________________________________________________________
Memory Safety for Skeptics
Author : steveklabnik
Score : 47 points
Date : 2025-11-10 18:23 UTC (4 hours ago)
(HTM) web link (queue.acm.org)
(TXT) w3m dump (queue.acm.org)
| whobre wrote:
| Ugh. I know all that and I am still sick of hearing about memory
| safety. My teammates spend way more time fixing security issues
| in "safe" languages than C/C++/whatever. It simply doesn't
| matter...
| kazinator wrote:
| It's hard to compare the two. A low-level memory safety issue
| can intersect with security. So can a flaw in logic that
| touches on security, but is reproducible and not undefined in
| any way.
|
| The latter can often be more easily exploited than the former,
| but the former can remain undetected longer, affect more
| components and installations, and be harder to reproduce in
| order to identify and resolve.
|
| As an exmaple of "more easily exploited". Say that you have a
| web application that generates session cookies that are easy to
| forge, leading to session hijack. Not much skill is needed to
| do that, compared to exploiting a memory safety problem
| (particuarly if the platform has some layers defenses against
| it: scrambled address space, non-executable stacks, and
| whatnot).
| mrkeen wrote:
| What security issues are biting you in safe languages that
| wouldn't also appear in C/C++ ?
| bluGill wrote:
| A large number of real world security issues are attacks on
| humans not software. No programming language can solve social
| engineering problems.
| kazinator wrote:
| > _If you 're tired of hearing about memory safety, this article
| is for you._
|
| Tell me more about memory safety, any time; just hold the Rust.
|
| Rust skeptics are not memory safety skeptics. Hopefully, there
| are no memory safety skeptics, other than rhetorical strawmen.
| Yoric wrote:
| I've spoken with quite a few C++ developers who swear that they
| don't need memory safety tooling because they're good enough to
| achieve it on their own. More than a few also expect that the
| worst that can happen from breaking memory safety is a
| SEGFAULT, which also suggests that they don't understand memory
| safety.
|
| So, I'd say that there is still some outreach to do on the
| topic.
|
| On the other hand, you're absolutely right that Rust is only
| one of the many ways to get there.
| kazinator wrote:
| OK, so those are skeptics about tooling, not about memory
| safety _per se_.
|
| And not even about _tooling_ per se, since achieving safety
| on their own doesn 't literally mean on their own; they are
| relying on tooling.
|
| True Scotsman's "on your own" means working in assembly
| language, in which you have to carefully manage even just
| calling a function and returning from it: not leaving stray
| arguments on the stack, saving and restoring all callee-saved
| register that are used in the function and so on.
|
| Someone who thinks that their job is not to have segfaults is
| pretty green, obviously.
| Ar-Curunir wrote:
| > Hopefully, there are no memory safety skeptics, other than
| rhetorical strawmen.
|
| There are plenty of such skeptics. It's why Google, Microsoft,
| etc all needed to publish things like "70% of our
| vulnerabilities are memory-safety linked".
|
| Even today, the increasing popularity of Zig indicates that
| memory-safety is not taken as a baseline.
| MeetingsBrowser wrote:
| Good point. There are even two posts about Zig on the front
| page along side this post.
| AlotOfReading wrote:
| I _wish_ memory safety skepticism was nothing more than a
| rhetorical strawman. It 's not hard to find prominent people
| who think differently though. Take Herb Sutter for example, who
| argues that "memory safety" as defined in this article is an
| extreme goal and we should instead focus on a more achievable
| 95% safety instead to spend the remaining effort on other types
| of safety.
|
| I can also point to more extreme skeptics like Dan O'dowd, who
| argue that memory safety is just about getting gud and you
| don't actually need language affordances.
|
| Discussions about this topic would be a lot less heated if
| everyone was on the same page to start. They're not. It's taken
| advocates years of effort to get to the point where we can
| start talking about memory safety without immediate negative
| reactions and that process is still ongoing.
| bmurphy1976 wrote:
| I prefer to treat testing like insurance. You purchase enough
| insurance to get the coverage you need, and not a penny more.
| Anything beyond that could be invested better.
|
| Same thing with tests, get the coverage you need to build the
| confidence in your codebase, but don't tie yourself in knots
| trying to get that last 10%. It's not worth it. Create some
| manual and integration tests and move one.
|
| I feel like type safety, memory safety, thread safety, etc.
| are are all similar. Building a physics core to simulate the
| stability of your nuclear stockpile? The typing should be
| second to none. Building yet another CSV exporter? Who gives
| a damn.
|
| Context is so damn important.
| Yoric wrote:
| > Building yet another CSV exporter? Who gives a damn.
|
| The problem with memory unsafe code is that it can have
| unexpected and unpredictable side-effects. Such as subtly
| altering the critical data you're exporting, of letting an
| attacker take control of your CSV exporter.
|
| In other words, you need quite a lot of context to figure
| out that a memory bug in your CSV exporter won't be used
| for escalation. Figuring out that context, documenting it
| and making sure that the context never changes for the
| lifetime of your code? That sounds like a much complex
| proposition that using memory-safe tools in the first
| place.
| AlotOfReading wrote:
| This is a perfectly reasonable argument if memory safety
| issues are essentially similar to logic bugs, but memory
| unsafety isn't like a logic bug.
|
| A logic bug in a library doesn't break unrelated code. It's
| meaningful to talk about the continued execution of a
| program in the presence of logic bugs. Logic bugs don't
| time travel. There are ways to exhaustively prove the
| absence of logic bugs, e.g. MC/DC or state space
| exploration, even if they're expensive.
|
| None of these properties are necessarily true of memory
| safety. A single memory safety violation in a library can
| smash your stack, or allow your code to be exploited. You
| can't exhaustively defend against this with error handling
| either. In C and C++, it's not meaningful to even talk
| about continued execution in the presence of memory safety
| violations. In C++, memory safety violations can time
| travel. You typically can't prove the absence of memory
| safety violations, except in languages designed to allow
| that.
|
| With appropriate caveats noted (Fil-C, etc), we don't have
| good ways to retrofit memory safety onto languages and
| programs built without it or good ways to exhaustively
| diagnose violations. All we can do is structurally
| eliminate the possibility of memory unsafety in any code
| that might _ever_ be used in a context where it 's an
| important property. That's most code.
| smithkl42 wrote:
| If your attacker controls the data you're exporting to a
| CSV file, they can take advantage of a memory safety issue
| in your CSV exporter to execute arbitrary code on your
| machine.
|
| https://georgemauer.net/2017/10/07/csv-injection.html
| samdoesnothing wrote:
| > Take Herb Sutter for example, who argues that "memory
| safety" as defined in this article is an extreme goal and we
| should instead focus on a more achievable 95% safety instead
| to spend the remaining effort on other types of safety.
|
| I don't really see how that's a) a scepticism of memory
| safety or b) how it's not seen as a reasonable position. Just
| because someone doesn't think X is _the most important thing
| ever_ doesn 't mean they are skeptical of it, but rather that
| the person holding the 100% viewpoint is probably the one
| with the extreme position.
| kazinator wrote:
| [delayed]
| AlotOfReading wrote:
| Look at the definition quoted in the article:
| [A] program execution is memory safe so long as a
| particular list of bad things, called memory-access errors,
| never occur
|
| "95% memory safety" is not a meaningful concept under this
| definition! That's very much skepticism of memory safety
| _as defined in this article_ , to highlight the key phrase
| in the comment you're quoting.
|
| It's also not a meaningful concept within the C++ language
| standard written by the committee Herb Sutter chairs.
| Memory unsafety is undefined behavior (UB). C++ code
| containing UB has no defined semantics and is inherently
| incorrect, whether that's 1 violation or 1000.
|
| Now, we can certainly discuss the practical ramifications
| of 95% vs 100%, but even here Herb's arguments have fallen
| notoriously flat. I'll link Sean Baxter's piece on why
| Herb's actual proposals fail to achieve even these more
| modest goals as an entry point [0]. No need to rehash the
| volumes of digital ink already spilled on this subject in
| this particular comment thread.
|
| [0] https://www.circle-lang.org/draft-profiles.html
| kazinator wrote:
| It's hard to imagine that if a memory problem were reported
| to Sutter about one of his own programs, that he would not
| prioritize fixing that, over most other work.
|
| However, I imagine he would probably take into consideration
| the context. Who and what is the program for? And does the
| issue only reproduce if the program is misused? Does the
| program handle untrusted inputs? Or are there conceivable
| situations in which a user of the program could be duped by a
| bad actor into feeding the program a malicious input?
|
| Imagine Sutter wrote a C compiler, and someone found a way to
| crash it. But the only way to reproduce that crash is via
| code that invokes undefined behavior. why would Herb
| prioritize fixing that over other work?
|
| Suppose the user insists that he's running the compiler as a
| CGI script, allowing unauthenticated visitors to their site
| to compile programs, making it a security issue.
|
| How should Herb reasonably reply to that?
| edmccard wrote:
| > Take Herb Sutter for example, who argues that "memory
| safety" as defined in this article is an extreme goal and we
| should instead focus on a more achievable 95% safety
|
| I wonder how you figure out when your codebase has reached
| 95% safety? Or is it OK to stop looking for memory unsafety
| when you hit, say, 92% safe?
| vlovich123 wrote:
| I'm curious, what memory safe alternative is there for a C/C++
| codebase that doesn't give up performance?
|
| Also for what it's worth Rust ports tend to perform faster
| according to Russinovich. Part of that may be second system
| syndrome although the more likely explanation is that the
| default std library is just better optimized (eg hash tables in
| Rust are significantly better than unordered_map)
| bluGill wrote:
| Ada has been around for years. The approach to memory safety
| isn't as strong as Rust, but it is a lot strong than C or
| C++. C++ is also adding a lot of memory safety, it is a lot
| easier to bypass than it is in Rust (though I've seen Rust
| code where everything is marked unsafe), but you still get
| some memory safety if you try.
|
| All benchmarks between Ada, C, C++, and Rust (and others)
| should come down to a wash. A skilled programmer can find a
| difference but it won't be significant. A skilled C++
| programmer wouldn't be using unordered_map so it is unfair to
| point out you can use something bad.
| vlovich123 wrote:
| It has but you need spark too to avoid the runtime
| overhead. And I haven't seen adoption of Ada in the broader
| industry so I wouldn't pick it based on that. I would need
| to understand why it remains limited to industry's that
| mandate government certification.
|
| > A skilled C++ programmer wouldn't be using unordered_map
| so it is unfair to point out you can use something bad.
|
| Pretending defaults don't matter is naive especially in a
| language that is so hostile to being easy to add 3p
| dependencies (even without that defaults matter).
| BeetleB wrote:
| > A skilled C++ programmer wouldn't be using unordered_map
| so it is unfair to point out you can use something bad.
|
| C++ isn't my primary language. Pray tell - what's wrong
| with unordered_map, and what's the alternative?
| jcranmer wrote:
| std::unordered_map basically specifies a bucket-based
| hashtable implementation (read: lots of extra pointer
| chasing). Most high-performance hashtables are based on
| probing.
| littlestymaar wrote:
| > Rust skeptics are not memory safety skeptics
|
| Definitely not all of them, yes.
|
| > Hopefully, there are no memory safety skeptics, other than
| rhetorical strawmen.
|
| You'll find the reality disappointing then...
| nightpool wrote:
| There was an article about Zig on the front page just a few
| hours ago that attracted many "Why do I need memory safety?"
| comments. The fact that new languages like Zig aren't taking
| memory safety as a foundational design goal should be evidence
| enough that many people are still skeptical about its value
| eptcyka wrote:
| Rust certainly was not the first "systems programming" language
| that was memory safe, ADA was aiming for the same title and I
| think achieved it way before Rust.
| Yoric wrote:
| While Ada is a great and sadly underused language, if my memory
| serves, it's not out-of-the-box memory-safe by today's
| definitions. I seem to recall that it takes Spark to make it
| memory-safe.
| faustocarva wrote:
| > a roughly 70 percent reduction in memory-safety
| vulnerabilities.
|
| Couldn't find this in the reference text. Is it my
| interpretation? https://www.memorysafety.org/docs/memory-
| safety/#how-common-...
| burakemir wrote:
| This is a good article.
|
| Small nit: As someone curious about a definition of memory
| safety, I had come across Michael Hicks' post. He does not use
| the list of errors as definition, and argues that such a
| definition is lacking rigor and he is right. He says;
|
| > Ideally, the fact that these errors are ruled out by memory
| safety is a consequence of its definition, rather than the
| substance of it. What is the idea that unifies these errors?
|
| He then offers a technical definition (model) involving pointers
| that come with capability of accessing memory (as if carrying the
| bounds), which seems like one way to be precise about it.
|
| I have come to the conclusion that language safety is about
| avoiding untrapped errors, also known as "undefined behavior".
| This is not at all new, it just seems to have been forgotten or
| was never widely known somehow. If interested, find the argument
| here https://burakemir.ch/post/memory-safety-the-missing-def/
| tptacek wrote:
| What's important is the context in which the term is used
| today: it's specifically about security and software
| vulnerabilities, not about a broader notion of correctness and
| program reliability. Attempts to push past that have the effect
| of declaring languages like Java and Python memory-unsafe,
| which is not a defensible claim.
| pizlonator wrote:
| This article comes up with yet another definition of memory
| safety. Thankfully, it does not conflate thread safety with
| memory safety. But it does a thing that makes is both inaccurate
| (I think) and also not helpful for having a good discussion:
|
| TFA hints at memory safety requiring static checking, in the
| sense that it's written in a way that would satisfy folks who
| think that way, by saying thingys like "never occur" and
| including null pointer safety.
|
| Is it necessary for the checking to be static? No. I think
| reasonable folks would agree that Java is memory safe, yet it
| does so much dynamic checking (null and bounds). Even Rust does
| dynamic checking (for bounds).
|
| But even setting that aside, I don't like how the way that the
| definition is written in TFA doesn't even make it unambiguous if
| the author thinks it should be static or dynamic, so it's hard to
| debate with what they're saying.
|
| EDIT: The definition in TFA has another problem: it enumerates
| things that should not happen from a language standpoint, but I
| don't think that definition is adequate for avoiding weird
| execution. For example, it says nothing about bad casts, or
| misuses of esoteric language features (like misusing longjmp). We
| need a better definition of memory safety.
| tptacek wrote:
| I want to be there with you, but the definition this piece uses
| is, I think, objectively the correct one --- "memory safety",
| at least as used in things like "The Case For Memory Safe
| Roadmaps" government guidance, is simply the property of not
| admitting to memory corruption vulnerabilities.
|
| I don't see where you're seeing the article drawing a line
| between static and dynamic defenses. The article opens by
| noticing Rust isn't the first memory safe language. It is by
| implication referring to things like Java, which have dynamic,
| runtime-based protections against memory corruption.
| pizlonator wrote:
| > I want to be there with you, but the definition this piece
| uses is, I think, objectively the correct one --- "memory
| safety", at least as used in things like "The Case For Memory
| Safe Roadmaps" government guidance, is simply the property of
| not admitting to memory corruption vulnerabilities.
|
| This piece does not define memory safety as "not admitting
| memory corruption vulnerabilities". If it was using that
| definition, then:
|
| - You and I would be on the same page.
|
| - I would have a different complaint, which is that now we
| have to define "memory corruption vulnerability".
| (Admittedly, that's maybe not too hard, but it does get a bit
| weird when you get into the details.)
|
| The definition in TFA is quoted from Hicks, and it enumerates
| a set of things that should never happen. It's not defining
| memory safety the way you want.
| bgwalter wrote:
| TFA is too long, like all articles since the arrival of you
| know what. So the definitions are scattered. Here it claims:
|
| _Rust 's big step function was to offer memory safety at
| compile time through the use of static analysis borrowed and
| grown out of prior efforts such as Cyclone, a research
| programming language formulated as a safe subset of C._
|
| In other words, Rust has solved the halting problem since the
| static checking of array bounds is undecidable in the general
| case!
| Jtsummers wrote:
| > In other words, Rust has solved the halting problem
|
| No one is making that claim.
| anonnon wrote:
| It seems obvious that with hardware-level memory safety on the
| way[1], just gradually modernizing existing C and C++ codebases
| to take advantage of safer constructs (like smart pointers or
| checked arithmetic) makes much more sense than rewriting
| everything in Rust. Even better, thanks to GCC, is that you don't
| need to sacrifice any portability to take advantage of even
| bleeding-edge features, due to its front-end/back-end separation.
| Fish shell had to drop support for some platforms when it was
| rewritten in Rust[2].
|
| [1] https://community.intel.com/t5/Blogs/Tech-Innovation/open-
| in...
|
| [2] http://fishshell.com/blog/rustport/
| bgwalter wrote:
| If the 5 eye agencies recommend memory safety, can we conclude
| that they already get all their information via "AI" data
| harvesting in Office 365 and similar? What will happen to
| Pegasus? Or do they have yet unknown backdoors in Rust?
___________________________________________________________________
(page generated 2025-11-10 23:00 UTC)