3 ms·

Data-execution exploits mean that you may accidentally run code you weren't expecting to. If you have any kind of message parser taking input from an external s

Data-execution exploits mean that you may accidentally run code you weren't expecting to. If you have any kind of message parser taking input from an external system and examining it, you may be vulnerable to these types of exploits without realising it. Having the ability to mark (for example) your stack as non-executable is a simple change that can remove a whole class of problems. That is only the skimming the surface tho.

zozbot234 5y ago
Yes, this is a concern in memory-unsafe languages like C. But Rust can build memory-safe primitives with only a modest amount of runtime checking wrt. inherently unsafe operations. (Of course, having better formal models of how 'unsafe' code behaves might allow us to be a lot more rigorous in building safe primitives, such as by endowing some 'unsafe' calls with proof objects that might reify the outcome of a bounds check.)
- rcxdude 5y ago
  Defence in depth. Rust isn't completely immune to memory safety bugs, due to the need for unsafe code underlying many primitives in the language as well as soundness bugs in the compiler, it just makes them much rarer. It's well worth designing the system so it doesn't fall apart as soon as one such bug appears.
- TickleSteve 5y ago
  Rust helps, but isnt immune (e.g. stack overflows). Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that. (Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).
  - zozbot234 5y ago
    > Rust helps, but isnt immune (e.g. stack overflows). This is a good point but isn't Hubris designed to use statically bounded amounts of memory anyway, like much embedded software? AIUI, this was a key reason for keeping their design focused on synchronized requests, avoiding the hard-to-predict buffering that's needed for supporting 'async' models.
    - steveklabnik 5y ago
      Defense in depth matters. The blog post shows an example of Hubris correctly killing a task that's touching memory it's not supposed to. That "supposed to" was due to a configuration error, but configuration errors can and do happen, and maybe would not be as benign as this one was.

zozbot234 5y ago

Yes, this is a concern in memory-unsafe languages like C. But Rust can build memory-safe primitives with only a modest amount of runtime checking wrt. inherently unsafe operations. (Of course, having better formal models of how 'unsafe' code behaves might allow us to be a lot more rigorous in building safe primitives, such as by endowing some 'unsafe' calls with proof objects that might reify the outcome of a bounds check.)

rcxdude 5y ago
Defence in depth. Rust isn't completely immune to memory safety bugs, due to the need for unsafe code underlying many primitives in the language as well as soundness bugs in the compiler, it just makes them much rarer. It's well worth designing the system so it doesn't fall apart as soon as one such bug appears.
TickleSteve 5y ago
Rust helps, but isnt immune (e.g. stack overflows). Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that. (Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).
- zozbot234 5y ago
  > Rust helps, but isnt immune (e.g. stack overflows). This is a good point but isn't Hubris designed to use statically bounded amounts of memory anyway, like much embedded software? AIUI, this was a key reason for keeping their design focused on synchronized requests, avoiding the hard-to-predict buffering that's needed for supporting 'async' models.
  - steveklabnik 5y ago
    Defense in depth matters. The blog post shows an example of Hubris correctly killing a task that's touching memory it's not supposed to. That "supposed to" was due to a configuration error, but configuration errors can and do happen, and maybe would not be as benign as this one was.