5 ms·

However from the top of my head I can give you one example that is likely used in very security-critical applications that also uses goto: The linux kernel. T

by SCHiM 11y ago

However from the top of my head I can give you one example that is likely used in very security-critical applications that also uses goto: The linux kernel. The kernel coding conventions actually state that this is because over-zealous nesting is more harmful than using goto statements. >The rationale for using gotos is: - unconditional statements are easier to understand and follow - nesting is reduced - errors by not updating individual exit points when making modifications are prevented - saves the compiler work to optimize redundant code away ;) https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle

TickleSteve 11y ago
security-critical != safety-critical. Linux would never get chosen for any higher level safety-related s/w.
- PinguTS 11y ago
  Safety critical and security critical share a lot of goals like: sanity checking of input data, buffer overflows, …
- fit2rule 11y ago
  Linux is deployed all over the world in safety-critical applications .. if you take a train in Europe, parts of China, Brazil, some parts of the US .. Linux is running along, track-side, protectin' yo' ass.. Linux is used in systems that have SIL-4 and ISO 27001 up the wazoo, its just that in the commercial/industrial use, 'tis all extremely well documented. And tested. Tested, tested, tested. Onboard, offline, staged, etc. Test the hell out of all safety-critical software. No goto un-tested. No branches not taken.
  - TickleSteve 11y ago
    In those systems, the Linux kernel tends to be compartmentalised, basically being run as a task under the control of the real RTOS while the safety critical & hard real-time portions are run in a proper RTOS. The other situation is that the actual control is deferred to a proper RTOS/micro combination which can do the correct thing when Linux goes off the rails. The Linux kernel is not a hard-real-time system, it doesn't have complete test coverage and its inclusion in highly-safety-critical systems is as a lower-safety-level subsystem. You will not find a Linux task controlling (for example) a GPIO enabling an X-Ray beam in human rated medical devices. BTW: I can promise you that there are many untested goto's in the Linux Kernel...
    - deleted 11y ago
      [deleted]
    - fit2rule 11y ago
      "proper" RTOS. What part of Linux precludes it from being a proper RT OS in the hands of industrial developers whose purpose it is to certify it as such? >BTW: I can promise you that there are many untested goto's in the Linux Kernel... Not in a development environment looking for SIL-4 certification, there isn't. Perhaps in the public sphere you may feel that is an adequate position, but in industrial computing a significant part of the value is in the testing and real certification of the Linux kernel for certain ratings. >The Linux kernel is not a hard-real-time system, it doesn't have complete test coverage and its inclusion in highly-safety-critical systems is as a lower-safety-level subsystem I assure you, I have found none of these statements to be truly true.
      - TickleSteve 11y ago
        The linux kernel is tuned for throughput, not latency and certainly not bounded-latency. My background is industrial/defense/medical s/w on hard real time systems. e.g. I've worked on train braking systems, high throughput radar systems, medical devices, lots hard real-time control stuff.... I personally have never seen any evidence of anything greater than SIL-2 certified Linux (https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html) and that is only in very narrowly defined context. Like I said earlier, any higher certification, Linux would be run as a comparmentalised, lower-level subsystem. The real control would not be via a Linux controlled task. Until you can point me to the test-suite for a Linux kernel& driver set that gives me 100% code-coverage, then Linux will never get past this point. Dont get me wrong, I like Linux and it has a valuable place in embedded systems.... but hard-real-time control and safety-related systems is not it. As a final word on the subject, dont take my word for it: http://www.hse.gov.uk/research/rrhtm/rr011.htm http://www.hse.gov.uk/research/rrhtm/rr011.htm "it is not likely to be either suitable or certifiable for SIL 4 applications" "It is unlikely that Linux would be useful for SIL 4 applications and it would not be reasonably practicable to provide evidence that it meets a SIL 4 integrity requirement. " ...And in (https://www.osadl.org/fileadmin/dam/presentations/61508/61508_paper.pdf https://www.osadl.org/fileadmin/dam/presentations/61508/6150...) "One of the main conclusion: Linux is not suitable for SIL4."
erikb 11y ago
That's pretty much my point. By avoiding to use some tools completely one does not necessarily increase the stability of software. I just hope that such kind of rules allow well documented/argumented exceptions. But I guess even in safety-critical environments you will have to handle exceptions (small, like in "we did something different than what was agreed on" not as in "throw BufferOverflowException") anyway. No system is perfect.

by SCHiM 11y ago

TickleSteve 11y ago

security-critical != safety-critical. Linux would never get chosen for any higher level safety-related s/w.

PinguTS 11y ago
Safety critical and security critical share a lot of goals like: sanity checking of input data, buffer overflows, …
fit2rule 11y ago
Linux is deployed all over the world in safety-critical applications .. if you take a train in Europe, parts of China, Brazil, some parts of the US .. Linux is running along, track-side, protectin' yo' ass.. Linux is used in systems that have SIL-4 and ISO 27001 up the wazoo, its just that in the commercial/industrial use, 'tis all extremely well documented. And tested. Tested, tested, tested. Onboard, offline, staged, etc. Test the hell out of all safety-critical software. No goto un-tested. No branches not taken.
- TickleSteve 11y ago
  In those systems, the Linux kernel tends to be compartmentalised, basically being run as a task under the control of the real RTOS while the safety critical & hard real-time portions are run in a proper RTOS. The other situation is that the actual control is deferred to a proper RTOS/micro combination which can do the correct thing when Linux goes off the rails. The Linux kernel is not a hard-real-time system, it doesn't have complete test coverage and its inclusion in highly-safety-critical systems is as a lower-safety-level subsystem. You will not find a Linux task controlling (for example) a GPIO enabling an X-Ray beam in human rated medical devices. BTW: I can promise you that there are many untested goto's in the Linux Kernel...
  - deleted 11y ago
    [deleted]
  - fit2rule 11y ago
    "proper" RTOS. What part of Linux precludes it from being a proper RT OS in the hands of industrial developers whose purpose it is to certify it as such? >BTW: I can promise you that there are many untested goto's in the Linux Kernel... Not in a development environment looking for SIL-4 certification, there isn't. Perhaps in the public sphere you may feel that is an adequate position, but in industrial computing a significant part of the value is in the testing and real certification of the Linux kernel for certain ratings. >The Linux kernel is not a hard-real-time system, it doesn't have complete test coverage and its inclusion in highly-safety-critical systems is as a lower-safety-level subsystem I assure you, I have found none of these statements to be truly true.
    - TickleSteve 11y ago
      The linux kernel is tuned for throughput, not latency and certainly not bounded-latency. My background is industrial/defense/medical s/w on hard real time systems. e.g. I've worked on train braking systems, high throughput radar systems, medical devices, lots hard real-time control stuff.... I personally have never seen any evidence of anything greater than SIL-2 certified Linux (https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html) and that is only in very narrowly defined context. Like I said earlier, any higher certification, Linux would be run as a comparmentalised, lower-level subsystem. The real control would not be via a Linux controlled task. Until you can point me to the test-suite for a Linux kernel& driver set that gives me 100% code-coverage, then Linux will never get past this point. Dont get me wrong, I like Linux and it has a valuable place in embedded systems.... but hard-real-time control and safety-related systems is not it. As a final word on the subject, dont take my word for it: http://www.hse.gov.uk/research/rrhtm/rr011.htm http://www.hse.gov.uk/research/rrhtm/rr011.htm "it is not likely to be either suitable or certifiable for SIL 4 applications" "It is unlikely that Linux would be useful for SIL 4 applications and it would not be reasonably practicable to provide evidence that it meets a SIL 4 integrity requirement. " ...And in (https://www.osadl.org/fileadmin/dam/presentations/61508/61508_paper.pdf https://www.osadl.org/fileadmin/dam/presentations/61508/6150...) "One of the main conclusion: Linux is not suitable for SIL4."

erikb 11y ago

That's pretty much my point. By avoiding to use some tools completely one does not necessarily increase the stability of software. I just hope that such kind of rules allow well documented/argumented exceptions. But I guess even in safety-critical environments you will have to handle exceptions (small, like in "we did something different than what was agreed on" not as in "throw BufferOverflowException") anyway. No system is perfect.