3 ms·

Aside from the massively misleading HN title, I don't see the point of replacing one machine language with another machine language. Even if the latter is a vi

Aside from the massively misleading HN title, I don't see the point of replacing one machine language with another machine language. Even if the latter is a virtual machine language. The microcontrollers you would use this on (i.e. not the absolute bottom end, which would be too slow for a VM) may not have a MMU, but they do have a MPU. That's enough to get process isolation. And implementing relocation to load an ELF image isn't rocket science. Also, I'd like to point out the billions of embedded systems implementing safety critical functions like huge industrial robot controls, or the brakes in your car. They're all built (and certified) without a VM. As a matter of fact, the VM would probably make them fail certification, unless it is specified and verified itself to a very fine degree.

scoutt 5y ago
> billions of embedded systems implementing safety critical functions I realize that there is a pattern: when high-level programmers talk about security and reliability, they basically mean "hackers breaking your system to steal your passwords". To the point that memory bugs = security vulnerabilities, and nothing else. This, of course, has another meaning for embedded.
- segfaultbuserr 5y ago
  For application development, a memory corruption bug or a race condition is a safety issue that causes data corruption, and when the same corruption can be used to compromise the system, it's a security issue, as you said, often there's no point to distinguish them. In the embedded world, this distinction can be important. If a vendor says its microcontrollers have safety features, it means an elaborate system of watchdog timers, glitch-filtered inputs, and checksums. On the other hand, "a microcontroller with security features" means a crypto engine and secure key storage memory.
  - scoutt 5y ago
    I agree with what you wrote. > there's no point to distinguish them I think the distinction should be clearly made when someone wants to sell me something like Rust. They come up with the daily link about 70% of the bugs are memory issues plus something in the lines of "memory vulnerabilities! think about the hackers! exploits!", when it's clear that these arguments don't click in (many areas of) embedded. Safety and security have another meaning. The steal of a password is the least of my fears, if I think a bad implementation of mine can chop-off the hand of an operator.
    - eqvinox 5y ago
      The distinction is made quite clearly, one is safety, the other is security :) (while the terms are intermixed in general discourse, both the embedded and security worlds consistently separate the two, at least in everything I've seen)
baybal2 5y ago
Indeed, And VM == bye bye JTAG debugging, which makes it DOA for most developers past the Arduino level.
pjmlp 5y ago
Thanks to MISRA-C and highly certification procedures. Yet don't put too much trust into them. https://hackaday.com/2016/10/24/toyotas-code-didnt-meet-standards-and-might-have-led-to-death/ https://hackaday.com/2016/10/24/toyotas-code-didnt-meet-stan...
- eqvinox 5y ago
  I don't think there's all that many safety issues resulting from MISRA-C non-adherence that would be fixed by putting the entire thing on top of a VM. Also, I'd wager almost all issues that a VM can catch are also caught by using a safer language, e.g. Rust (without a VM.) That said, the really bad safety issues in a car are probably on a much higher semantic level, i.e. "at X level of braking, do Y", which neither a VM nor a safer language like Rust could catch.
- buescher 5y ago
  Apparently Toyota followed their own internal standards, the code met them, and no bug that would cause unintended acceleration has ever been found. I still wouldn't advocate for the problems that Barr and Koopman savaged as expert witnesses in the lawsuit, but Toyota was held to an extremely high standard in court. https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRU...

scoutt 5y ago

> billions of embedded systems implementing safety critical functions I realize that there is a pattern: when high-level programmers talk about security and reliability, they basically mean "hackers breaking your system to steal your passwords". To the point that memory bugs = security vulnerabilities, and nothing else. This, of course, has another meaning for embedded.

segfaultbuserr 5y ago
For application development, a memory corruption bug or a race condition is a safety issue that causes data corruption, and when the same corruption can be used to compromise the system, it's a security issue, as you said, often there's no point to distinguish them. In the embedded world, this distinction can be important. If a vendor says its microcontrollers have safety features, it means an elaborate system of watchdog timers, glitch-filtered inputs, and checksums. On the other hand, "a microcontroller with security features" means a crypto engine and secure key storage memory.
- scoutt 5y ago
  I agree with what you wrote. > there's no point to distinguish them I think the distinction should be clearly made when someone wants to sell me something like Rust. They come up with the daily link about 70% of the bugs are memory issues plus something in the lines of "memory vulnerabilities! think about the hackers! exploits!", when it's clear that these arguments don't click in (many areas of) embedded. Safety and security have another meaning. The steal of a password is the least of my fears, if I think a bad implementation of mine can chop-off the hand of an operator.
  - eqvinox 5y ago
    The distinction is made quite clearly, one is safety, the other is security :) (while the terms are intermixed in general discourse, both the embedded and security worlds consistently separate the two, at least in everything I've seen)

baybal2 5y ago

Indeed, And VM == bye bye JTAG debugging, which makes it DOA for most developers past the Arduino level.

pjmlp 5y ago

Thanks to MISRA-C and highly certification procedures. Yet don't put too much trust into them. https://hackaday.com/2016/10/24/toyotas-code-didnt-meet-standards-and-might-have-led-to-death/ https://hackaday.com/2016/10/24/toyotas-code-didnt-meet-stan...

eqvinox 5y ago
I don't think there's all that many safety issues resulting from MISRA-C non-adherence that would be fixed by putting the entire thing on top of a VM. Also, I'd wager almost all issues that a VM can catch are also caught by using a safer language, e.g. Rust (without a VM.) That said, the really bad safety issues in a car are probably on a much higher semantic level, i.e. "at X level of braking, do Y", which neither a VM nor a safer language like Rust could catch.
buescher 5y ago
Apparently Toyota followed their own internal standards, the code met them, and no bug that would cause unintended acceleration has ever been found. I still wouldn't advocate for the problems that Barr and Koopman savaged as expert witnesses in the lawsuit, but Toyota was held to an extremely high standard in court. https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRU...