<div dir="ltr"><div dir="ltr">Paul,<div><br></div><div>Thank you for taking the time to respond to my comments. Please see my responses below.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)">On Mon, 5 Aug 2024 at 18:33, Paul Sherwood <<a href="mailto:paul.sherwood@codethink.co.uk">paul.sherwood@codethink.co.uk</a>> wrote:<br></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What do you mean by Linux, here? If you are meaning "the people who <br>
develop Linux", then I think the reason is that they have been able to <br>
achieve their goals for the software without compliance. In almost all <br>
cases the developers will not have needed to consider those specific <br>
standards at any point during their careers.<br></blockquote><div><br></div><div>So, the problem is not that Linux cannot meet the relevant standards, but that there is no motivation for the Linux developers to comply with the standards? Surely, if Linux is to be used for safety applications, there needs to be a 'Safe Linux' branch that complies with the relevant standards. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Even Level C isn't that hard. Why wouldn't<br>
> you want to achieve statement coverage?<br>
<br>
Actually, I wouldn't, because of my personal bias. I've successfully <br>
delivered small amounts of critical code (in the few thousands of LoC <br>
range) without unit tests, for systems which then worked for years <br>
without problems. Usually I've had more success with system tests than <br>
unit tests, on many projects.<br></blockquote><div><br></div><div>I accept that before I started writing safety-critical software, I didn't necessarily test every single line of code. Dave Thomas, who I used to work for, says in his presentation <a href="https://www.youtube.com/watch?v=a-BOSpxYJ9M&t=457s">Agile is Dead • Pragmatic Dave Thomas • GOTO 2015 (youtube.com)</a> at 18:00 that he doesn't test everything. However, there is a big difference between safety applications and other kinds of applications. Even IEC 61508 SIL 1 or DO-178C Level D is a very strong claim. Since I started writing safety-critical software, I have tended to test everything just because it isn't that hard and doesn't take that much time.</div><div><br></div><div>DO-178C doesn't require you to achieve 100% structural coverage through unit tests. It requires that your requirements-based tests (which can be hardware/software integration tests, software integration tests or low-level tests) cover all the software requirements and exercise all the code. If your tests haven't covered all the requirements, there's functionality you haven't tested. If your tests haven't achieved statement coverage, then there's code that you've never executed, not even once, during your testing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I remember attending a talk by<br>
> the CEO of Red Hat Linux UK, who admitted that most of their<br>
> developers are volunteers and prefer to spend their time coding rather<br>
> than writing tests.<br>
<br>
While it is true that most or Red Hat's engineers contribute voluntarily <br>
to open source projects in their spare time, it is also true that Red <br>
Hat pays some thousands of engineers to work full-time on contributing <br>
to the Linux kernel and a huge range of open source projects. <br>
Irrespective of personal preference, I would expect that if Red Hat <br>
chooses to increase test coverage on any project, they are entirely <br>
capable of doing so.<br></blockquote><div><br></div><div>You claim they are capable of doing so, but they choose not to. It comes back to the point above that they don't see a commercial incentive to create a DO-178C or IEC 61508 variant of Red Hat Linux.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The open-source repositories that I've inspected<br>
> contain alarmingly few tests.<br>
<br>
Well, I think there are hundreds of millions of open source repositories <br>
on GitHub, and I'm sure almost all of them are clearly not suitable for <br>
use in critical systems. But there are some thousands of open source <br>
projects that have been developed and maintained to extremely high <br>
standards.<br></blockquote><div><br></div><div>There are open-source repositories that are suitable for use in critical systems. One example is AdaCore's GNAT Ada compiler. Most open-source projects (and I suspect most proprietary software projects), even those sponsored by large companies, do surprisingly little testing. For example, I reviewed part of the ARM Trusted Computing Platform on behalf of the CHERI Standards Compliance (STONE) project <a href="https://static1.squarespace.com/static/5f8ebbc01b92bb238509b354/t/617924ea4bc0ce729ca8591c/1635329260523/CHERI+STONE+-+Final+Report+-+for+publication+v1.0.pdf">CHERI+STONE+-+Final+Report+-+for+publication+v1.0.pdf (squarespace.com)</a>. The System Control Processor (SCP) firmware consisted of 381,512 SLOC, but there were only 5,291 SLOC of tests. There are very few open-source projects that do enough testing to achieve even DO-178C Level D or IEC 61508 SIL 1.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> IEC 61508 provides three compliance routes:<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Route 1s: compliant development. Why is it so hard for Linux to just<br>
> comply with IEC 61508? The requirements for SC1 or SC2 are not very<br>
> onerous.<br>
<br>
As previously stated, the people developing the Linux kernel in general <br>
have little/no experience (or need to comply) with any specific <br>
standard. Red Hat is actively working on safety for their RHIVOS <br>
product, focusing on ISO 26262. Perhaps they will achieve compliance, <br>
but I suspect there may be a lot of 'tailoring'.<br>
<br>
As stated, previous initiatives have failed to achieve certification, <br>
but this does not mean that Linux has not been deployed in critical <br>
systems.<br></blockquote><div><br></div><div>How was it deployed in critical systems if it was not certified? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Route 2s: proven in use. This is not considered practicable for<br>
> complex software such as operating systems. This was recognised by<br>
> SIL2Linux.<br>
<br>
At the risk of seeming 'insulting' again, it seems to me that the proven <br>
in use path is practically impossible for anything involving modern <br>
electronics, even before we get to the software.<br></blockquote><div><br></div><div>Agreed </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Route 3s assessment of non-compliant development. This is a very<br>
> sensible way of allowing the use of an open-source operating system<br>
> such as Linux (more so than the COTS guidance in DO-278A). Route 3s<br>
> can be summarised as a. what do we know about the software? b. what<br>
> evidence do we have that it works? and c. what happens if it goes<br>
> wrong? This was the approach adopted by SIL2Linux. Yet they failed.<br>
> I'd like to understand why.<br>
<br>
I have some understanding of why, but it is not my story to tell.<br></blockquote><div><br></div><div>I would love to know more, since IEC 61508-3 Route 3s seemed a sensible route for SIL2Linux to take.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Your post is insulting to certification authorities and those of us<br>
> who participate in standards committees.<br>
<br>
I'm sorry you feel that way. My aim was not to insult, but to draw <br>
attention to the gaps which clearly exist between the standards and the <br>
way modern software-intensive systems are actually engineered.<br></blockquote><div><br></div><div>I'm glad that you did not aim to insult. There is a big gap between safety-critical software that complies with the standards and other software that does not. That's always been the case. Most software developers care about features, cost and time-to-market. Safety-critical software developers have to show that the system can be shown to be acceptably safe before it enters service. I don't agree with your use of the term 'modern'. The Airbus Flight Control System (FCS) and the Linux kernel are both modern software-intensive systems. They've been developed to meet very different goals and have therefore been engineered differently. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> You imply that the<br>
> certification authorities are being unreasonable and that they should<br>
> just allow people to use Linux.<br>
<br>
I certainly did not say any such thing, nor did I intend to imply it. <br>
Given experience of single-threaded microcontroller type systems with <br>
expectations of deterministic behaviour, many of the ideas in the <br>
standards are entirely reasonable.<br>
<br>
When reasoning about software for a modern multi-core processor, with <br>
perhaps a million lines of (uncertified) code hidden as firmware, the <br>
behaviour is not deterministic, so test coverage will not get there.<br></blockquote><div><br></div><div>Accepted, but that's why a million lines of uncertified code running on a multi-core processor, whose behaviour is not deterministic, is not suitable to be used in a safety application.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I don't agree with your conclusion. If<br>
> Linux is as complicated as you say, they need to do more verification,<br>
> not less.<br>
<br>
I did not mean to suggest any lack of verification; there is a huge <br>
amount of work done to verify every Linux release. They just don't set <br>
much store in measuring code coverage via unit tests.<br></blockquote><div><br></div><div>This is the aspect I have difficulties with. I accept that the Linux developers don't set much store in measuring code coverage. DO-178C doesn't require that you achieve structural coverage through unit tests, by the way. But if they do as much testing as you claim to verify every Linux release, it should be straightforward for a 'Safe Linux' team to fill the gaps to achieve compliance with the relevant standards. If the compliance gaps are large and the Linux developers rely instead on the extremely large user base reporting any defects quickly so they can be fixed in the next release, then that isn't good enough for safety applications.</div><div><br></div><div>You talk a lot about "state of the art". Linux is a widely-respected, mature operating system, but it is not "state of the art". I consider formal methods to be "state of the art". Microsoft, Amazon Web Services and Intel all have large formal methods teams. See, for example, the excellent presentation by Rod Chapman, my former colleague from Praxis: <a href="https://www.his-conference.co.uk/session/automated-reasoning-in-and-about-the-cloud">Automated Reasoning in and… | High Integrity Software Conference 2024 (his-conference.co.uk)</a>. There is even an open-source operating system microkernel that has been verified using formal methods - <a href="https://sel4.systems/">Home | seL4</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I don't see how you can use statistical techniques to<br>
> measure confidence in software as complex as an operating system.<br>
<br>
Understood. Hopefully we and others will manage to demonstrate that in <br>
spite of the doubts.<br></blockquote><div><br></div><div>Prof. Peter Ladkin is one of the World's leading experts on practical statistical evaluation of critical software. Peter has pointed out that using statistical techniques to measure confidence in software as complex as an operating system is a pipe dream.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'm reminded of the quote from Tony Hoare, "There are two ways of<br>
> constructing a software design: One way is to make it so simple that<br>
> there are obviously no deficiencies, and the other way is to make it<br>
> so complicated that there are no obvious deficiencies. The first<br>
> method is far more difficult". I'm also reminded of the quote from the<br>
> NTSB report on one of the Tesla accidents, "Just because you can<br>
> doesn't mean you should".<br>
<br>
Indeed. Thank you again for your comments.<br></blockquote><div><br></div><div>Thank you for your taking the time to respond to my comments.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a name="SignatureSanitizer_m_-5798674576462993830_SignatureSanitizer_SafeHtmlFilter_UNIQUE_ID_SafeHtmlFilter__MailAutoSig"><span style="font-size:10pt;font-family:Arial,sans-serif">Yours,</span></a><br></div><div><div dir="ltr"><div dir="ltr"><p><span style="font-family:Arial,sans-serif;font-size:10pt">Dewi Daniels | Director | Software Safety Limited</span><br></p><p><span lang="FR" style="font-size:10pt;font-family:Arial,sans-serif">Telephone +44 7968 837742 | Email <a href="mailto:dewi.daniels@software-safety.com" target="_blank">dewi.daniels@software-safety.com</a></span></p><p><font face="Arial, sans-serif">Software Safety Limited is a company registered in England and Wales. Company number: </font><font face="Arial, sans-serif">9390590</font><font face="Arial, sans-serif">. Registered office: Fairfield, 30F Bratton Road, West Ashton, Trowbridge</font><span style="font-family:Arial,sans-serif">, United Kingdom </span><span style="font-family:Arial,sans-serif">BA14 6AZ</span></p></div></div></div></div></div></div><br></div></div></div>