4 ms·

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

by pknopf 8y ago

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?

asfdsfggtfd 8y ago
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...
- pknopf 8y ago
  Their argument seems to suggest that I should roll my own openssl, for "risk management". I mean, these projects typically have thorough tests.
  - asfdsfggtfd 8y ago
    Surely it's more that you should obtain certified binaries of openssl from a third party?
    - pknopf 8y ago
      Yeah, I get it. However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?
      - wgjordan 8y ago
        > 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 https://www.openssl.org/source/openssl-1.1.0h.tar.gz
  - yzmtf2008 8y ago
    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.
    - Hello71 8y ago
      wait, wait, it's harder to audit source code than a binary? wtf?
      - yzmtf2008 8y ago
        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.
        pknopf 8y ago
        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/recipes-graphics/harfbuzz/harfbuzz_1.7.5.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...
        loup-vaillant 8y ago
        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?
seren 8y ago
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.
- pknopf 8y ago
  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.
  - seren 8y ago
    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.
    - pknopf 8y ago
      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.

by pknopf 8y ago

asfdsfggtfd 8y ago

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

pknopf 8y ago
Their argument seems to suggest that I should roll my own openssl, for "risk management". I mean, these projects typically have thorough tests.
- asfdsfggtfd 8y ago
  Surely it's more that you should obtain certified binaries of openssl from a third party?
  - pknopf 8y ago
    Yeah, I get it. However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?
    - wgjordan 8y ago
      > 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 https://www.openssl.org/source/openssl-1.1.0h.tar.gz
- yzmtf2008 8y ago
  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.
  - Hello71 8y ago
    wait, wait, it's harder to audit source code than a binary? wtf?
    - yzmtf2008 8y ago
      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.
      - pknopf 8y ago
        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/recipes-graphics/harfbuzz/harfbuzz_1.7.5.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...
        loup-vaillant 8y ago
        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?

seren 8y ago

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.

pknopf 8y ago
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.
- seren 8y ago
  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.
  - pknopf 8y ago
    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.