[Interest] anti-Tivo - was The willy-nilly deletion of convenience, , methods

Wed Mar 24 14:22:12 CET 2021

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210324/80dcf8ce/attachment.html>