4 ms·

They typical argument given for the focus on memory related bugs is that: ‘{company,Github,bug/cve -tracker} says (following code review | testing)* that 70% o

They typical argument given for the focus on memory related bugs is that: ‘{company,Github,bug/cve -tracker} says (following code review | testing)* that 70% of reported bugs/exploits are due to memory management failures.’ I write it thusly, because I don’t actual know or remember all the various permutations I’ve seen. But a few that I can recall being mentioned would be Microsoft and Google, regarding Windows and Chrome (or it could have been the entire Google production code base). But other than these types of statements I can’t recall any support for focusing on memory vs other error kinds. This line of argument has led to developers who class memory ‘unsafe’ languages as objective moral bads (and the development of such to be inherently morally bad) [I was literally told this on HN, in the furor over the announcement of Hare Lang]. I think it’s reactions like this that lead to your usage of the word panicked, but I always try to assume the majority of developers are just using a language they enjoy and getting on with the business of making stuff. Just as a parting note: I’m not attempting to disagree with the statements by these companies, or with the general premise that memory safety errors result in problems for users of software. I’m slightly ambivalent to the whole thing. — edit for spelling

tored 3y ago
About 20 percent of all bugs in the Linux kernel are use-after-free. With that said, I think proper tooling can solve much of the problems with unsafe memory languages. Question is then, why doesn't it happen? Are developers uninformed, arrogant or just lazy? Is forcing it into the language the only way to solve this?
wredue 3y ago
I think your wording is off, because 70% of reports bugs are not memory related. I vaguely recall that 70% of *certain classes* of reported security flaws were buffer misuses (which zig handles quite nicely in releasesafe and using slices, which is recommended) Edit: Found it: 70% of security bugs were counted as safe buffer related. Note that by sticking to slices and releaseSafe, zig provides most of the same guarantees as rust in this arena. It’s unclear whether a buffer issue automatically classified a bug as a security flaw as well, as in many cases it’s simply not. For example, a memory security flaw was reported in Stockfish that was simply not a flaw. We are also discussing the Microsoft OS, which is a whole different beast than applications. Overall, meh.
- throwaway17_17 3y ago
  I probably should have substituted 70% with (some percentage big enough to attempt to draw conclusions). But I think I got the 70% from so ‘blank says 70% of exploits in our codebase are memory related’, but I could be mis-remembering. I tried to make it as broad and encompassing as I have seen the claim used in arguments for memory-safety-centric programming.
- kupfer 3y ago
  "70 percent of all security bugs are memory safety issues" (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...)
gtani 3y ago
dunno about x% of all exploits but this is a systematic attempt at count/census of 6 categories memory safety failures https://www.scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/ https://www.scattered-thoughts.net/writing/assorted-thoughts...

tored 3y ago

About 20 percent of all bugs in the Linux kernel are use-after-free. With that said, I think proper tooling can solve much of the problems with unsafe memory languages. Question is then, why doesn't it happen? Are developers uninformed, arrogant or just lazy? Is forcing it into the language the only way to solve this?

wredue 3y ago

I think your wording is off, because 70% of reports bugs are not memory related. I vaguely recall that 70% of *certain classes* of reported security flaws were buffer misuses (which zig handles quite nicely in releasesafe and using slices, which is recommended) Edit: Found it: 70% of security bugs were counted as safe buffer related. Note that by sticking to slices and releaseSafe, zig provides most of the same guarantees as rust in this arena. It’s unclear whether a buffer issue automatically classified a bug as a security flaw as well, as in many cases it’s simply not. For example, a memory security flaw was reported in Stockfish that was simply not a flaw. We are also discussing the Microsoft OS, which is a whole different beast than applications. Overall, meh.

throwaway17_17 3y ago
I probably should have substituted 70% with (some percentage big enough to attempt to draw conclusions). But I think I got the 70% from so ‘blank says 70% of exploits in our codebase are memory related’, but I could be mis-remembering. I tried to make it as broad and encompassing as I have seen the claim used in arguments for memory-safety-centric programming.
kupfer 3y ago
"70 percent of all security bugs are memory safety issues" (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...)

gtani 3y ago

dunno about x% of all exploits but this is a systematic attempt at count/census of 6 categories memory safety failures https://www.scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/ https://www.scattered-thoughts.net/writing/assorted-thoughts...