9 ms·
Memory safety absolutists
- enbugger 2mo agoFunny to see how Rust devs start to make up new labels when it turns out some language performs better then their language.
- himata4113 2mo agoMy biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software developer I feel like this is even more important because I use libraries maintained by thousands of other developers that might also use applications that have these exploits which get their systems compromised pushing malware to thousands of other developers which end up compromising even more libraries. I believe that memory safety should be the standard for software that thousands if not millions rely on and that it shouldn't be some political issue of X is better, Y is that, Z is something else. But then again, social engineering is the primary source of malware spread so I don't know.
- consumer451 2mo agoIt 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.
- himata4113 2mo agoThere are too many opensource projects that show that even with good engineering discipline humans are flawed creatures. Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired and are getting pretty damn predictable.
- deleted 2mo ago[deleted]
- inigyou 2mo agoHow many bugs in qmail though?
- himata4113 2mo agoIt had one bad cve it seems, but that's exactly what I mean. It only takes one mistake, of course you can learn and never make those mistakes again, however, that is an unrealistic expectation in software that receives hundreds of feature updates a year especially when it comes to core applications as basic as communication when it wants to support image previews, reels and whatnot.
- Brian_K_White 2mo agoThere will always be one, so "it only takes one" is meaningless and invalid. That leaves less is better than more, and any form of less is as good as any other form of less.
- deleted 2mo ago[deleted]
- inigyou 2mo agoSome Rust programs also had RCE CVEs.
- Ygg2 2mo agoSome is doing heavy misrepresentation. Latest batch of LLM's Linux had 423 vulnerabilities. Out of which 10 were Rust*. Would you prefer more or less CVEs? But it's like seat belt analogy. It's a helper not a panacea. * Granted Rust isn't in the entire kernel yet. D
- 2mo ago
- dns_snek 2mo ago> 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 more than using a certified I-beam makes someone a "Civil Engineer". What matters is that the finished structure/program meets the explicit and implicit requirements of safety, functionality, durability, cost, etc. Not to mention that complex reliable systems are usually engineered out of much less reliable components.
- inigyou 2mo agoOverall safety matters. Memory safety is just one factor. Log4Shell happened in Java, a GC language without pointer arithmetic.
- Ygg2 2mo agoWith Fil-C and Rust the memory safety shouldn't even be discussed. It should be the bare minimum. Presence of worse bugs won't make memory bugs disappear.
- pjmlp 2mo agoUsing seat belts is just one factor. People still die while wearing one, so it should not be compulsory. Is how this kind of arguments always get received by security folks.
- satvikpendem 2mo agoNecessary versus sufficient condition, as they say in philosophy.
- goalieca 2mo agoThere are engineering standards where dynamic allocation and especially garbage collectors are banned. C is actually a perfectly approved language in these cases.
- NBJack 2mo agoIf as a user you're willing to pay these library/application owners and premium to do so, by all means; this is a reasonable demand. But short of a massive campaign to educate and change minds, I can't see the average user caring enough.
- himata4113 2mo agoMy biggest gripe honestly is businesses rather than any particular opensource project, opensource projects can often get away with these issues getting caught by the many eyes looking at them before they ever make it to mainline.
- inigyou 2mo agoBut they usually don't? heartbleed should have put that idea to rest once and for all. The many eyes don't exist.
- userbinator 2mo agoYou will never change my mind.
- benj111 2mo agoSo you have a dogmatic belief, not based on evidence then.
- userbinator 2mo agoThe evidence is clear, "safety" paranoia is leading to increasing authoritarianism.
- ssokolow 2mo agoBy that simplistic logic, we should ban all seatbelts and airbags because they cause authoritarianism.
- uecker 2mo agoAs a user you should be far more worried about running up-to-date software and supply chain risks rather than zero-days related to memory safety.
- naasking 2mo agoYou wouldn't have to worry so much about running up to date software if memory safety were pervasive.
- uecker 2mo agoThis is wrong as there are many other safety issues to worry about.
- inigyou 2mo agoBut memory safety is one of the big ones.
- uecker 2mo agoMost people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks. (Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)
- Pooge 2mo ago> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1] [1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...
- leni536 2mo agoFil-C is basically an alternate ABI and libc runtime. Otherwise it is not tied to C and I see no reason it couldn't be targeted by Rust or Zig.
- yjftsjthsd-h 2mo agoIt currently is at least associated with C in the sense that it takes C code as an input. But yes, I would be very happy to see its approach applied to more languages.
- pizlonator 2mo agoYes
- sanxiyn 2mo agoI think Fil-C ABI implemented by all of C, Rust, and Zig is the future. But that would need some sort of stability for interoperation, and stabilizing ABI takes time: Rust still doesn't have one (while Swift spent enormous amount of effort to have one). Experimental implementation is probably still worth doing.
- throwlifeaway 2mo agoPizlo is not a memory safety absolutist. His rhetoric towards rust is a tactic specifically designed to draw more attention to him and his project. It is amplified by people who already had a bone to pick with rust and take joy in giving rust folk "a taste of their own medicine," so to speak. Articles like this are taking the bait.
- pizlonator 2mo agoWhat a weird take. I think the limits of Rust’s memory safety are interesting to discuss, as are the limits of Fil-C’s perf and practicality. It’s best to discuss these things rationally, rather than accusing folks of trying to draw attention
- my-next-account 2mo agoI don't think it's too weird of a take, we do things for many reasons. I get that it feels bad to have that directed at you as an accusation. It's rational to discuss the intent behind actions, but I think the parent is hinting at "so we shouldn't take what Pizlo says seriously", which isn't a good conclusion.
- throwlifeaway 2mo agoRepeatedly calling Rust "memory unsafe" and then shoving your fingers in your ears when people refute you is not "discussing the limits of Rust's memory safety". Stating that your detractors have "Fil Derangement Syndrome" is not engaging in rational discussion. > I think the limits of Rust’s memory safety are interesting to discuss, as are the limits of Fil-C’s perf and practicality. Notably absent from what you claim to be willing to discuss are the limits of Fil-C's memory safety, or the possibility that it could be less safe than Rust. What you're doing is well explained here: https://katamari64.se/posts/2026/odin-wikipedia/ https://katamari64.se/posts/2026/odin-wikipedia/
- rowanG077 2mo agoSomething that is important to me is that it's caught at compile time. A memory issue is a logic bug. Fil-c simply moves that from undefined behavior/security issue/incorrectness to a crash. That's better than what it was. But I generally don't want my programs to crash. Having memory safety at compile time is much more worthwhile imo.
- wat10000 2mo agoIt’s the exact opposite for me. Catching it at compile time is great, but the most important thing by far is that it’s caught somewhere instead of creating a security issue.
- muvlon 2mo agoAs a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.
- rowanG077 2mo agoI agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.
- Animats 2mo agoThe important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as for foo in bartab {} can usually hoist checks out of inner loops almost for free. I used to argue with the C++ committee about to when it's OK to catch an error early. If you write #define LEN 1000 int tab[LEN]; for (auto p = tab; p++; p <= LEN) { *p = 0; } that's a buffer overflow. The question is, is the compiler allowed to generate checking code which will abort the program before entering the loop? Or does it have to execute all the iterations up to the subscript error? I argued that it's legit to catch an error at the point it becomes inevitable. This leads to bikeshedding objections: "But what if a signal interrupts the loop before it runs off the end". That's why you need a language where undefined behavior has been nailed down to do this optimization properly.
- noelwelsh 2mo agoGood 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.
- kmeisthax 2mo agoI was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense. Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were stuck with languages made prior to Java - which in practice meant just C - or the one language everyone tried to staple every new programming paradigm onto, C++. In fact, part of why C++ became such an untameable beast of a language is because it became load-bearing for non-GC projects. Anything not in the ISO C++ standard was, in practice, something you just couldn't do in native code. Oh, of course you can't introspect structs in a compiled language, of course macros are useless and unhygenic, of course templates have to be monomorphized and bloat your binary size. And so the pressure for C++ to be an all-singing, all-dancing, all-dressed language grew. Rust's big story is memory safety, but the more Rust I wrote, the more I realized that the memory safety is only part of the picture. Rust has a very nicely curated selection of features that allows the language to remain understandable despite the sophistication of the compiler. Memory safety is a selling point, sure, but it is also the lubricant that makes working with those features pleasant. If you want a real complaint about Rust, it's that some features are oversimplified in ways that make certain scenarios harder and make some features way more "magic" than they should be. Have you ever tried writing Futures code without making use of the async keyword? It's nearly impossible, for several reasons; the main being that Rust's type systems cannot express self-referential borrows. This also makes returning a reference to something in an Rc or RefCell you own more difficult[0]. And there are numerous other states memory can be in that are hidden from Rust's type system. Rust can't even represent a real destructor fn. Dropping a value multiple times, or using it after it's been dropped, is explicitly forbidden; but Drop impls still can't take values out of themselves because Rust doesn't have an "owned reference" - i.e. memory you can take values from but can't deallocate. But none of this compromises memory safety - it just makes certain things harder than they should be. [0] Strictly speaking, there's an owning_ref crate that manages this; stdlib is also working on a "mapped mutex guard" type that would do the same thing without a dependency.
- deleted 2mo ago[deleted]
- hmry 2mo agoIt's annoying how many comment sections online are now just Rust vs Fil-C / Zig flamewars, and the creators of those languages are deliberately fanning the flames. I also feel there's a second dimension to the politics, where Rust is the "woke" language and C / Zig / Odin are now the "anti-woke" languages. At least, going by their most vocal online communities. I'm sure offline there's still engineering decisions being made (I hope).
- estebank 2mo agoCould you point me at the members of the Rust project doing so? I'd want to have a word with them (I'm a member of t-compiler).
- slopinthebag 2mo agoThey aren't. It's some random rust users vs the leader of the Zig project, leader of the Fil-c project, the head of community at Zig, etc. But they like to pretend there is an equivalence on the Rust side.
- hmry 2mo agoSorry for not being clear, I meant the creators of Fil-C and Zig (since those are the ones mentioned in the article)
- hitekker 2mo agoIIRC, ralfj was insinuating that Java was memory unsafe and arguing about it with experts on HN not too long ago. But I think he was coming off hot from the T-spec debacle so I understand it as him wanting to blow off steam. The most toxic Rust leaders exited from the project a few years back, though some are flaming more freely than ever, e.g., Go barely deserves to exist, “SQlite is a terrible example” etc
- ssokolow 2mo agoI remember seeing a blog post about that years ago and I probably bookmarked it but Firefox doesn't seem to have a way to search bookmarks for "Java" but not "JavaScript" and it appears "memory" wasn't part of the page title. (And it's entirely possible it was back when I ONLY saved a copy of articles of that tier of "I may need this again" via ScrapBook/WebScrapBook, I haven't yet set up the browser/indexer for those and a few quick ripgrep searches aren't turning it up.) I believe it had something to do with the JVM having some flawed semantics which couldn't be fixed without breaking compatibility with existing bytecode.
- hkalbasi 2mo agoSomeone should fire up an AI and create Fil-Rust by connecting the Fil-C llvm backend to rustc, ending this flamewar. I guess it is well within the capabilities of a Fable class model, even if the driver doesn't have experience in compiler development.
- bloaf 2mo agoAs 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.
- inigyou 2mo agoECC memory fixes rowhammer. And random bitflips. Everyone should have ECC memory, but Intel disagrees because they are greedy. My system sometimes detects a few bitflips per day.
- bloaf 2mo agoThere have been demonstrated rowhammer-based ECC bypass attacks. ECC mitigates but does not fix rowhammer.
- userbinator 2mo agoMy system sometimes detects a few bitflips per day. Perhaps you should replace your RAM, or it's a sign that you have a massive source of radiation lurking somewhere?
- inigyou 2mo agoI assumed this is just normal in DDR5 and the reason I only had motherboards with ECC to choose from. I do have quite a lot of it. It wouldn't be the first time engineers pushed something close to the unreliability limit and compensated with a mechanism to make it more reliable.
- ssokolow 2mo ago*nod* I remember an interview with Steve Gibson (author of SpinRite) 10 or 20 years ago where he was talking about how much modern-at-the-time hard drives relied on ECC to reliably achieve higher data densities when it used to be a sign of a drive going bad.
- deleted 2mo ago[deleted]
- inigyou 2mo agoI don't think you need to be an absolutist or only use memory safe languages but it's very obvious that we need to do a whole lot better than we actually do. Rewriting in Rust or any other language is one way to do that, but not a perfect one. I'll accept C++ when most C++ software has 1 in 50 chance of an RCE and not just a 1 in 50 chance of a known RCE. I think we can get there but we are not currently there. Coreutils has a good track record. Ffmpeg doesn't. They should have rewritten ffmpeg in Rust, not coreutils. There are other approaches though like formal verification.
- bpavuk 2mo agoffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources
- inigyou 2mo agoGreat then let's prove that ASM is correct. the reference C code is just as bad.
- pjmlp 2mo agoWhich is actually possible, unfortunately the industry never cared that much about strong typed assembly. See Verve OS from Microsoft Research, TAL and the origins of the Dafny language.
- inigyou 2mo agoIt's smallish snippets that implement self-contained algorithms, which should make it well within reach of direct formal proof of correctness.
- dblohm7 2mo agoThere are projects such as Halide[1] that actually allow you to achieve performance without needing to resort to asm. [1] https://halide-lang.org/ https://halide-lang.org/
- blurgrin 2mo ago> 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).
- pjmlp 2mo agoBecause it doesn't exist, I have never seen modern C++ in real life as in conference slideware. Most projects keep being full of C idioms, regardless of how much advocacy we keep pushing for.
- pornel 2mo agoChromium 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.
- smj-edison 2mo agoThis is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. The fact that I can have a LRU cache that changes what's at the front by shuffling some pointers, while still keeping stable addresses so the hash map stays stable? That's freaking cool. Atomic operations with pointers for linked lists is really slick for implementing an allocator's free list between threads. Being able to walk a live heap using a breadth first search by just... following pointers, made the elegance of Dijkstra's algorithm come alive. Now, maybe I'm only running into these algorithms because these are the problems I'm running into, but in the Rust community I consistently got the message that linked lists were a legacy data structure. In some cases they are, but when they do apply they do so brilliantly. I know working in Zig leaves plenty of room for memory unsafety. Perhaps that's a bad thing. But I'm implementing an interpreter, and these algorithms are essential for it to run fast. I really do need to be aware of where every allocation happens, and what instructions the computer is running. So for now I stick with Zig, even though I know I'm opening myself up to memory exploits.
- conradludgate 2mo agoGiven your performance concerns, I'm imagining you're unlikely to run Zig-Fil in practice, due to the GC overhead?
- smj-edison 2mo agoYeah, probably not. I wouldn't mind fuzzing it with Zig-Fil, but the interpreter (Zicl) is embedded in a larger C project that uses a lot of dynamic linking, so chances of using it in production is pretty much zero. I do have a lot of asserts that only have a small overhead, so I'll probably use ReleaseSafe most of the time, since it does catch a lot of the issues.
- afdbcreid 2mo agoI absolutely agree learning C is a good thing! In fact, there are two camps of Rust people: one that argue that you should not learn C before learning Rust, and one that argues that you should. Also, while such data structures/algorithms are rare, and more importantly, they can be written once and used many times, someone still needs to write them! Here is some online content on this side of Rust: - Learn Rust the Dangerous Way - https://cliffle.com/p/dangerust/ https://cliffle.com/p/dangerust/ - Learn Rust With Entirely Too Many Linked Lists - https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/ - The Rustonomicon - https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/
- yjftsjthsd-h 2mo ago> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security problems. Rust has less, at the cost of breaking the ecosystem. Fil-C has even less, and breaks the ecosystem. Why is the place Rust stops now suddenly good enough?
- deleted 2mo ago[deleted]
- jvuygbbkuurx 2mo agoUnsafe doesn't disable the borrow checker
- yjftsjthsd-h 2mo agoI don't follow how that impacts the argument. Rust with unsafe is certainly safer than C, but I don't see that that changes anything at hand.
- conradludgate 2mo agoI don't immediately follow how Rust breaks the ecosystem. Rust has very good C FFI support and fully supports the default C ABI. It just requires unsafe bindings.
- yjftsjthsd-h 2mo agoIn practice, my Python packages broke when they dropped the C crypto support. I'm sure it was theoretically possible to avoid that, but they didn't. And that's ecosystem breakage. (And if the fix is that I the user must go manually install or worse compile extra things, that's definitely ecosystem breakage)
- 2mo ago
- IshKebab 2mo agoRepeat after me: Rust is not just memory safe C++! Memory safety is a really big reason to use Rust, but it is very very far from the only reason. Even if Fil-C was magically zero-overhead (that is basically what CHERI is), I would still rather use Rust. Rust has so many advantages over something like Fil-C it's hard to list them. I think Fil-C is a great project but it's only really relevant if you have no choice but to use C. If you can use Rust you also get: * Compile time memory safety (Fil-C / CHERI are run-time). * A modern functional-style type system (helps prevent logic bugs). * Tree ownership (helps prevent logic bugs) * Sane toolchain (helps prevent hair loss). * Easy dependencies. * Vastly more things checked at compile time. Also I find it amusing how this post claimed it wasn't about Rust and then spent the whole time talking about it. Rust is great. I don't think that really needs to be debated any more.
- deleted 2mo ago[deleted]
- nanolith 2mo agoPersonally, I see these language fights as being a bit pointless. They are trying to optimize at the wrong layer. Unless one is working with a dependently typed language, which requires a proof assistant to discharge type checks, then it's all just a question of where you make the trade-off. Don't care about memory leaks or deadlocks as part of your soundness guarantees, but can't have GC? Use Rust. Okay with runtime overhead to verify checks? Consider fil extensions. If you want to go deeper, skip the language wars entirely. Tooling does what these languages can't do. I have had great success model checking C with CBMC. Not only does this prevent memory safety issues (including memory leaks), but this also prevents deadlocks. Bonus: you can write user contracts and invariants to verify that every execution path of a function fulfills these contracts and invariants. Kani comes close with Rust. It doesn't yet have decent concurrency support, but there is nothing that prevents this from being added in the future. The ability to write custom contracts and enforce custom invariants more than makes up for its lack of concurrency support. Similar technology could be used or adapted for Zig or C++. Use whichever language you like. Just, please look into model checking it. The technology scales just fine, once you get over the learning curve and learn how to use compositional verification.
- Shorel 2mo agoHow is this better than the GC in D?
- sanxiyn 2mo agoIt is better in a sense that D is not C or C++. Technical innovation is memory safety with high level of compatibility with existing C and C++ in practice. It is compatible enough that you can run memory safe LibreOffice with Fil-C. D doesn't do that.
- Animats 2mo agoTrying to figure out Fil-C's "inviscaps".[1] When you allocate space with Fil-C's "malloc", some additional bounds checking data precedes the space the program gets to use. Pointers are "fat pointers", with a pointer to the beginning of the buffer and a pointer to someplace within the buffer, allowing ordinary C pointer manipulation. There's much new verbiage around this. But it's roughly the same idea as GCC "fat pointers".[2][3] So it's not a new idea. It's one that's been tried several times, but never caught on. There's a performance penalty. Especially if the compiler can't hoist the checks out of loops. [1] https://fil-c.org/invisicaps https://fil-c.org/invisicaps [2] https://williambader.com/bounds/example.html https://williambader.com/bounds/example.html [3] https://www.doc.ic.ac.uk/~awl03/projects/miro/MIRO.pdf https://www.doc.ic.ac.uk/~awl03/projects/miro/MIRO.pdf
- pizlonator 2mo agoInvisicaps are not exactly fat pointers. Fat pointers show up inline in memory, which has a bunch of problems: - sizeof(void*) changes - either you let the bounds get corrupted by bad casts, unions, and other issues, or you impose restrictions that prevent unions from working compatibly, or you end up supporting unions by having issues with races, or you need special hardware. Invisicaps sidestep all of those issues
- Animats 2mo agoThe "flight pointer" looks an awful lot like a fat pointer. See the diagram at "The intuition of inviscaps" in [1]. A "flight pointer" has a pointer to the beginning of the buffer, which they call the "lower bound ptr", and a pointer to someplace within the buffer, which they call the "integer ptr". The pointer to the beginning of the buffer lets the checker find the size of the buffer, which is stored preceding the buffer. The compiler has to arrange things so that the lower bound ptr is carried around wherever a "flight pointer" goes. This is supposed to be invisible to the programmer. [1] https://fil-c.org/invisicaps https://fil-c.org/invisicaps
- pizlonator 2mo agoother implementations of fat pointers (that I’m aware of) have no distinction between flight and rest; they store what I call flight pointers in memory literally. The closest technique to invisicaps is softbound, but that has issues that invisicaps resolve (better story for races, more comprehensive safety for all of the C and C++ languages, no need for large virtual memory reservations, and lock freedom)
- deleted 2mo ago[deleted]
- pizlonator 2mo agoThe 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 the language. It’s interesting because us language designers ought to be thinking about how this could be avoided. It’s a hard problem! And that makes it fun! If you do read what I say on twitter, you’ll find praise for Rust, many concessions about Rust being faster than Fil-C, as well as a wide range of other opinions. When I point out Rust’s unsafety, I’m just citing facts. It’s interesting how doing that really seems to upset some folks. Pointing out a limitation in a technology does not imply dislike, and it’s best not to take it personally.
- Aurornis 2mo ago> I don’t dislike Rust As someone who really enjoys seeing all of the different programming languages and their approaches to different problems, it’s becoming obnoxious to hear the constant battles among people who think programming languages need to become part of your identity. The endless battles of superiority and tit-for-tat responses feel petty and distracting. It’s refreshing to get back to people who just want to try different things and experiment without making everything into a battle where each side scores points against the other.
- pizlonator 2mo agoMemory safety can be defined in more than one way, so it’s super worthwhile to figure out how to define it and what meets the definition and what doesn’t. We should do more of that as a community. It’s important stuff. Ima do my part so you’ll likely see me poke at how Fil-C does a thing that Rust doesn’t do. If you read my arguments unemotionally, I think you’ll get a deeper appreciation for Fil-C, Rust, and memory safe language design generally. What we shouldn’t do is reduce the discussion to claiming in a blog post that so-and-so “doesn’t like” such-and-such.
- 2mo ago
- inigyou 2mo agoI think the "Fil-C is safer than Rust" thing is an understandable reaction to 10 years of Rust evangelists telling people they have to use Rust otherwise they're stupid and wrong.
- NBJack 2mo agoWe can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.
- 20k 2mo agoFil-C has a large performance impact though, and it'll always be reasonably significant. Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
- sanxiyn 2mo agoMore people should use C#, to be honest.
- xboxnolifes 2mo ago> Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C# Combined with the ability to compile to a single native binary, having a solid package management solution, a fairly advanced type system, and a solid selection of nice language features. Usually you need to give up at least one of those.
- wolvesechoes 2mo ago> Combined with the ability to compile to a single native binary, having a solid package management solution, a fairly advanced type system, and a solid selection of nice language features Good to see a praise for C#.
- 2mo ago
- tptacek 2mo agoOnce 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 include design features that in any practical way admit them, they're memory safe. What always feels like is missing from these kinds of analyses is that there are lots of memory-safe programming environments. Almost every Java, Python, Ruby, Javascript, and Go program is memory safe, in the real meaning of the term. The competition to lock in and promote adoption of the "most" memory-safe language is a category error... unless you do what every language-war argument does, and redefine the term.
- pjmlp 2mo agoEven within Rust some folks do this to themselves, misusing unsafe with code that is 100% safe Rust, only to taint code that should only be called in specific cases, completely unrelated to memory safety. I never seen this happen with GC/RC languages that also support unsafe code blocks.
- mirashii 2mo agoThe 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.
- dadrian 2mo agoThere are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
- bastawhiz 2mo agoThat's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.
- procflora 2mo agoAnd how about safety of life systems? They use computers in chemical plants and on planes, you know lol. Integer overflows have a body count!
- tialaramex 2mo agoIn these applications we want what's called "Functional safety" where what we care about is that the humans are kept safe. A Memory Safe language can be useful to help achieve this, which is why https://ferrocene.dev/ https://ferrocene.dev/ exists but it's also important to have business processes to assure that what the software is supposed to do will keep the humans safe, memory safety doesn't distinguish between "Ensure the human operator is in the containment zone when a cloud of toxic vapour is released" and "Ensure the human operator is NOT in the containment zone when it is released". But for that operator this difference is crucial.
- xboxnolifes 2mo agoI kinda wish we didn't push with the term "memory safe", and instead had a push with "correct". If your software isn't memory safe, it does not work correctly. We should aim to have software that works correctly.
- quotemstr 2mo ago> And I also think it is totally fine to use Rust even if you could use a GC language like Go or Fil-C. The problem with choosing Rust over a GC language like the above (or a good one, like OCaml) isn't that it's not "fine" to use Rust, but that manual memory management is an inefficient use of developer time. That's an issue for the developer, and one he inflicts on himself, not an issue for the end-user. Both Rust and (safe) GC languages provide memory safety, after all.
- userbinator 2mo ago[flagged]
- userbinator 2mo agoFace the truth and see the reality of what you're making: better nooses to put around everyone's necks.
- inigyou 2mo agoYou should learn C and then use safe languages for serious stuff anyway.
- Panzerschrek 2mo agoThe main problem of Fil-C or similar solutions is not that they provide absolute safety with no escape hatch (unlike languages with unsafe keyword). The problem is that they provide an excuse to keep using terrible programming languages like C and C++ allowing memory safety issues in the first place.
- pjmlp 2mo agoYeah, but who's going to rewrite LLVM in Rust, which rustc relies on? Yes there is Cranelift, and?
- Panzerschrek 2mo agoIn case of such projects like LLVM C++ usage can be tolerated. But for new code or smaller codebases a better alternative should be considered. Also Fil-C can't be used for LLVM anyway, since performance and memory consumption overhead is way too much. Nobody wants clang/rustc working 4x slower and consuming 2x more memory.
- pjmlp 2mo agoYeah, unfortunately there are plenty of such projects, without alternatives. GCC, GNOME, KDE, Linux kernel, BSD variants, CUDA, RocM, OpenCL Vulkan, DirectX, Metal, GNM(X), OpenMP, OpenACC, NVN,.... Hence why somehow fixing C and C++ is also quite relevant for the upcoming decades, assuming humans still matter on the planet. Now it is going to be ARM MTE, SPARC ADI, CHERI, Fil-C, or WG14 and WG21 actually getting their act together, remains to be seen, as it is subject to governments and industry pressure, and we not destroying civilisation.
- Panzerschrek 2mo ago> GCC Isn't needed if we rewriting anything in Rust anyway. > GNOME, KDE They aren't that huge. Huge is the overall codebase of applications using them. It's relatively easy to create a native Rust GUI framework and rewrite applications needed such a framework one by one. > Linux kernel It's a good opportunity to rewrite it. Not only because modern languages like Rust are better than C, but because such a rewrite allows getting rid of old stuff present only for historical reasons. > BSD variants Aren't needed if we writing a new kernel from scratch. > CUDA, OpenCL Not a huge problem. There are dozens of GPU-related languages. Adding one more isn't that problematic. > Vulkan, DirectX, Metal They are language-agnostic (but still unsafe). One can create an implementation in something other than C.
- Mordak 2mo agoThe article points out what I think is the crux of the discussion: With Fil-C they become crashes. Errors manifest at runtime, not at compile time. I realized some time ago when I talk to people about rust, I don't really mention memory / thread safety in a security context, I mention them in a reliability context. Compile-time checks mean I basically never spend time debugging runtime crashes, and generally can count on the compiler to catch memory and thread safety issues before the program ever runs, and this saves me time and aggravation in production. I care about security, but I care more about reliability, and rust compile-time checks mean my software is reliable in a way that runtime-checked languages just aren't. This applies to lots of languages. Every time I hit a runtime crash in python, or ruby, or js I die a little inside. Even though they are memory-safe because they're garbage collected, I still waste time debugging runtime errors.
- bubblebeard 2mo agoThis made me think and reflect, thank you. Not so much about language design as how easy it is to take a defensive position on something we are comfortable with when it's challanged. This prohibits growth. When someone suggests you have been doing something the wrong way or has a new idea, it's usually better to hear them out and take what knowledge you can from them, even if they weren't actually trying to help you. Anyways, thanks again
- robalni 2mo agoI don't know if there can be any memory safe languages. Programming is always unsafe because you can always make mistakes. The best we can do is to use tools that help us avoid the common mistakes. As an example of that, the rust compiler helps the programmer to avoid many mistakes but it's still possible to use memory incorrectly and the tool is only safe as long as you use it as intended. You could say that C is safe too as long as you use it as intended and make no mistakes. The only problem is that it's hard to use it as intended and make no mistakes. So let's think about what memory safety could mean. My understanding is that a memory bug is when you use memory in an unintended way. An example of that is when you write to memory after you have deallocated it, which means after you have decided not to use it any more. No compiler or tool can make sure you don't write to or read deallocated memory, because whether it's allocated depends on what your intention is, and no compiler can read your thoughts. They can only give you a tool (like functions for allocating and deallocating memory or compiler checks) and hope that you will use that tool in a way that reflects your intention. One problem is that those tools are not always sufficient to keep track of your intentions and you may not always use them as intended. Memory allocation is relative. In a sense, no program that runs under an operating system can use deallocated memory, because when they read or write to memory that has not been mapped to the process, they crash. In a sense, even "safe" rust can use deallocated memory; let's say you have an array of 10 integers and you decide that the fifth integer should not currently be used, you have then deallocated it on a level where the available tools can not help you, but you can of course still access that memory. So again, everything is safe if you use it as intended and nothing is safe if you use it in other ways. Safety depends on how well the code matches your intentions. Remember that programming always happens in layers and no tool can cover all of them. It's not even clear what "all layers" would mean or how many there are in a program.
- Panzerschrek 2mo ago> but it's still possible to use memory incorrectly Only by misusing unsafe. Using it in regular programs actually isn't that necessary. In languages like C you have unsafe code almost in every line. > My understanding is that a memory bug is when you use memory in an unintended way Memory safety rules are more strict and formalized than you think. Memory safety issues are typically reading uninitialized memory (or strictly speaking changing observable behavior based on contents of uninitialized memory), reading/writing memory after it have been freed (free/delete call or out-of-scope going for local variables), concurrent unsynchronized memory access. > No compiler or tool can make sure you don't write to or read deallocated memory I am author of a programming language, where you can't write to or read deallocated memory, unless you misusing unsafe. > no compiler can read your thoughts But many languages more complex than C have powerful features allowing telling the compiler your about intents. At least partially. > Memory allocation is relative. In a sense, no program that runs under an operating system can use deallocated memory You are mixing two different concepts. One is memory model of the abstract machine defined by the specification of a language and other is the OS processes model. They have much in common, but there are a lot of differences. > So again, everything is safe if you use it as intended Such mindset is considered harmful, since it provides an excuse to use languages where making mistakes is easy (like C).
- sirwhinesalot 2mo agoI 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 and C++, these two absolute garbage languages (though I do have a lot of love for C, you can both love and hate something). Tools like Fil-C, hardened mallocs like SlimGuard, and other "make C safe" solutions all sacrifice absurd amounts of performance because these two moronic languages refuse to have a proper slice/span type. Use-after-free and double-free are serious problems but they're a spec of dust compared to missing bounds-checks. The low-hanging fruit is right there for the picking but everyone is worried about how to reach the fruits at the top. C++ only now in C++26 is finally adding bounds checks to the [] operator on std::span and (hilariously) is also finally adding the now mostly redundant .at() method which should have been there from day one. Clang added -fbounds-safety which is a feature that should have existed for a long time and serves as a decent stop-gap to a proper slice type. But of course, since it's not standardized, most people won't use it. What these two languages have taught us is that if you want to produce utter garbage you should make it an ISO standard. Me, personally, I find this whole discussion on memory safety amusing. Missing bounds checks are by far the biggest source of vulnerabilities and they're a problem in exactly 2 languages and those 2 languages have outright refused to do anything about it for decades. But hey, even in memory safe languages you have frameworks like log4j that had remote code execution from a format string as a feature. Is the problem memory safety specifically, or this utter cavalier attitude towards security? I'm not even suggesting something dumb like "you just gotta get good at C and then you won't have any vulnerabilities". Humans are fallible, which is why we delegate what we can to machines. I'm just pointing out the utter lack of care. People just don't care. At least do the bare minimum of effort like, I don't know, not make remote code execution a feature tied to format strings. Or provide a slice type in your language and string manipulation functions in your standard library that make use of it, preferably 20 years ago.
- SkiFire13 2mo ago> You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. Isn't this what MIRI already does?
- blub 2mo agoRustafarians do seem to be worried by Fil-C and for good reason. One of the top two issues with Rust is its cumbersome and overbearing syntax and anything which sidesteps that is automatically attractive to anyone which is worried about memory safety and doesn’t like to encode every little detail about in the type system. That’s the majority of programmers… think about it, that’s one of the big reasons people switched to GC languages which are the most popular languages. The classic Rust approach to addressing criticism of the syntax was a mix of downplaying, gaslighting and “you’re holding it wrong”. But if easy to use, reasonably ergonomic alternatives become available, I expect that most would prefer them to Rust.
- zgs 2mo agoI don't the fanaticism around memory safe languages. We've had memory safe languages for a very long time. Algol-60, the granddaddy of many modern languages, had it sixty-five years ago. Algol-60 also had other safety features that modern languages don't have - for example integer overflow safety. The real issue is that we came to accept unsafe languages and are taking a really long time to put such features back.
- inigyou 2mo agoThe real issue is effort. We accept ffmpeg because nobody tried to rewrite ffmpeg in ALGOL-60. We're happy to go through contortions to make ffmpeg or sqlite usable from Java because it's useful and not written in Java and nobody wants to rewrite it in Java.
- dom96 2mo ago> The thing is, programs that can be also written in GC powered languages, often don't need unsafe at all That's true, though it's worth noting that they do still need unsafe for the FFI. Often this is where the memory safety issues arise in GC languages. So no language is truly "memory safe".
- pjmlp 2mo agoWhich is why in some OS written in memory safe systems languages, like Burroughs, still being sold by Unisys as ClearPath MCP, any use of unsafe code blocks taints the binary. Execution is only allowed after the OS admin adds the executable to a specific process white list. This is similar to how some managed runtimes work, and the Java ecosystem is moving forwards it. Currently it only triggers a warning, however in the future JNI and Panama will be disabled by default, and like with ClearPath MCP, it is up to the person installing the application to enable the unsafe layer explicitly. Another example is the capabilities approach on WASM runtimes, here again the one executing the platform takes ownership on enabling unsafe behaviours.
- inigyou 2mo agoThat's probably because the OS itself didn't have great defenses, right? We have permissioned virtual memory now.
- pjmlp 2mo agoIt surely did, MMU were already a thing. The customers that still buy such systems, care about security as the feature above anything else. As you can see, the marketing is all about security. https://www.unisys.com/product-info-sheet/ecs/clearpath-master-control-program-mcp/ https://www.unisys.com/product-info-sheet/ecs/clearpath-mast...
- fukaiall 2mo ago> I'm hoping, though, that most of the Rust devs, who say they care about memory safety, genuinely care about making software safer, and not just criticizing languages that compete with Rust. Well I feel most of the Rust devs are there for saying shits about other languages to prove their own dumbassness.
- Hizonner 2mo agoIf I want a memory-safe, garbage-collected language, I have a ton of choices already, and many of them are safer in other ways than either Rust or anything derived from C (richer type systems make programs safer). Not to mention being prettier and more ergonomic. The huge advantage of Rust is that it's memory-safe with no GC; it makes your timing and memory occupancy much more deterministic at those times when you have to care.
- mpweiher 2mo ago"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.
- mikewarot 2mo agoWhat 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 https://genode.org/about/road-map [2] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate#Continued_dialogue 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.
- Prerti_Soni 2mo ago[flagged]
- DaveParkCity 2mo agoI'm in the (near) memory safety absolutionist camp. Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations. An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrome not only has v8 jit, but 2 different GC systems - V8's and Oilpan, plus PartitionAlloc) Which means Fil-C is an amazing tech for securing the manual-deallocator daemons and backends, but does not secure the biggest attack vector on 2 billion consumer devices. This is why i'm writing a maximally memory safe browser in dotnet where the only unsafe will be the FFI and RyuJIT underneath me. [1] I also think we have gone too long with poor operating system safety tools. I want a system based on Andrew Valencia's VSTa's hierarchial capability system. In that system protection ids are hierarchial and infinitelly narrowable without any special authority. So user.david can forge user.david.browser which can forge user.david.browser.site.ycombinator and so on. The closest we have to this today is (relatively) heavy weight virutlized containers. [1] https://unsoliciteddave.blogspot.com/ https://unsoliciteddave.blogspot.com/
- DaveParkCity 2mo agoabsolutionist => absolutist
- deleted 2mo ago[deleted]
- UltraSane 2mo agoThe C memory model is simply not practical on any modern code that is connected to the public internet. It is just too easy to write insecure software with it.
- nwah1 2mo agoCHERI seems to accomplish much of what Fil-C does, in-hardware. And removes some of the trust from the entire build toolchains in your entire supply chain, because memory-unsafety cannot be stealthily inserted.
- Suzuran 2mo agoYou guys are missing the point entirely. Absolutionism is not about being right, it's about everyone else being wrong and therefore deserving of abuse.
- fmajid 2mo agoMemory safety cosplayers, more like.