Live data from Hacker News

Memory safety absolutists

itsallaboutthebit.com

181–190 of 272 posts

Re: Memory safety absolutists

#181
post #81

There 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.

That'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.

In fact codecs in particular should be written in something much stricter but more special purpose than Rust, WUFFS (Wrangling Untrusted File Formats Safely)

https://github.com/google/wuffs

WUFFS gives up generality - you can't write "Hello World" in WUFFS because it lacks both strings (for the "Hello, world" text) and I/O (for the printing it out). But you can write a codec, going from a block of bytes representing the encoded file to a block of bytes representing pixels, or PCM audio, or indeed uncompressed data [or vice versa] is easy.

But unlike Rust, all of the safety in WUFFS was checked during compilation. For example Rust emits bounds checks, arr[n] might panic at runtime if n is outside the bounds of arr, but WUFFS doesn't do that, it'll have proved mathematically that n is always in-bounds, if it can't prove that it rejects your code, make sure n is in bounds and try again.

Sometimes the end result is similar, you write code to check n at runtime, if it's a miss you report an error, WUFFS can see you met the criterion - basically the same as Rust. But often in a codec design you can just prove it's in bounds, if you implemented it correctly.

Re: Memory safety absolutists

#182

Earlier quoted context omitted.

That'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.

And how about safety of life systems? They use computers in chemical plants and on planes, you know lol. Integer overflows have a body count!

In 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/ 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.

Re: Memory safety absolutists

#183
post #166
post #88

Earlier quoted context omitted.

I don't think we should set our expectations based on an extreme outlier. qmail is special, and we can't expect most software to get to its level of security/safety. Put another way: if you have to rely on programmer skill or attention to detail in order to guarantee something, that will always be a losing bet, on average. The existence of a tiny percentage of programmers that can clear that high bar does not make it…

Splitting programs into mutually untrusting modules is a plausible alternative to memory safety in programming languages. Also in a program similar to qmail, memory safety alone is not sufficient, a lot of bugs in sendmail were related to complexity issues.

If only there was an OS design architecture that would follow such approach from the ground up....

Re: Memory safety absolutists

#184

This 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 tha…

Linked lists are cool but they are terrible for cache performance, so their apparently elegant performance characteristics are often illusory. And hybrid data structures which get you the best of both worlds are quite complicated to implement. I think that's why there's a general pressure against using them unless you have a very specific reason (and ideally some measurements) to demonstrate that they are a good opti…

Even Lisp got all major data structures relativity early on, building only on lists is mostly used for prototyping.

Re: Memory safety absolutists

#185
post #163

> 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".

Which 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.

Re: Memory safety absolutists

#186
post #58
post #16

Earlier quoted context omitted.

ffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources

Great then let's prove that ASM is correct. the reference C code is just as bad.

Which 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.

Re: Memory safety absolutists

#187

I 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 s…

The thing that has changed is that there are spaces where security is being taken more seriously, and C's memory unsafety became a deal breaker there. I do think that providing a mechanism to run existing C software that isn't performance sensitive in a way that mitigates its limitations is very worthwhile. I think the "static analysis" and the "runtime checks" approaches are complementary, not in opposition, making…

One would think that by now it would also be on WG14 roadmap for language evolution.

Same in regards to WG21, while more active in improving safety, there are plenty of politics between the profiles approach faction and everyone else.

Re: Memory safety absolutists

#188

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

C++ has had bounds checking in standard library for ages, and on compiler specific frameworks like MFC and OWL, however plenty of devs apparently never read the compiler manuals on how to improve safety and related compiler settings.

It is also relatively strange that many devs use the lacks of standardisation as an excuse to not adopt safety features in C and C++, while at the same time rush out to adopt cool toys that are specific to a single compiler.

Re: Memory safety absolutists

#189
post #185
post #163

> 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".

Which 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…

That's probably because the OS itself didn't have great defenses, right? We have permissioned virtual memory now.

Re: Memory safety absolutists

#190
post #57

Earlier quoted context omitted.

> It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications. Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code). > Why in the future? It exists and can be used right now. In fact, much of…

Bearing in mind that "there should be no room for a language above assembly and below Rust" (i.e. something like what C or C++ is to Python, Java, C#, etc.) was an intentional design decision for Rust which resulted in `unsafe`.

Actually there is, given that the reference compiler depends on C++.
Post reply on HN