Hacker News Reader

Comment by pknopf | Hacker News Reader

A little of topic, but I'm confused about something.

These certs open the door for medical devices, which is great.

I work on Class 1 medcial device. We have customers and regulatory people saying I can't even use Qt because we compile it ourselves. Apparently, once we have access to the source code, we must bring the software up to our target safety class.

This of course isn't feasible. Apparently, this even applies to the kernel.

My regulatory people are demanding that we hire someone like WindRiver to deliver use pre-compiled images and tool chains, removing the source from our hands.

I don't follow regulatory closely, but this has got to be wrong. Are you saying that I can never use open source software? Even if the software has these certs like this (Safe Render)? Surely we can still treat 3rd party libs as SOUP, even if we have the source, yeah?

View on HN

You can use any SOUP you want, the rule is that it is up to you, medical device seller, to write the requirements (performance or other) you want from it, and verify them. Additionally, you need to assess any risk added by the inclusion of the SOUP and mitigate them. (The effort depends on whether you include it into a Class A/B/C sw unit). You are ultimately responsible for any bug in the SOUP. And this is rather orthogonal to license of the sw.

Since this is a daunting task to verify something like QT, now you can at least pay for the certified version, and point some of your risk mitigations directly to the QT specifications/FMEA/Test results.

The usual strategies to avoid having to validate a huge external SW is to either have HW redundancies, or to segregate it completely from your main SW so that any failure of your SOUP is harmless.

We use Yocto. By default, the distribution is super minimal.

As I enable features in the Kernel, or add dependencies, they are driven based off of some functionality of our GUI/device which is tested/validated before each release.

So, if I enable squashfs in the kernel, and I can boot my box (which uses it), I can say that I have tested the requirements needed from the Kernel.

If I add in openssl for TLS connection to mobile devices and have validation in place to ensure connectivity, I can say that I have tested the required functionality of openssl.

I'd think this would be enough, but I never can seem to satisfy regulatory people. They are (in general) not very technical.

I would say it depends a bit of the usage of the system, and what is the worse case scenario of a failure (patient data corrupted, life sustaining devices switched off), in which case you might need to add another mitigation (CRC check, manual procedure) independent of your Yocto box.

I would understood under those circumstances where patients are at risk.

I'm not trying to get consultation services from HN, but for the sake of discussion, these devices are recorders used for post-op educational purposes. External/separate monitors are used for the actual operation.

I bring this up because the risk is very low, yet I have had multiple customers who wish to distribute our product ask about this.

This is turning into more of a rant than anything. I'll end with this comment.

You aren’t expected to do anything in analysis and mitigation for SOUP that you shouldn’t already be doing for all of your own software. The point is you can’t just punt on that stuff when you use others software. It doesnt have to be that onerous, but you do need to put some thought into it.

I know nothing about this... However, I can see a little bit of sense to this (not much - and nothing that couldn't be solved a lot better). If you have access to the source code it is very easy to start adding patches. On the other hand if you have access to binaries it is also very easy to start modifying them...

Their argument seems to suggest that I should roll my own openssl, for "risk management".

I mean, these projects typically have thorough tests.

Surely it's more that you should obtain certified binaries of openssl from a third party?

Yeah, I get it.

However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?

> How would I debug with no source?

I don't work in the field, but just because you're using a certified binary doesn't mean no source can ever be associated with it for debugging.

Continuing the example of a certified binary of openssl from a third party (say version 1.1.0h), I'd expect you to be able to debug the certified binary using a version-matched source tarball from the openssl website [1].

[1] https://www.openssl.org/source/openssl-1.1.0h.tar.gz

That’s not a very accurate analogy. The situation would be more like “you can only use a pre-compiled, audited version of OpenSSL”, which makes much more sense. Of course you could audit source code as well, but it’s much harder to verify than a binary.

wait, wait, it's harder to audit source code than a binary? wtf?

I should probably clarify: it’s easier to make sure that a binary is the same as a version that has been audited, whereas with source code, there’s much more uncertainty in the build process.

With Yocto, you can audit the recipes (example [0]) being used to build the library.

Yocto all generates checksums for all inputs and outputs, caching intermediate build steps, ensuring consistency in the build process.

Also, Yocto will not compile anything with your local/native gcc toolchain. It will however use your local gcc toolchain to build it's own gcc toolchain, which it will then use to build all the relative recipes. This again ensures build consistency across platforms/machines.

If the argument is purely a "well, I can't audit the produced binaries", I'd argue that you can audit the build system in great detail.

[0] https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...

How about the following?

"Sure, we do use the precompiled binaries. We can even prove it because they have the same hash, and our procedure fails if they don't"

How you obtained your binary is immaterial, if you can prove it's the same as the audited one. Surely regulatory people would accept that?

Reply on news.ycombinator.com