13 ms·
The need for memory safety standards
- anonzzzies 2y agoUse Rust for kernel/system programming, use Lisp/Go/Java/C# for backend, use Typescript+wasm for frontend. We have everything already.
- bigtimesink 2y agoThis, but I'm getting tired of people using Rust for things that really should be in C# or Java.
- laerus 2y ago"really should be" ? "in C# or Java" ? where do you even base these claims? Do you know what C# and Java threads have that Rust doesn't? data races. And don't get me stated on the biggest paradigm failure that is OOP.
- bigtimesink 2y agoProjects I've seen at work. Projects posted on Hacker News. Data races aren't usually an issue for backend services, and modern Java/C# is multi-paradigm.
- pdimitar 2y ago[flagged]
- lostmsu 2y ago> Data races aren't usually an issue for backend services I beg to differ unless all your logic is in the database with strong isolation guarantees. Speaking of C# for backends that are using EF actively, I bet there are bugs in pretty much all of them caused by incorrect applications of optimistic concurrency.
- legulere 2y agoBoth have a garbage collection though that lead to higher developer productivity than compared to rust's affine types.
- brink 2y ago> higher developer productivity Where have you been the past 5 years? Rust developers are insanely productive. Can we put this myth to rest already? Rust being an "unproductive language" is thoroughly dis-proven.
- hello_moto 2y agoRust is the silver bullet we all been waiting for?
- ramon156 2y agoNo, that's the other end of the stick. Its en par with other languages
- hello_moto 2y agoWell, put any language against Rust and Rustaceans would argue Rust is better than those languages so ... Silver bullet no?
- chasd00 2y agoIf the word “Rustaceans” is actually in common use then rust loses by default.
- neonsunset 2y agoThere are domains where C# (and F#) productivity stems from similar reasons why writing a game in something that isn't Rust might be more productive without even sacrificing performance (or, at least, not to the drastic extent). I can give you an example: var number = 0; var delay = Task.Delay(1000); for (var i = 0; i < 10; i++) { Task.Run(() => { while (!delay.IsCompleted) { Interlocked.Increment(ref number); } }); } await delay; How would you write this idiomatically in Rust without using unsafe? To avoid misunderstanding, I think Rust is a great language and even if you are a C# developer who does not plan to actively use it, learning Rust is of great benefit still because it forces you to tackle the concepts that implicitly underpin C#/F# in an explicit way.
- cantalopes 2y ago"Use lisp for backend" lol
- pjmlp 2y agoIt worked for Yahoo early days, SISCOG, ITA Software,... Even a site called HN if you happen to know it.
- worthless-trash 2y agoIts easier and saner than you think. No massive churn, quite performant and the code i wrote 20 years ago runs without modification. Can other blub languages claim this?
- anonzzzies 2y agoWorks well, got problems with it (outside pure ignorance), pick something else; same difference to me. lol.
- NoGravitas 2y agoI do this for my personal hobby projects, but that's as much to deter use by technology enthusiasts as anything.
- pdimitar 2y agoNope, Elixir for backend. We need the BEAM VM's guarantees, not yesterday but like 20 years ago, everywhere. The language itself does not matter. But we need that runtime's guarantees!
- teeray 2y agoWhat is it specifically about the BEAM VM that positions it above, say, Go on K8S?
- BeFlatXIII 2y agoNot having to learn K8s
- pdimitar 2y agoAbility to manage tens of thousands of stateful connections without the 95th percentile requests jumping to 5 seconds. Just to start with.
- Sytten 2y agoI get the appeal, but without strong typing it's a no-go in my book. Get me an elixir with proper types and we can talk.
- pdimitar 2y agoOh I agree. The Erlang/Elixir ecosystem is in danger of Rust inventing a BEAM-like runtime and making it irrelevant.
- Nilithus 2y agoI believe they have already started this effort. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
- pdimitar 2y agoThey have but it's mostly a labor of love and it's very difficult to fit a static type system into a dynamically typed language. We already have some false positives. Happily the team is very motivated and is grinding away at them, for which we the community are forever grateful.
- tptacek 2y agoThat doesn't address existing codebases. Neither the Linux kernel nor the Chromium project is going to replace all its memory-unsafe code, so there are design challenges that need to be solved that are more complicated than "these memory-safe languages are available for your problem domain".
- gw2 2y agoWhat is your opinion on deploying C++ codebases with mitigations like CFI and bounds checking? Let us say I have a large C++ codebase which I am unwilling to rewrite in Rust. But I: * Enable STL bounds checking using appropriate flags (like `-DGLIBCXX_ASSERTIONS`). * Enable mitigations like CFI and shadow stacks. How much less safe is "C++ w/ mitigations" than Rust? How much of the "70% CVE" statistic is relevant to my codebase?
- tptacek 2y agoWe recorded an episode (there's a transcript) about this exact issue: https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/ https://securitycryptographywhatever.com/2024/10/15/a-little...
- gw2 2y agoWith due respect, the blog you have linked looks like the average Rust marketing material. It does absolutely nothing to address my concerns. I did a `Ctrl-F` and found zero hits of any of the following terms: * CFI * isoheaps or type-stable allocators * Shadow stacks (There is just a single hit of "C++"...) Ignoring the appeal to authority, I have a hard time believing that incrementally rewriting my C++ code in Rust or just writing new code in Rust ("vulnerabilities exponentially decay" and all that) is going to give me more actual security than the mitigations stated above. Most, if not all, high-profile exploits stem from out-of-bounds accesses and type confusions, which these mitigations prevent at very low cost. Thanks for replying, though.
- tptacek 2y ago
- J_Shelby_J 2y agoNah, ima use rust for all of that because I’m too lazy to manage multiple tech stacks.
- antithesis-nl 2y ago[flagged]
- fooker 2y agoHumans too!
- dmitrygr 2y ago> we suggest establishing a common framework "If you want to kill an idea, start a committee to study it, or a framework to contain and guide it" :(
- neilv 2y agoSummary: We know, we know, but don't make us rewrite everything in Rust.
- WalterBright 2y agoThe most common memory safety bug in released software is array overflow. This is easily corrected in C by adding a small extension: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html
- Gibbon1 2y agoThey could fix typeof to make it something useful. Like the ability to take the type of something and pass it around. And add slice and buffer typedefs to the standard library. Especially since they added counted_by to the language. Add a way to define a slice the points to a c string.
- ajb 2y agoYeah, but looking back at the attempts to extend C a bit for safety, the only one that seems to have got market traction is MISRA and even then it's pretty limited. D, rust, zig etc all seem to have much more buy in. There must be some reason why a new language works better here -I mean, you're basing your business off D, not a C extension, right?
- WalterBright 2y agoThis idea is just adapting the D version of it.
- ajb 2y agoThat's.. kind of my point. This mechanism has seen more adoption in a new language than in the existing language. I'm sure it would work technically - there must be some other reason why it's easier to get a new language adopted .
- EE84M3i 2y ago> The most common memory safety bug in released software is array overflow. Do you have a source for this? I thought it was use after free.
- BirAdam 2y agoBeing completely serious, people will use whatever works. If what works is written in C, people will use it. The average person seriously doesn't care what language a thing is written in. The average person cares that the software in question works. Despite being written in C, most software today works reasonably well. Is it perfect? No. Will the rusty equivalent be perfect on day 1? No.
- wmf 2y agoYeah, we know the market won't solve this. That's why people are talking about government standards.
- grandempire 2y agoWhen you can’t convince people it’s better, you need to force them to do it.
- wakawaka28 2y agoDid you forget a /s? It seems that if you can't convince a majority of programmers that your new language is good enough to learn, maybe it actually isn't as good as its proponents claim. It is likely the case that rewriting everything in a new language for marginally less bugs is a worse outcome than just dealing with the bugs.
- grandempire 2y agoI agree. I don’t think we need a government computer language force. Terry is a prophet.
- wakawaka28 2y agoMind you, the government has tried this before with Ada. Not to knock Ada but let's just say that government would ruin everything and stifle the industry. Certainly, any new regulations about anything as broad as how memory is allowed to be managed is going to strangle the software industry.
- 0xbadcafebee 2y agoHow many security holes are caused by not sanitizing inputs, as opposed to memory safety? It feels like not sanitizing inputs is what enables memory safety exploits, in addition to many other classes of security hole, yet nobody seems to talk about it. - Buffer overflow: somebody didn't sanitize the input (length of buffer). - Stack smashing: somebody didn't sanitize the input (length of input). - Format string vulnerability: somebody didn't sanitize the format string data. - Integer converstion vulnerability: somebody didn't sanitize the integer input. - SQL injection: somebody didn't sanitize the input before querying a database. - Cross-site scripting: somebody didn't sanitize input and it got submitted and executed on behalf of the user. - Remote file inclusion / Directory traversal: somebody didn't sanitize an input variable leading to a file path. ...and on, and on, and on. If people were as obsessed with input sanitization as they are with memory, I'll bet you a much larger percentage of attacks would be stopped. Too bad input sanitization isn't sexy.
- UncleMeat 2y agoSQL Injection and XSS are actually great examples of vuln classes where the winning strategy is safe APIs rather than diligent sanitization. "Just sanitize all your user inputs" is hard to do correctly because it is difficult to create automatic rules that detect every single possible violation. Prepared statements and safe HTML construction APIs plus some linters that scream at you when you use the unsafe APIs works like magic.
- bflesch 2y agoYou're correct. It's about distinction between code and data. You should simply discern between HTML elements (code) and HTML text nodes (data). Same with prepared statements: Clear distinction between SQL code vs SQL data. You just need to ensure that your data is never interpreted as code.
- 0xbadcafebee 2y ago> You just need to ensure that your data is never interpreted as code. That's sanitization. Many different languages implement this. The old-school method is "tainting" data so it can't be used as part of execution without an explicit function call to "untaint" it. Same is used for "secret" data in various programs where you don't want it leaked.
- pizlonator 2y agoSo many mentions of CHERI - both in this post and in the linked CACM article. I doubt CHERI will be the future considering how long it's been around for and how few actually successes have come out of it. Also, hilariously, Fil-C is faster than CHERI today (the fastest CHERI silicon available today will be slower than Fil-C running on my laptop, probably by an order of magnitude). And Fil-C is safer. Which sort of brings up another issue - this could be a case where Google is trying to angle for regulations that support their favorite strategy while excluding competition they don't like.
- thephyber 2y agoSorry, I’m not a C specialist. What are Fil-C and CHERI? eg. Safe subsets of C, static analysis tools, C toolsets to ensure memory safety?
- warkdarrior 2y agoCHERI is a hardware architecture and instruction set to add safety-related capabilities to processors. See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ In this context a capability means a way to track and enforce which memory area a pointer can point into. Typically this has to be coupled with a compiler which will initialize the capability for each pointer. Fil-C seems to be a C variant that adds capabilities and garbage collection. See https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
- ajb 2y agoNot really buying your thesis here: Attempts to retrofit safely to C have been around a lot longer than Cheri; fil-c is just the latest and there's no obvious reason why it should be more successful. The speed comparison with a laptop is just disingenuous. Is a device with Cheri integrated slower than one of the same class without?
- pizlonator 2y ago> Not really buying your thesis here: Attempts to retrofit safely to C have been around a lot longer than Cheri; fil-c is just the latest and there's no obvious reason why it should be more successful. Here's the difference with Fil-C: It's totally memory safe and fanatically compatible with C/C++, no B.S. The other approaches tend to either create a different language (not compatible), or tend to create a superset of C/C++ with a safe subset (not totally memory safe, only compatible in the sense that unsafe code continues to be unsafe), or just don't fully square the circle (for example SoftBound could have gotten to full compatibility and safety, but the implementation just didn't). > The speed comparison with a laptop is just disingenuous. Is a device with Cheri integrated slower than one of the same class without? Not disingenuous at all. The issue is that: - high volume silicon tends to outperform low volume silicon. Fil-C runs on x86_64 (and could run on ARM64 if I had the resources to regularly test on it). So, Fil-C runs on the high volume stuff that gets all of the best optimizations. - silicon optimization is best done incrementally on top of an already fast chip, where the software being optimized for already runs on that chip. Then it's a matter of collecting traces on that software and tuning, rather than having to think through how to optimize a fast chip from first principles. CHERI means a new register file and new instructions so it doesn't lend itself well to the incremental optimization. So, I suspect Fil-C will always be faster than CHERI. This is especially true if you consider that there are lots of possible optimizations to Fil-C that I just haven't had a chance to land yet.
- 0xbadcafebee 2y agoThis post seems a lot more informative to me: "It Is Time to Standardize Principles and Practices for Software Memory Safety" (https://cacm.acm.org/opinion/it-is-time-to-standardize-principles-and-practices-for-software-memory-safety/ https://cacm.acm.org/opinion/it-is-time-to-standardize-princ...) I am 100% in favor of industry standards to enforce safety. It should go way past just memory safety, though. Engineering standards should include practices and minimum requirements to prevent safety issues as a whole.
- dataflow 2y agoThe key to progress in a lot of cases is to do it incrementally. If you make something too hard to chew, people won't bite.
- binkHN 2y agoHappy to see the mention of Kotlin's memory safety features here; goes a bit beyond Java with its null safety, encouragement of immutability and smart casting.
- flykespice 2y agoDont forget being very strict typed too.
- ammar2 2y agoI was actually a little surprised to see that in there, I wouldn't really consider those features to be "memory safety" as I traditionally see it over Java. They don't really lead to exploitable conditions, except maybe DoS if you have poor error handling and your application dies with null pointer exceptions.
- iFire 2y agoWhy not mandate ecc ram?
- wmf 2y agoLobbying from Intel probably.
- GuB-42 2y agoIntel supports ECC, so does AMD, so why would they lobby against it? Intel uses it for market segmentation, but I don't think it is a big deal. It is just that those who build consumer-grade hardware don't want to spend 12% more on RAM for slightly less performance. Among them are essentially all ARM devices, including smartphones and Apple silicon Macs.
- wmf 2y agoDon't look at the specs for LPDDR6...
- summerlight 2y agoDoes ECC do anything with memory safety? This is about physical errors while the article is talking about software bugs. Those two are almost orthogonal.
- hinkley 2y agoI worked on a provenance system which would be so completely the wrong solution to this problem that I only bring it up because the 100,000 foot view is still relevant. I think we are eventually going to end up with some sort of tagged memory with what this is for (such as credentials) and rules about who is allowed to touch it and where it's allowed to go. Instead of writing yet another tool that won't let fields called "password" or "token" or "key" be printed into the logs, but misses "pk", it's going to be no printing any memory block in this arena, period. I also think we aren't doing enough basic things with backend systems like keeping just a user ID in the main database schema and putting all of the PII in a completely different cluster of machines, that has 1/10 to 1/100th of the sudoer entries on it of any other service in the company. I know these systems are out there, my complaint is we should be talking about them all the time, to push the Recency Effect and/or Primacy Effect hard.
- Etheryte 2y agoWhile I agree with you as a matter of an ideal, the step from one database to two is infinitely larger than from two to more. Given budget, time and engineering constraints, sticking everything in one database is by far the sanest solution for the vast majority of code out there.
- hinkley 2y agoI think microservices kind of break that wall with a herd of stampeding elephants being chased by even angrier bees. If you're still using one database in 2025, even if you wouldn't touch microservices with a ten foot pole, then you've got some problems. OLAP, KV, cache heirarchies, you aren't running a singular database, except maybe for a standalone app.
- perlgeek 2y agoPerl has had a limited data tagging system for decades now, called "taint checking". If enabled (through a command line switch), all data coming in from the outside (sockets, STDIN etc.) are "tainted", and if you e.g. concatenate a non-tainted and a tainted string, it becomes tainted. Certain sensitive operations, like system() calls or open(), raise an error when used with tainted data. If you match tainted data with a regex, the match groups are automatically untainted. It's not perfect, but it demonstrates that such data tagging is possible, and quite feasible if integrated early enough in the language.
- sixthDot 2y agowhile I agree on the idea I clearly see that instead of proposing solutions, a bag of programming languages are suggested.
- westurner 2y ago> Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture offer a complementary defense, particularly for existing code. IIRC there's some way that a Python C extension can accidentally disable the NX bit for the whole process.. https://news.ycombinator.com/item?id=40474510#40486181 https://news.ycombinator.com/item?id=40474510#40486181 : >>> IIRC, with CPython the NX bit doesn't work when any imported C extension has nested functions / trampolines >> How should CPython support the mseal() syscall? [which was merged in Linux kernel 6.10] > We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process. In addition, as outlined in our Secure by Design whitepaper and in our memory safety strategy, we are deeply committed to building security into the foundation of our products and services. > That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. Secureblue; https://github.com/secureblue/Trivalent https://github.com/secureblue/Trivalent has hardened_malloc. Memory safety notes and Wikipedia concept URIs: https://news.ycombinator.com/item?id=33563857 https://news.ycombinator.com/item?id=33563857 ... A graded memory safety standard is one aspect of security. > Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to SLSA levels, recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts. > Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.
- tailrecursion 2y agoThe article in question is published on Google's blog. Has Google resolved memory safety issues in its C++ code base? Did G port their code base to Rust or some other memsafe language? What's preventing them from doing that by themselves? What's preventing Microsoft, or Apple, or the coagulate Linux kernel team, or any other kernel team, from adopting memsafe technology or practice by themselves for themselves? The last thing we need are what are evidently incompetent organizations that can't take care of their own products making standards, or useless academics making standards to try to force other people to follow rules because they know better than everyone else. If the team that designed and implemented KeyKos, or that designed Erlang, were pushing for standardized definitions or levels of memory safety, it would be less ridiculous. At the same time, consciousness of security issues and memory safety has been growing quickly, and memory safety in programming languages has literally exploded in importance. It's treated in every new PL I've seen. Putting pressure on big companies to fix their awful products is fine. No pressure needs to be applied to the rest of the industry, because it's already outpacing all of the producing entities that are calling for standards.
- benced 2y agoThe idea that Google is "evidently incompetent" for failing to resolve memory safety issues in their decades-old, giant codebase is dumb.
- tailrecursion 2y agoIf Google has failed so far to resolve mem safety issues in their decades old giant code base, then I'd rather hear standardization ideas from someone who succeeded. If G succeeded at resolving those issues, then that's a concrete positive example for the rest of industry to consider following. They ought to lead by example. It seems like decades-old giant code bases are precisely the ones hardest to migrate to memory safety. That's where coercion and enforcement is needed most. You and I don't need to be told to start a new project in not-C++ do we? Nearly every trained programmer has been brainwashed (in a good way) with formal methods, type systems, bounds checking, and security concerns. Now those same people who champion this stuff say it isn't enough, and therefore we need to do more of the same but with coercion. That's a failure to understand the problem.
- booleandilemma 2y agoNo mention of Carbon, I see.
- pjmlp 2y agoCarbon naysayers keep forgeting to read the part it is an experimental language.
- ChocolateGod 2y agoIt's not as if an experimental label would keep Google from deploying something. We all know their lack of software testing.
- pjmlp 2y agoIt only got an initial backend like a couple of months ago. The site clearly mentions folks to use something else, if they want to write safe code today.
- omoikane 2y agoRelated: https://news.ycombinator.com/item?id=42962020 https://news.ycombinator.com/item?id=42962020 - It is time to standardize principles and practices for software memory safety (2025-02-06, 100 comments)
- thrwy18237111 2y agoHow about incentives to write safe code even in C? They do not exist. You are not rewarded for: 1) Formal proofs or careful programming. No one cares if a piece of software works quietly for years. 2) Preventing others from ruining a working piece of software. To the contrary, you will be called a gatekeeper and worse things. You are rewarded for: 1) Wild ideas, quickly and badly implemented with the proper amount of marketing. 2) Churn, "social" coding, and LGTM. 3) Ironically, if you are a security researcher, finding exploits can help, too. As above, preventing exploits in the first place is regarded as a waste of time. All of the above is true at Google. But of course they have a technical solution to a social problem. Which might catch one category of bugs at best.
- hackburg 2y ago[dead]
- NoGravitas 2y agoProgrammers will invent new languages and demand new hardware architectures rather than ~~go to therapy~~ use a garbage collector.
- hackburg 2y ago[dead]
- hackburg 2y ago[dead]