[SystemSafety] State of the art for "safe Linux"

[Dewi Daniels]

Paul,

Thank you for a good summary of the initiatives to approve the use of Linux
in safety applications.

You're missing the Enabling Linux in Safety Applications (ELISA) project ELISA
- Advancing Linux in Safety-Critical Systems – ELISA <https://elisa.tech/>
and EB corbos Linux for Safety Applications EB corbos Linux for Safety
Applications – Elektrobit
<https://www.elektrobit.com/products/ecu/eb-corbos/linux-for-safety-applications/>
.

I agree with Andrew Banks when he asks what do you mean by Linux?

What do you mean by certification authorities? Do you mean aviation, rail,
automotive, nuclear, medical, process control? The regulatory regimes are
very different.

I don't understand why it's so hard for Linux to just comply with standards
such as RTCA DO-178C/EUROCAE ED-12C? DO-178C Level D is just Software
Engineering 101. Even Level C isn't that hard. Why wouldn't you want to
achieve statement coverage? I remember attending a talk by the CEO of Red
Hat Linux UK, who admitted that most of their developers are volunteers and
prefer to spend their time coding rather than writing tests. The
open-source repositories that I've inspected contain alarmingly few tests.

Another approach is to follow the COTS guidance in RTCA DO-278A/EUROCAE
ED-109A. It was specifically written to allow the use of COTS software such
as operating systems. I understand that EUROCONTROL and NATS have been
deploying CNS/ATM systems based on UNIX for many years. RTCA SC-240/EUROCAE
WG-117 is working on better guidance on the use of COTS and Open-Source
Software (OSS) in aviation.

IEC 61508 provides three compliance routes:

   1.

   Route 1s: compliant development. Why is it so hard for Linux to just
   comply with IEC 61508? The requirements for SC1 or SC2 are not very onerous.

   2.

   Route 2s: proven in use. This is not considered practicable for complex
   software such as operating systems. This was recognised by SIL2Linux.

   3.

   Route 3s assessment of non-compliant development. This is a very
   sensible way of allowing the use of an open-source operating system such as
   Linux (more so than the COTS guidance in DO-278A). Route 3s can be
   summarised as a. what do we know about the software? b. what evidence do we
   have that it works? and c. what happens if it goes wrong? This was the
   approach adopted by SIL2Linux. Yet they failed. I'd like to understand why.

Your post is insulting to certification authorities and those of us who
participate in standards committees. You imply that the certification
authorities are being unreasonable and that they should just allow people
to use Linux. I don't agree with your conclusion. If Linux is as
complicated as you say, they need to do more verification, not less. I
don't see how you can use statistical techniques to measure confidence in
software as complex as an operating system. I'm reminded of the quote from
Tony Hoare, "There are two ways of constructing a software design: One way
is to make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult". I'm also reminded of
the quote from the NTSB report on one of the Tesla accidents, "Just because
you can doesn't mean you should".

Yours,

Dewi Daniels | Director | Software Safety Limited

Telephone +44 7968 837742 | Email dewi.daniels at software-safety.com

Software Safety Limited is a company registered in England and Wales.
Company number: 9390590. Registered office: Fairfield, 30F Bratton Road,
West Ashton, Trowbridge, United Kingdom BA14 6AZ


On Mon, 5 Aug 2024 at 13:23, Paul Sherwood <paul.sherwood at codethink.co.uk>
wrote:

> Hi Andrew
> On 2024-08-05 13:07, andrew at andrewbanks.com wrote:
> > I'd start with an easier question... what do you mean by Linux
> >
> > It's a Kernel, plus a whole array of other features; but what would the
> > Software BoM for Linux actually show?  What is part of Linux, and what
> > are add-ons or apps?
>
> It's a fair question. I was using Linux as shorthand, but in practice
> the BoM needs to show not just the kernel, but also the boot loader,
> drivers, modules and applications. Moreover the compiler, linker and all
> component libraries can affect the outcome. And if the build environment
> is not sufficiently well controlled, results might also be tainted by
> things on the servers, or on the developers' laptops!
>
> br
> Paul
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription:
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20240805/e2ee2faa/attachment-0001.html>