[HN Gopher] Memory safety is table stakes
___________________________________________________________________
Memory safety is table stakes
Author : comradelion
Score : 54 points
Date : 2025-06-26 19:36 UTC (3 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| timewizard wrote:
| > if it compiles, then it's correct ... or at least, will not
| contain use-after-free or other memory safety errors
|
| In a language with the `unsafe` construct and effectively no
| automated tooling to audit the uses of it. You have no guarantee
| of any significance. You've just slightly changed where the
| security boundary _might_ lie.
|
| > There is a great amount of software already written in other
| languages.
|
| Yea. And development of those languages is on going. C++ has
| improved the memory safety picture quite a bit of the past decade
| and shows no signs of slowing down. There is no "one size fits
| all" solution here.
|
| Finally, if memory safety were truly "table stakes" then we would
| have been using the dozens of memory safe languages that already
| existed. It should be blindingly obvious that /performance/ is
| table stakes.
| noisem4ker wrote:
| > It should be blindingly obvious that /performance/ is table
| stakes.
|
| I think a big part of it is just inertia.
| dwattttt wrote:
| It's been a very slow learning process trying to undo the
| "performance at every cost" mantra.
| AlotOfReading wrote:
| In a language with the `unsafe` construct and effectively no
| automated tooling to audit the uses of it.
|
| You can forbid using unsafe code with the lints built into
| rustc: https://doc.rust-lang.org/stable/nightly-
| rustc/rustc_lint/bu...
|
| Cargo allows you to apply rustc lints to the entire project,
| albeit not dependencies (currently). If you want dependencies
| you need something like cargo-geiger instead. If you find
| unsafe that way, you can report it to the rust safety dance
| people, who work with the community to eliminate unsafe in
| crates.
|
| All of this is worlds ahead of the situation in C++.
| vlovich123 wrote:
| OP is wrong that there's no tooling. All the C++ tooling that
| I'm aware of (e.g. ASAN/UBSAN/MSAN/TSAN) is still available
| on Rust. Additionally, it has MIRI which can check certain
| code constructs for defined behavior at the MIR level which,
| unlike sanitizers, validates that all code is sound according
| to language rules regardless of what would be run by
| generated assembly; this validation includes unsafe code
| which still has to follow the language rules. C/C++ doesn't
| have anything like that for undefined behavior by the way.
|
| However, if I can apply a nitpicking attitude here that
| you're applying to their argument about the ease with which
| unsafe can be kept out of a complex codebase. unsafe is
| pretty baked into the language because there's either simply
| convenient constructs that the Rust compiler can't ever prove
| safely (e.g. doubly-linked list), can't prove safely today
| (e.g. various accessors like split), or is required for basic
| operations (e.g. allocating memory). Pretending like you can
| really forbid unsafe code wholesale in your dependency chain
| is not practical & this is ignoring soundness bugs within the
| compiler itself. That doesn't detract from the inherent
| advantage of safe by default.
| AlotOfReading wrote:
| I do safety critical code. I would consider banning
| allocation (e.g. just using Core) or avoiding certain data
| structures a completely feasible strategy to avoid unsafe
| if I wanted to exclude it from my safety model. It's what
| I'm already doing in C++. The difference is that in C++, I
| can never prove the absence of undefined behavior from any
| part of the codebase, even if I review every single line.
| Even if I could, that proof might be invalidated by a
| single change anywhere.
|
| It's not easy in Rust, but it's _possible_.
| imglorp wrote:
| That's an extreme take now and maybe uncharitable. The safe
| parts of rust are simply no comparison to the whole c/c++
| world: the tooling is eliminating vast swaths of "easy" errors.
| Unsafe parts might be comparable if they're calling the same
| libraries.
|
| Industry is seeing quantifiable improvements, eg:
| https://thehackernews.com/2024/09/googles-shift-to-rust-prog...
| xvedejas wrote:
| Safe rust is a safe language. Yes, it is built upon unsafe
| rust. But I still consider Python to be a memory safe language
| despite it being built on C. I can still trust that my Python
| code doesn't contain such memory errors. Safe Rust is the same
| in terms of guarantees. That's all that anyone is claiming.
| zaphar wrote:
| Languages with unsafe don't just change where the security
| boundary lies. It shrinks the size of the area that the
| boundary surrounds.
|
| C++ has artificially limited how much it can improve the memory
| safety picture because of their quite valid dedication to
| backwards compatibility. This is a totally valid choice on
| their part but it does mean that C++ is largely out of the
| running for the kinds of table stakes memory safety stuff the
| article talks about.
|
| There _are_ dozens of memory safe languages that already exist:
| Java, Go, Python, C#, Rust, ... And a whole host of other ones
| I 'm not going to bother listing here.
| torstenvl wrote:
| All of the languages you listed are proprietary languages.
| Most of them have a single implementation. They could
| disappear tomorrow. While that's unlikely, it's a possibility
| that some will go the way of ColdFusion, and more will fade
| away like Pascal.
| umanwizard wrote:
| What does "proprietary" mean to you?
| johnfernow wrote:
| The Java language specification is open and there are
| multiple implementations. OpenJDK is the official open-
| source reference implementation, and many of the
| alternative implementations pull from upstream, but OpenJ9
| is a different JVM implementation (though does currently
| use OpenJDK's class libraries to form a complete JDK.)
|
| Before Microsoft opened-up C#, Mono was a completely
| independent alternative implementation.
|
| Python has CPython (reference open source implementation),
| but also PyPy, MicroPython and several others.
| torstenvl wrote:
| I'm not sure what you mean when you say the Java spec is
| open, but Oracle certainly took the position--and the
| Supreme Court confirmed--that they own copyright in the
| APIs.
|
| Has Oracle dedicated those to the public domain in the
| meantime? Or at least licensed them extremely
| permissively?
|
| More importantly, is there a public body that owns the
| spec?
| Jtsummers wrote:
| For C# there is the ECMA specification for it
| https://ecma-international.org/publications-and-
| standards/st...
|
| But who cares if there's a public body who owns the
| specification? The Supreme Court ruled Google's use of
| the copyrighted APIs fell within fair use. That gives,
| within the US (other countries will have other legal
| circumstances) a basis for anyone to copy pretty much any
| language so long as they steer clear of the actual
| copyrighted source code (don't copy MS's C# source code,
| for instance) and trademark violations.
| Kranar wrote:
| >the Supreme Court confirmed--that they own copyright in
| the APIs.
|
| To use your own terminology, this is clearly and
| objectively false. The US Supreme Court made no such
| finding.
|
| What the court concluded was that even if Oracle had a
| copyright on the API, Google's use of it fell under fair
| use so that making a ruling on the question of whether
| the API was protected by copyright was moot.
| zahlman wrote:
| > Most of them have a single implementation.
|
| _None_ of them have a single implementation. It only took
| a few minutes to find all the following:
|
| * https://en.wikipedia.org/wiki/Free_Java_implementations
|
| * Go has gofrontend and GopherJS aside from the reference
| implementation
|
| * Python has a whole slew of alternate implementations
| listed _on the main Python web site_ :
| https://www.python.org/download/alternatives/
|
| * C# has Mono, which actually implements the entire .NET
| framework
|
| * Rust has Rust-GCC and gccrs
| b0a04gl wrote:
| c/c++ you're in unsafe mode by default, unless you build
| guardrails yourself. rust built different: unsafe is loud,
| compiler flags it, tooling keeps count, you can gate it in ci.
| bugs don't slip in quiet.. burden of proof shifts
| nick_ wrote:
| If Rust is the language that finally overwhelms the resistance to
| memory safe languages, that's good.
|
| I think it's also important not to centre Rust alone. In the
| larger picture, Rust has a combo of A) good timing, and B) the
| best evangelism. It stands on decades of memory safe language &
| runtime development, as well as the efforts of their many
| advocates.
| tptacek wrote:
| I think it's important to keep the scope of the debate well-
| defined, because memory-safe languages completely stomped out
| memory-unsafe languages more than 20 years ago; _almost all_
| new code is written in languages that are unshowily memory safe
| (like Java and Python).
|
| We're really talking about resistance to memory safety in the
| last redoubts of unsafety: browsers and operating systems.
| Ar-Curunir wrote:
| and cryptographic code.
| olarm wrote:
| > We're really talking about resistance to memory safety in
| the last redoubts of unsafety: browsers and operating
| systems.
|
| And control systems, c++ (along with PLCs ofcourse) dominates
| in my experience from developing maritime software and there
| doesnt appear to be much inclination towards change.
| zahlman wrote:
| To be fair, there's a pretty clear difference between
| achieving memory safety with a garbage collector and run-time
| type information, versus achieving it through static
| analysis.
| tuveson wrote:
| > browsers and operating systems
|
| And the VMs for the two languages that you mentioned above
| (edit: though to be fair to your comment, I suppose those
| were initially written 20+ years ago).
| chubot wrote:
| There's also google, yandex, baidu, and bing, which are
| incredible amounts of c++ code
|
| And probably lots of robotics, defense, and other industries
|
| Granted, those aren't consumer problems, but I would push
| back on the "last redoubts".
|
| We should absolutely move toward memory safe languages, but I
| also think there are still things to be tried and learned
| noelwelsh wrote:
| Rust also didn't give up, whereas earlier languages like
| Cyclone did. This is a problem with the different incentives in
| research; once you've shown it works there is no funding for
| further development.
| jandrewrogers wrote:
| This statement seems imprecise. We've had memory-safe languages
| for decades and they are the primary programming languages used
| today e.g. Java and Python. There is no meaningful resistance
| to them.
|
| If you look at what unsafe languages are used for, it mostly
| falls into two camps (ignoring embedded). You have legacy code
| e.g. browsers, UNIX utilities, etc which are too expensive to
| rewrite except on an opportunistic basis even though they could
| be in principle. You have new high-performance data
| infrastructure e.g. database kernels, performance-engineered
| algorithms, etc where there are still significant performance
| and architectural advantages to using languages like C++ that
| are not negotiable, again for economic reasons.
|
| Most of the "resistance" is economic reality impinging on
| wishful thinking. We still don't have a practical off-ramp for
| a lot of memory-unsafe code. To the extent a lot of evangelism
| targets these cases it isn't helpful. It is like telling people
| living in the American suburbs that they should sell their cars
| and take the bus instead.
| HideousKojima wrote:
| > is like telling people living in the American suburbs that
| they should sell their cars and take the bus instead.
|
| That hasn't stopped the fuckcars/strongtowns/15 minute
| walkable cities crowd from trying anyways.
| xTachyon wrote:
| (Copied from Reddit)
|
| What they're saying is kind of true, but the example is very bad.
| bindgen already doesn't generate Rust enums for C enums exactly
| for this reason. It insteads generates const's with each
| variant's value, and the enum type is just an alias to its basic
| type (i32 or something else).
|
| This forces you to do a match on an integer, where you have to
| treat the _ case (with unreachable!() probably).
|
| I can't tell if this is the whole paper, but it seems low effort
| at best.
| Ar-Curunir wrote:
| You can just read the paper instead of making negative
| comments:
| https://patpannuto.com/pubs/schuermann2025omniglot.pdf
|
| They are in particular careful to never state that bindgen
| emits the wrong code. Maybe they could have said that bindgen
| in fact does handle this case correctly. But Omniglot seems to
| be doing a lot more than bindgen, and
| IshKebab wrote:
| Well... he does have a point. Don't demonstrate your great
| tool with an issue that the existing solution doesn't
| actually have.
| gavinray wrote:
| Where'd you find this paper link, out of curiosity?
|
| The referenced footnote, [9], leads to: https://www.usenix.or
| g/conference/osdi25/presentation/schuer...
| 0xbadcafebee wrote:
| [delayed]
___________________________________________________________________
(page generated 2025-06-26 23:00 UTC)