public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
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

  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