unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.
This isn't how people seriously approach memory safety.
Memory safety is a critical starting point, because without it you can no longer trust the logic you wrote in your program to behave in any particular bounded way. Memory safety bugs undermine everything else.
Right, but a memory unsafety but is what takes a harmless logic bug in an image parser with no filesystem access to an RCE and sandbox escape.
Memory unsafety allows you to change the 'category' of the bug, you become free to do whatever whereas a logic bug forces to to work within the (flawed) logic of the original program.
as someone who's pretty much only written high level languages and doesn't really know what they're talking about, doesn't memory safety generally refer to referencing data you shouldn't (things like buffer overruns?)
I'm not sure I understand what you're saying. It sounds like you're claiming that a static guarantee that you can't cause memory unsafety is insufficient for a memory model to be memory safe, but I suspect I've misunderstood.
Memory safety is valuable! I wouldn't want to implement anything in a memory-unsafe language if I could avoid it, and, thanks to Rust, I can virtually always avoid it now. There's ways to make bugs easier to chain and exploit, and memory unsafety is a big one.
But, while I know nothing is a panacea, memory safety is especially not a panacea. We have over a decade worth of experience with software built principally in memory-safe languages; it's hard to find a modern web application --- increasingly, it's even hard to find a modern mobile application --- built in a language as bad as C. And, as you know, all these memory-safe applications are riddled with vulnerabilities. They don't have memory corruption vulnerabilities, but I'm still game-over'ing app pentests, and very unhappy with myself when I can't.
I think you have a missunderstanding on what memory safety is.
Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.
(To be clear: "memory safety" doesn't mean "freedom from memory leaks", it covers things like buffer overflows and use-after-free violations, https://en.wikipedia.org/wiki/Memory_safety .)
I don't think you understand what memory safety means. Please look it up.
It's independent of how you write or design your program. It's a property of the language + runtime combination.
(Folks out there downvoting me: you could do with some education too... Parent is a completely ignorant (in the best possible sense - easily fixed) comment.)
reply