On 3/24/21 6:00 AM, Konrad Rosenbaum wrote:
Hi,
[this is getting a bit off-topic, but anyway...]
On 23/03/2021 16:43, Roland Hughes wrote:
The OpenSource community was blind, deaf, and dumb when they railed
against Tivo locking down their devices and came up with all of these
poisoned pills in OpenSource licenses mandating users be able to
modify the software.
In medical devices, that's illegal.
In industrial control systems where SAFETY is mandated, that's illegal.
This is not exactly true. Modifying software of a medical or safety
critical device is not illegal, it just revokes your right to use the
device in its critical function because it no longer follows regulations.
According to the FDA approved training I had to go through on this
matter it is illegal. Modifying the device and leaving it where it
"could" be used ranges from criminal trespass with intent (whatever that
is) to attempted manslaughter.
To be clear, it depends on several things:
1) The class of device. I'm speaking mostly of Class II and Class III
2) If the device was subject to 510K
https://www.fda.gov/media/99785/download
3) How honked off the FDA is and how good the A.G. lawyer.
https://www.enzyme.com/resources/intro-to-qms
I hate Web pages that won't let me scrape one line. Search for illegal.
It's illegal to launch a product without a QMS in place. They can take
it to the extreme and say you are launching your own product by
modifying an FDA approved product subject to 510K approval process thus
giving the false impression your product has FDA approval.
They are using much the same approach with drug distributors who receive
one IV bag of a super high priced drug, cut it with
saline/water/whatever into 2, 5, 7+ bags and sell it as pure.
I will cede the point that the FDA training was most likely pushing the
extreme to strike fear of God so nobody working in the industry tried
it. At best it is a very expensive legal rats nest.
Keep in mind that 99.9% of devices that were targeted by the
anti-tivoization clauses were actually very Tivo-like: smart TVs, HiFi
devices, mobile phones, smart buttons, cheap internet routers, etc.
They brought a shotgun to what should have been a knife fight.
It is possible to use software with an anti-tivo license in critical
systems, it just requires you to use your brain before deploying it in
your device.
Actually no. Scroll back through the archive, or perhaps the EU medical
device person I had a conversation with some months back will chime up.
The anti-tampering/cyber security regulations which are deservedly
getting more strict, not more permissive, forbid anyone modifying the
device software. You have to make it physically impossible to alter the
software without breaking the device and not having special
not-easily-replicated tools
OR
you have to do what they were doing with checksums compiled into the OS
kernel so the device refused to book if any one checksum didn't match.
Question is whether you wouldn't want to use something else
anyway, because you need hard, certified real time capabilities.
Were that the case, nobody could use Qt.
Devices are in layers.
If I skip a step or fluff a definition I hope others currently working
FDA/EU regulated correct it. Qt had a big place in this market so junior
developers surfing through the archive should get the correct picture.
Bare metal: out at the very end of the device, nearest to something that
operates. Probably burned rather than flashed in final product version.
This has to be deterministic. No dynamic memory allocation, free,
network, etc. No matter what is going on in the system the exact same
command takes the exact same amount of time. Nothing can block it.
RTOS: All of the safety critical interaction with physical/logical
device operations occur at this next higher level. Must be
deterministic. No dynamic memory allocation/free. This has its own
processor and RAM allocation if not own RAM. Someone needs to clarify. I
__believe__ network activity is formally not allowed at this level. It
__might__ be that nobody does it as an industry standard. I don't
generally work at this level. All of the designs I've worked on have
messaging system between this level and a different OS where UI and
networking happen.
COMM Module: Pretty much standard in most new designs. Usually its own
hunk of programmed hardware. All off-device communication happens here.
Own processor and RAM. Various serial/on-chip messaging techniques to
the higher level. Usually does not speak directly with RTOS. Generally
has ReadOnly mount of "disk" storage that is mounted WriteOnly from
higher level. There is no deterministic requirement. There is generally
a requirement that this *cannot write* to anything other than the
message queue.
UI: (There is a better name for this layer, just having brain fart) Here
is where you can have a Yocto build of Linux, Qt, Windows, DOS,
whatever. There are no deterministic requirements. Communicates via
message queues to both the COMM Module and RTOS layers. If changes need
to be made to COMM Module they come through the COMM module as messages
to this layer. After validation they get written to the WriteOnly shared
"disk". Note: you generally don't allow firmware changes to COMM Module
via this method. Those are generally designed to be a plug-&-play
firmware of their own. The configuration changes allowed are
configuration changes. Other than a PPP-serial driver to communicate
with the other layers, there is no networking software loaded here.
NOTE: older designs did not have COMM Module. This is newer. Designed to
answer new security requirements.
Note 2: The RTOS and UI layers are generally flashable by service
personnel with specialty equipment __AFTER__ opening the device.
You would be correct in assuming Note 2 wasn't always the case and Note
2 may not be the case yet for the lower classes.
Change either of those and the regulators find out, you go to jail. A
person doesn't even have to get hurt or killed.
That's a bit of an overly generalized statement, in't it?
Your statement about industry and safety doesn't hold much water either:
in semiconductor we change critical software all the time and nobody
cares.
Different industry Konrad. I only know about the mills because they were
one time huge OpenVMS customers. I suspect the real difference is that
many mills and mines in the U.S. are unionized because of a long history
like this:
https://www.pbs.org/wgbh/americanexperience/features/triangle-fire-deadliest-workplace-accidents/
Some day I want to read the rest of this book.
https://link.springer.com/chapter/10.1007%2F978-0-387-22466-4_8
I just don't want to pay $80 to read it. At least not $80 for an
electronic copy. Hard cover I probably would.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
