I don't care about memory safety (2023)
linkedin.com
linkedin.com
This is an excellent article that's about completely different issues that's much deeper and more interesting than that headline implies.
Well - now I'm not gonna read it twice as hard.
This is not true. You can have formally verified programs in a non-memory safe language.
The author is mixing discussions of memory-safe languages vs memory-safe programs.
They make this "anti-distinction" because they actually want to run both kinds of programs (w/ and w/o compile-time memory guarantees) in a sandbox that itself provides the memory-safe guarantees. Of course, they will sell you that sandbox.
But who wrote the sandbox, and and here we are: what are its guarantees conditioned on:
> You can take for granted the fact that any out-of-bounds access and any use-after-free will trap. And that means that you can share an object with another compartment by passing it a pointer. You can rely on the fact that, if you pass another compartment a pointer to an on-stack object (or any pointer that you've explicitly marked as ephemeral), any attempt to capture that pointer will trap. You can share a read-only view of a buffer, by providing a pointer without write permission, or of a complex data structure by providing one without transitive write permission.
So, forgive my ignorance, but this is great for _your_ code, but not helpful for the code of others. They could still read the data from a buffer the not-so-safe code used to copy the data you sent to it, and no amount of "marking it ephemeral" can save you unless somehow the safety is transitory. This doesn't seem possible.
> vacuum-cleaner model of software development': point your vacuum cleaner at the Internet, vacuum up all of the components you need, and ship them. Only now you can audit exactly what each of those third-party components has access to. Because even assembly code has to follow the core rules for memory safety, you can write policies about what they should be able to access and audit them before you sign a firmware image.
Yeah - find. You allow openssl to see your data, then component X is exploited and reads data from an openssl _copy_ of that data. right?
But you can't have formally verified libraries in a non-memory safe language; or rather, when you use such a library in a non-memory safe language, the proofs don't carry over because the ambient program may break the underlying assumptions at any point in execution.
It doesn't matter if the library carefully tracks its buffers if the main program can accidentally overwrite the library's book-keeping structures between two calls into the library.
Hardware addition is filled with edge cases that cause it to not work as expected; I don't see it as that much different from the memory safety edge cases in most programming models. So by corollary is there no way to reason about any program that uses hardware addition?
I am not aware of a single case where integer addition does not work as expected at the hardware level. Of course if you have a different expectation than what the hardware does it could be called "unexpected", but I would classify this more as "ignorance". I think we can reword it as "addition must be predictable and consistent".
This is not the case in standard C, because addition can produce a weird value that the compiler assumes obeys a set of axioms but in fact doesn't, due to hardware semantics. Most C compilers allow you to opt into hardware semantics for integer arithmetic, at which point you can safely use the result of addition of any two integer values. That is really the crux of the matter here - if I write "a = b + c", can I safely examine the value "a"? In C, you cannot. You must fist make sure that b and c fulfil the criteria for safe use with the "+" operator. Or, as is more usual, close your eyes and hope they do. Or just turn on hardware semantics and only turn them off for specific very hot regions of the code where you can actually prove that the input values obey the required criteria.
That's the difference between something being safe and local but perhaps it's unexpected because you lack the knowledge about how it works, and something being unsafe because there is absolutely no way to know what will happen and the consequences can be global.
On the same hardware, yes, but the same C or C++ program may behave differently on different hardware specifically because the C abstract machine doesn't define what's supposed to happen. This leaves it up to (to your point) the compiler or the hardware what happens in, e.g., an overflow condition.
If you're planning on running the program on more than one CPU revision then I'd argue it introduces a similar level of risk, although one that's probably less frequently realised.
Undefined behavior really does mean that the program does not have valid semantics. There is no proper interpretation of how the program is to behave if signed overflow happens. It's not simply that the interpretation of the program is beyond the language and left to the hardware or the operating system, it's that the program's behavior is undefined.
This is only true in certain contexts isn’t it?
I seem to recall reading recently that some very high percentage of web security holes are caused by insecure exposed functions.
"Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues"
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
[1] https://www.chromium.org/Home/chromium-security/memory-safet...
This doesn’t gel with the hive mind though, so you probably won’t see it pop up terribly often.
And yet the memory safety advocates everywhere are waving that number around like 70% of all security issues are caused by memory safety.
I note Chromium project also says "The Chromium project finds that around 70% of our serious security bugs are memory safety problems." https://www.chromium.org/Home/chromium-security/memory-safet...
Then you get headlines like this: "Microsoft: 70 percent of all security bugs are memory safety issues", which is flat out wrong and contradicts itself the first line of the article.
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
The HN post that we are commenting on even says "To me, the fact 70% of security vulnerabilities arise from a lack of memory safety is not the reason that memory safety is important." which is also false and certainly needs clarification.
What was it before? SQL injection?