4 ms·

Memory management errors are just like regular bugs, but they have a disproportionate impact on security. If the security requirements are permissive, what's t

by blub 7y ago

Memory management errors are just like regular bugs, but they have a disproportionate impact on security. If the security requirements are permissive, what's the point of investing so much effort in preventing only one category of bug? There's no misconception.

pdpi 7y ago
Like I said, it's a matter of safety versus security. Use-after-free, concurrent read/writes, forgetting to acquire a lock are all problems that can crash an application or cause correctness issues. Preventing all of those falls under the "safety" heading, and is still useful in a security-permissive environment. Now, what do you mean by "investing so much effort"? At the language level, it's valuable effort that lets us achieve security in many security-conscious applications, and we get the safety for free in less security-critical environments as a knock-on. Score! From an application developer's point of view, though, you're right. It might genuinely not matter, especially if you're not otherwise motivated to learn the language (a lot of that effort is a one-off and is amortised over your lifetime as a developer, if you choose to learn it). Not all applications benefit that much from the safety guarantees, and you might just be better off not even putting in the effort of using the language if something else is a better fit for you.
jerf 7y ago
"Memory management errors are just like regular bugs" I'd have to disagree in this specific context of high-performance parallel numeric simulation. It is terribly easy for memory management errors to produce incorrect simulations that still "work" perfectly, because incorrect handling of floating point numbers will never crash the program, merely corrupt the results in arbitrary, but not necessarily easy-to-detect, ways. Bugs that cause visibly obvious incorrect answers or crash the program are far preferable to bugs that cause subtle errors. It's too easy to "correct" for a bug in a simulation by simply poking it until the buggy simulation seems to return to the behavior you expect, but two bugs don't make correct code. If you don't really care about accuracy, it may not be a big deal, though... the "shape" of these errors is very difficult to wrap one's head around and I'd still question someone working for or with me fairly hard even so if they think they don't care about accuracy and so it's OK to write code that may or may not be thread-safe.
- affyboi 7y ago
  To tack onto this point, I actually had a couple of issues where subtle memory management bugs led to slightly incorrect (not terribly incorrect) results when I was working on a graphics paper. The worst part about that was it wasn't immediately obvious that there even was an error, until much later when we realized that the results we were getting weren't consistent with what we expected. Something glaring would be if we were getting values that were zeroed out or something like that, but when the only difference is that a slope is -1.4 instead of -1.6 or something like that, you don't immediately realize something's up. Once we realized there was a bug, it took a long time to track down, and after that I was so frustrated I started writing a new library from scratch in Rust for our research and it worked out pretty well. Anecdotal evidence for sure but it was really nice not having to triple check for memory race issues.
  - blub 7y ago
    Why did it take a long time to track down the bug? You had a test case which triggered it, so in theory just running under valgrind would have been enough. Or did it not happen in that case? I'm not even gonna comment on the rewrite, that reads like an ad. :-)
  - keldaris 7y ago
    Can you elaborate a bit on how the bug worked and why Rust would have prevented it? I'm genuinely curious because the only bugs I've ever had with comparable presentation and consequences have been logic bugs which no set of language features could possibly prevent.
- mike_hock 7y ago
  As a rule of thumb, if "I don't care about memory safety and thread safety" is followed immediately by "my programs don't have memory corruption or race conditions," the latter statement is usually false.
- blub 7y ago
  Any code base which does simulations would likely have some automated testing covering a good chunk of the value domain + extremes, which lends itself very well to ASan and UBSan analysis. I don't think OP said anything about writing code that's not thread-safe. They specifically said they're carefully designing such code. What they said is that due to the way they handle memory, most related errors don't happen in practice - which is perfectly believable. Floating point errors are separate issue, they could happen in almost any language.

by blub 7y ago

pdpi 7y ago

Like I said, it's a matter of safety versus security. Use-after-free, concurrent read/writes, forgetting to acquire a lock are all problems that can crash an application or cause correctness issues. Preventing all of those falls under the "safety" heading, and is still useful in a security-permissive environment. Now, what do you mean by "investing so much effort"? At the language level, it's valuable effort that lets us achieve security in many security-conscious applications, and we get the safety for free in less security-critical environments as a knock-on. Score! From an application developer's point of view, though, you're right. It might genuinely not matter, especially if you're not otherwise motivated to learn the language (a lot of that effort is a one-off and is amortised over your lifetime as a developer, if you choose to learn it). Not all applications benefit that much from the safety guarantees, and you might just be better off not even putting in the effort of using the language if something else is a better fit for you.

jerf 7y ago

"Memory management errors are just like regular bugs" I'd have to disagree in this specific context of high-performance parallel numeric simulation. It is terribly easy for memory management errors to produce incorrect simulations that still "work" perfectly, because incorrect handling of floating point numbers will never crash the program, merely corrupt the results in arbitrary, but not necessarily easy-to-detect, ways. Bugs that cause visibly obvious incorrect answers or crash the program are far preferable to bugs that cause subtle errors. It's too easy to "correct" for a bug in a simulation by simply poking it until the buggy simulation seems to return to the behavior you expect, but two bugs don't make correct code. If you don't really care about accuracy, it may not be a big deal, though... the "shape" of these errors is very difficult to wrap one's head around and I'd still question someone working for or with me fairly hard even so if they think they don't care about accuracy and so it's OK to write code that may or may not be thread-safe.

affyboi 7y ago
To tack onto this point, I actually had a couple of issues where subtle memory management bugs led to slightly incorrect (not terribly incorrect) results when I was working on a graphics paper. The worst part about that was it wasn't immediately obvious that there even was an error, until much later when we realized that the results we were getting weren't consistent with what we expected. Something glaring would be if we were getting values that were zeroed out or something like that, but when the only difference is that a slope is -1.4 instead of -1.6 or something like that, you don't immediately realize something's up. Once we realized there was a bug, it took a long time to track down, and after that I was so frustrated I started writing a new library from scratch in Rust for our research and it worked out pretty well. Anecdotal evidence for sure but it was really nice not having to triple check for memory race issues.
- blub 7y ago
  Why did it take a long time to track down the bug? You had a test case which triggered it, so in theory just running under valgrind would have been enough. Or did it not happen in that case? I'm not even gonna comment on the rewrite, that reads like an ad. :-)
- keldaris 7y ago
  Can you elaborate a bit on how the bug worked and why Rust would have prevented it? I'm genuinely curious because the only bugs I've ever had with comparable presentation and consequences have been logic bugs which no set of language features could possibly prevent.
mike_hock 7y ago
As a rule of thumb, if "I don't care about memory safety and thread safety" is followed immediately by "my programs don't have memory corruption or race conditions," the latter statement is usually false.
blub 7y ago
Any code base which does simulations would likely have some automated testing covering a good chunk of the value domain + extremes, which lends itself very well to ASan and UBSan analysis. I don't think OP said anything about writing code that's not thread-safe. They specifically said they're carefully designing such code. What they said is that due to the way they handle memory, most related errors don't happen in practice - which is perfectly believable. Floating point errors are separate issue, they could happen in almost any language.