One of the key things that is important when investigating customer complaints in healthcare is that of reproducibility. Any software that we release to a site needs to either be archived so we can investigate on the same bits that went out the door or needs to be reproducible bit-for-bit when rebuilt.
Being able to freeze a Linux software image and know there is nothing that is constantly trying to update it at the merest appearance of an Internet connection is important so we can do any investigation required of us.
Or, they have released a medical device with customized Linux software and not shared the source as the license requires because it's "proprietary information".
To elaborate on the parent's point, you should not be running automatic updates because you should be running manually verified and rigorously tested updates before you push a change in a safety-critical component. This is because an update to every device containing that component introduces a correlated failure mode. If the change is bad, you risk harming or killing everybody at the same time. This is in contrast to standard hardware failures modes which are much more likely to be uncorrelated, so the chance of harming everybody at the same time is (1 / FailureRate) ^ N. If a safety-critical system requires updates and can not verified and tested in context before being deployed it is criminally irresponsible to deploy such a system. Both automatic and no updates are similarly inadequate in much the same way that even though cardboard is stronger than tissue paper, neither is an adequate bridge building material for a car-carrying bridge.
tl;dr Both no updates and automatic updates are criminally irresponsible. If you can not verify and test updates in context for an appropriate amount of time to verify safety stop before you kill somebody.
"Security updates" are for things doing all kinds of network stuff - exposing ports, running untrusted code inside sandboxes, that sort of thing. Your insulin pump should absolutely not be doing any of those things.
That is the biggest engineering challenge for these products. Having timely, effective, accurate SOUP anomaly reviews are critical to ensure that you have patches for issues in the wild, so you don't end up in a situation where you are running vulnerable software for years and years.
This is also why you see a lot of RHEL and SLES in healthcare - commitments for EOL and support timelines are key, and drive a lot of planning for device makers.
Linux has no real-time capabilities and guarantees! Maybe with some crazy patch. But recommending general Linux kernel for medical applications is dangerous. It can not even play and capture audio in RT!!
I hear this argument a lot, but the reality is that most devices that need realtime support will either be using the rt patched kernel, or be using application specific mcu's that handle real-time constraints while the Linux system just acts as the main control hub and orchestrator.
There's nothing "crazy" about the preempt-rt patch and coding your application to use the scheduler policies/priorities. Like anything else worth having in open source, it takes practice to learn or money for consultants.
Linux also doesn't constantly stream telemetry from devices that are being used in a HIPAA-bound setting unlike Windows which is going be sending everything from operational metadata to memory dumps back to Microsoft who will mine, selling and eventually leak it all.
Which is exactly the OS you choose when you when you're pushing medical data through network stacks. I could belabor the usual arguments regarding "secure by default" configurations, but I'm sure HN readers have heard them before.
Can we talk about how, in the first graphic, the "open-source distributions" that garner mention are Debian, Mint, Gentoo, and Slackware? Centos seems like a conspicuous absence.
Linux could be a good choice for some medical devices, but certainly not those where any malfunction could result in the death of a patient. Linux isn't intended to be used for fault-tolerant computer systems, as such systems use specially designed hardware and operating systems.
30 comments
[ 3.1 ms ] story [ 65.2 ms ] threadBeing able to freeze a Linux software image and know there is nothing that is constantly trying to update it at the merest appearance of an Internet connection is important so we can do any investigation required of us.
If the alternative is a medical device running in an untested configuration, that may well be worse.
Instead, updates should be verified by the manufacturer and pushed out on a schedule.
tl;dr Both no updates and automatic updates are criminally irresponsible. If you can not verify and test updates in context for an appropriate amount of time to verify safety stop before you kill somebody.
This is also why you see a lot of RHEL and SLES in healthcare - commitments for EOL and support timelines are key, and drive a lot of planning for device makers.
No thanks, i would not trust linux with my life, better take something like VXwork..that's why linux in aircraft's is just for the multimedia stuff.
The problem is that medical devices can literally kill when they malfunction (The Therac-25 is a great example https://en.wikipedia.org/wiki/Therac-25)