Hacker News Reader

Comment by throwawaylinux | Hacker News Reader

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.

View on HN

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

> 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?

> 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

> 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...

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.

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.

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.

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.

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

I didn't say you're not.

It can involve software though.

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.

Reply on news.ycombinator.com