From: paul.sherwood@codethink.co.uk (Paul Sherwood)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] [SystemSafety] Critical systems Linux
Date: Thu, 22 Nov 2018 09:24:27 +0000 [thread overview]
Message-ID: <e65ecf916a6f7952737b52aeb591eaa5@codethink.co.uk> (raw)
In-Reply-To: <e5bcaec2b35a99e151627fbab8047e72@codethink.co.uk>
Hi again...
>>> The question is:-
>>>
>>> As Linux is monolithic, already written (with minimal
>>> requirements/design
>>> docs) and not to any coding standard
>>> How would the world go about making a Certifiable Linux?
>
>>> Is it possible?
Sadly most of the followon discussion seems to have stayed only on
systemsafetylist.org [1] which rather reduces its impact IMO.
I cross-posted in the hope that knowledge from the safety community
could be usefully shared with other communities who are (for better or
worse) considering and in some cases already using Linux in
safety-critical systems. For example Linux Foundation is actively
soliciting contributors expressly for an initiative to establish how
best to support safety scenarios, as discussed at ELCE [2] with
contributors from OSADL (e.g. [3]) and others.
Perhaps I'm being stupid but it's still unclear to me, after the
discussion about existing certificates, whether the 'pre-certification'
approach is justifiable at all, for **any** software, not just Linux.
As I understand it, for any particular project/system/service we need to
define safety requirements, and safety architecture. From that we need
to establish constraints and required properties and behaviours of
chosen architecture components (including OS components). On that basis
it seems to me that we must always prepare a specific argument for an
actual system, and cannot safely claim that any generic
pre-certification fits our use-case?
Please could someone from systemsafetylist.org reply-all and spell it
out, preferably without referring to standards and without triggering a
lot of controversy?
br
Paul
[1] http://systemsafetylist.org/4310.htm
[2]
https://www.osadl.org/Linux-in-Safety-Critical-Systems-Summit.lfsummit-elce-safety.0.html
[3]
https://events.linuxfoundation.org/wp-content/uploads/2017/12/Collaborate-on-Linux-for-Use-in-Safety-Critical-Systems-Lukas-Bulwahn-BMW-Car-IT-GmbH-1.pdf
next prev parent reply other threads:[~2018-11-22 9:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <037a01d480f8$1f486570$5dd93050$@phaedsys.com>
2018-11-20 18:45 ` [cip-dev] [SystemSafety] Critical systems Linux Paul Sherwood
2018-11-20 18:58 ` Paul Sherwood
2018-11-22 9:24 ` Paul Sherwood [this message]
2018-11-22 11:57 ` [cip-dev] [C-safe-secure-studygroup] " Clive Pygott
2018-11-22 13:19 ` Paul Sherwood
2018-11-22 17:43 ` [cip-dev] [Safety-linux-formation] " Nicholas Mc Guire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e65ecf916a6f7952737b52aeb591eaa5@codethink.co.uk \
--to=paul.sherwood@codethink.co.uk \
--cc=cip-dev@lists.cip-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox