4 ms·

This is exactly the way I see it. I view the bar for developer responsibility to be much higher than some others do. I suspect it's because I come from the worl

This is exactly the way I see it. I view the bar for developer responsibility to be much higher than some others do. I suspect it's because I come from the world of information security where we deal very directly with the consequences of not having a higher bar. To me, the idea that a new language would be anything other than entirely memory safe, unless it is very domain specific to areas where that's not important, is just another example of developers lowering the bar. And I'm fine calling that out and being called a zealot or whatever.

verdagon 4y ago
You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains: A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this. We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side. Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
- staticassertion 4y ago
  Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that. If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much. But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
  - verdagon 4y ago
    I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
  - steveklabnik 4y ago
    Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place. Single player games maybe but they can still cause problems the end user sees.
    - staticassertion 4y ago
      Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
    - AndyKelley 4y ago
      EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. It's correctness that affects the user experience, not memory safety. From a cheating perspective, memory safety is entirely irrelevant when the game code is running on the users' computers, where they have full control over the machine code of the client, their own RAM, and the bytes being sent to the network. There are plenty of important use cases to care about memory safety, but video games executing on players' computers ain't it.
      - veber-alex 4y ago
- Ygg2 4y ago
  > games don't need memory safety if they're single player, or even multiplayer co-op against AI. I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it). So no, memory security matters even in SP games with user made content and bug. Attacker can spoof or take a user mod and exploit it for their own gains * Warcraft 3 had a really rudimentary language called JASS, however due to a way some handle convert function could leak address of objects, an entire new language stack (vJASS) was formed around it. Many maps embraced vJass. And several years later it turned out that function could be exploited.
  - unsafecast 4y ago
    > I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it). Crashes that didn't cause a lot of damage. Using a language like Rust could add way more overhead than it's worth. The GP's point was that some applications just don't require complete safety, a crash or two won't kill anyone (which could happen literally in a hospital computer for example).
    - Ygg2 4y ago
      > Crashes that didn't cause a lot of damage. Update. Crashes and RCE in fanmade maps. Looking at https://wc3we.fandom.com/wiki/Jass_Coding https://wc3we.fandom.com/wiki/Jass_Coding I found a reference to the bug being fixed in 1.24. And tracking that down lead to: https://gaming-tools.com/warcraft-3/patch-1-24/ https://gaming-tools.com/warcraft-3/patch-1-24/ One of the errors fixed: > Bug Fix: Fixed an __exploit that allowed users to execute arbitrary code__ in Warcraft 3 Funmaps. > Bug Fix: Fixed several World Editor crashes. > New JASS has table functions have been added to the Warcraft 3 World Editor, to fix unsafe type casting.(Save Item Handle, Unit Handle, Load Item Handle, Load Unit Handle, Get Handle ID). EDIT: I was right originally, game error in modded games can lead to horrible exploits.
lifthrasiir 4y ago
I think there is some similarity between information security and Rust community; there had been the elephant in the room, and they were the first to actively acknowledge and get rid of it. Since it was long neglected by others, the elimination of the elephant---vulnerability or memory bugs---can be seen as the utmost goal to some (but not all) of them. Others will complain, but as those others were mostly who neglected the elephant from the beginning, their complaints are mixed, some reasonable, some not. It's clear that this situation is far from being ideal, both for who are aware of the elephant and not, but I'm not sure how to mend this gap in understanding.

verdagon 4y ago

You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains: A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this. We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side. Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.

staticassertion 4y ago
Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that. If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much. But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
- verdagon 4y ago
  I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
- steveklabnik 4y ago
  Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place. Single player games maybe but they can still cause problems the end user sees.
  - staticassertion 4y ago
    Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
  - AndyKelley 4y ago
    EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. It's correctness that affects the user experience, not memory safety. From a cheating perspective, memory safety is entirely irrelevant when the game code is running on the users' computers, where they have full control over the machine code of the client, their own RAM, and the bytes being sent to the network. There are plenty of important use cases to care about memory safety, but video games executing on players' computers ain't it.
    - veber-alex 4y ago
Ygg2 4y ago
> games don't need memory safety if they're single player, or even multiplayer co-op against AI. I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it). So no, memory security matters even in SP games with user made content and bug. Attacker can spoof or take a user mod and exploit it for their own gains * Warcraft 3 had a really rudimentary language called JASS, however due to a way some handle convert function could leak address of objects, an entire new language stack (vJASS) was formed around it. Many maps embraced vJass. And several years later it turned out that function could be exploited.
- unsafecast 4y ago
  > I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it). Crashes that didn't cause a lot of damage. Using a language like Rust could add way more overhead than it's worth. The GP's point was that some applications just don't require complete safety, a crash or two won't kill anyone (which could happen literally in a hospital computer for example).
  - Ygg2 4y ago
    > Crashes that didn't cause a lot of damage. Update. Crashes and RCE in fanmade maps. Looking at https://wc3we.fandom.com/wiki/Jass_Coding https://wc3we.fandom.com/wiki/Jass_Coding I found a reference to the bug being fixed in 1.24. And tracking that down lead to: https://gaming-tools.com/warcraft-3/patch-1-24/ https://gaming-tools.com/warcraft-3/patch-1-24/ One of the errors fixed: > Bug Fix: Fixed an __exploit that allowed users to execute arbitrary code__ in Warcraft 3 Funmaps. > Bug Fix: Fixed several World Editor crashes. > New JASS has table functions have been added to the Warcraft 3 World Editor, to fix unsafe type casting.(Save Item Handle, Unit Handle, Load Item Handle, Load Unit Handle, Get Handle ID). EDIT: I was right originally, game error in modded games can lead to horrible exploits.

lifthrasiir 4y ago

I think there is some similarity between information security and Rust community; there had been the elephant in the room, and they were the first to actively acknowledge and get rid of it. Since it was long neglected by others, the elimination of the elephant---vulnerability or memory bugs---can be seen as the utmost goal to some (but not all) of them. Others will complain, but as those others were mostly who neglected the elephant from the beginning, their complaints are mixed, some reasonable, some not. It's clear that this situation is far from being ideal, both for who are aware of the elephant and not, but I'm not sure how to mend this gap in understanding.