4 ms·

Lots of real time, safety critical, and control systems rely on software and don't have mechanical or hard wired electronic interlocks or fallbacks. That doesn'

Lots of real time, safety critical, and control systems rely on software and don't have mechanical or hard wired electronic interlocks or fallbacks. That doesn't make it worse than alternatives. You could hack the firmware and make the device behave out of spec, but you could also hack the hardware. If you bypassed your voltage limiter on the board then you could blow it up too.

GTP 4y ago
And there is the crucial difference: you would need to bypass the voltage limiter on purpose, your display wouldn't be ruined by mistake just by putting a slider to the maximum possible value.
- throwawaylinux 4y ago
  It won't be ruined by mistake just by putting a slider to the maximum possible value unless you first bypass the firmware on purpose and install your own one that allows voltage limits to be disregarded.
mojzu 4y ago
I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar. But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
- throwawaylinux 4y ago
  > I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar. I meant hacking as-in messing around, poor choice of word. > But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug Hardware bugs can cause hardware damage. > For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable They're just not. The ABS, stability, and collision avoidance systems in your car can't fail safe if the software fails because the software is required to control the dynamic situation. It can't just say stop everything. Same as control software in airliners. Or industrial control and monitoring systems (although they can have mechanical interlocks in more cases, not all). And very little that can be _absolutely_ fail-safe, not even purely mechanical devices. How do you make a fail safe bridge?
  - mojzu 4y ago
    > Hardware bugs can cause hardware damage. That's true, although I think the original point was that if software can damage the hardware it's running on then that should be seen as a fault/bug, but with cost reduction/market pressures/etc. it is often ignored And fail-safe doesn't necessarily mean everything turns off because that can be just as dangerous, I take it more as a systems mindset where thought, care and attention are paid to failure conditions and making sure those outcomes pose the least risk. Again something which can often be ignored for cost or expediency reasons Perfection is probably an unattainable goal but I've been around software long enough that I wouldn't want someones safety to depend solely on one piece of software
    - throwawaylinux 4y ago
      > if software can damage the hardware it's running on then that should be seen as a fault/bug It is. And I'm still waiting to hear how that absolutely fail-safe bridge is going to work...
      - salawat 4y ago
        Easy. You set your safety factor in excess of expected everyday load. The fact is, Engineering has become the Art of specifying the worst (read: cheapest) implementation one can get away with.
        mdtusz 4y ago
        Building in a high safety factor is not a failsafe. A failsafe requires that in the event of failure, the system goes into a safe state.
iso1631 4y ago
If you're not practicing defense in depth, especially for safety critical systems, that is a big problem.
- throwawaylinux 4y ago
  I didn't say you're not. It can involve software though.
  - iso1631 4y ago
    Of course it should involve software, that's one line of defense. A problem in software should have a second line - hardware. Same the other way round, just because the hardware shouldn't allow setting a value to X, doesn't mean the software should request the setting.

GTP 4y ago

And there is the crucial difference: you would need to bypass the voltage limiter on purpose, your display wouldn't be ruined by mistake just by putting a slider to the maximum possible value.

throwawaylinux 4y ago
It won't be ruined by mistake just by putting a slider to the maximum possible value unless you first bypass the firmware on purpose and install your own one that allows voltage limits to be disregarded.

mojzu 4y ago

I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar. But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable

throwawaylinux 4y ago
> I think the argument is less related to hacking, as that would be like making something tamper proof which is a much higher bar. I meant hacking as-in messing around, poor choice of word. > But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug Hardware bugs can cause hardware damage. > For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable They're just not. The ABS, stability, and collision avoidance systems in your car can't fail safe if the software fails because the software is required to control the dynamic situation. It can't just say stop everything. Same as control software in airliners. Or industrial control and monitoring systems (although they can have mechanical interlocks in more cases, not all). And very little that can be _absolutely_ fail-safe, not even purely mechanical devices. How do you make a fail safe bridge?
- mojzu 4y ago
  > Hardware bugs can cause hardware damage. That's true, although I think the original point was that if software can damage the hardware it's running on then that should be seen as a fault/bug, but with cost reduction/market pressures/etc. it is often ignored And fail-safe doesn't necessarily mean everything turns off because that can be just as dangerous, I take it more as a systems mindset where thought, care and attention are paid to failure conditions and making sure those outcomes pose the least risk. Again something which can often be ignored for cost or expediency reasons Perfection is probably an unattainable goal but I've been around software long enough that I wouldn't want someones safety to depend solely on one piece of software
  - throwawaylinux 4y ago
    > if software can damage the hardware it's running on then that should be seen as a fault/bug It is. And I'm still waiting to hear how that absolutely fail-safe bridge is going to work...
    - salawat 4y ago
      Easy. You set your safety factor in excess of expected everyday load. The fact is, Engineering has become the Art of specifying the worst (read: cheapest) implementation one can get away with.
      - mdtusz 4y ago
        Building in a high safety factor is not a failsafe. A failsafe requires that in the event of failure, the system goes into a safe state.

iso1631 4y ago

If you're not practicing defense in depth, especially for safety critical systems, that is a big problem.

throwawaylinux 4y ago
I didn't say you're not. It can involve software though.
- iso1631 4y ago
  Of course it should involve software, that's one line of defense. A problem in software should have a second line - hardware. Same the other way round, just because the hardware shouldn't allow setting a value to X, doesn't mean the software should request the setting.