3 ms·

Generally higher level programmer here (Elixir), who has been dabbling with Zig lately (goal is to write an Elixir type checker!). It's quite refreshing, intere

Generally higher level programmer here (Elixir), who has been dabbling with Zig lately (goal is to write an Elixir type checker!). It's quite refreshing, interesting, and dare I say it, fun! I realize it doesn't have the same memory safety guarantees as rust, but what I don't quite understand, is what sort of danger that means I'm inviting these days. If my app doesn't deal with anything particular sensitive, do I need to worry about it too much? Am I inviting trouble for my users? I read Smashing the Stack for Fun and Profit back in the day, and I know that at one point, poorly behaving low level programs could escalate privileges, reach into other programs' memory and so forth. But is that still relevant these days? I'd think OSes have gotten better about sandboxing programs and such. I know I've seen misbehaving programs segfault before, which I thought was the OS protecting against wayward memory access. And "memory safety" really doesn't apply if targeting wasm, right? In that case Zig could really shine, since its great for cross compilation and really has memory allocations handled well, and doesn't need a GC, without the "memory safety" downsides. I guess my question is how much rust's "memory safety" is kind of an XY problem? In what cases is that actually what I should be asking for, compared to the more general question of program correctness? I can see it in rust's original use case of a web browser, since, e.g., tabs shouldn't access each other, but does it apply to all "system" or low level programming use cases?

gnuvince 6y ago
Many organizations have independently converged on memory safety being responsible for roughly 70% of vulnerabilities. So yes, still relevant and still a problem for users. https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
roca 6y ago
Partitioning memory-unsafe code into lots of little OS or WASM sandboxes each running with least-privilege would be interesting, but I think it would get really costly at runtime and at development time, because they all have to have disjoint address spaces one way or another and managing the privileges gets crazy. We don't see people actually doing this in practice (although some WASM people are thinking about it). You would have to be very aggressive about making the partitioning as fine as necessary, otherwise memory unsafety leads to privilege escalation. For example if memory unsafe code in a single sandbox can download arbitrary PDFs and render them, then a malicious PDF will be able to scan scan local networks and exfiltrate data.

gnuvince 6y ago

Many organizations have independently converged on memory safety being responsible for roughly 70% of vulnerabilities. So yes, still relevant and still a problem for users. https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

roca 6y ago

Partitioning memory-unsafe code into lots of little OS or WASM sandboxes each running with least-privilege would be interesting, but I think it would get really costly at runtime and at development time, because they all have to have disjoint address spaces one way or another and managing the privileges gets crazy. We don't see people actually doing this in practice (although some WASM people are thinking about it). You would have to be very aggressive about making the partitioning as fine as necessary, otherwise memory unsafety leads to privilege escalation. For example if memory unsafe code in a single sandbox can download arbitrary PDFs and render them, then a malicious PDF will be able to scan scan local networks and exfiltrate data.