|
HI,
I noticed the interesting contribution by Bruce Benson and Priyanka Verma at the recent LPC, suggesting usage of cgroups and namespaces to support FFI claims.
The talk was mainly an introductory tutorial clarifying the technical features of cgroups and namespaces, and is fundamental for those who are not familiar with these basic Linux
kernel features.
However, having missed the presentation itself, I don't see from the slides if the safety aspects were discussed in the talk.
Some questions are included in the final slide (e.g., Can we rely on containers for temporal FFI? What is the role of containers if we have an external flow control monitor?)
And in a more general sense, what are the criteria for acceptance of such kernel features as the basis for safety claims such as FFI?
@Paul Albertella
– I would hope that your new WG will be helpful to make clear guidelines on such questions.
Regards
Elana
|
|
|
Paul Albertella
Hi Elana, On 29/09/2021 06:50, elana.copperman@... wrote: And in a more general sense, what are the criteria for acceptance of such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> – I would hope that your new WG will be helpful to make clear guidelines on such questions. Yes, that's very much my intention! There are really two broad sets of criteria, which can be summarised in the following two questions: 1) What role does the feature have in achieving a safety goal? 2) What gives us confidence that the feature can fulfil that role? In my opinion, there's nothing to *prevent* us from using any Linux feature as the basis for a safety claim, provided that we can: * Document our answers to these questions (Assertions) * Provide material to support these answers (Evidence) The challenge is that we then have to satisfy a safety assessor that these are valid and sufficient! One of the issues we face when answering these questions for Linux (and open source software in general) is that the 'traditional' answers (as described in safety standards like ISO 26262) are not always well-supported by either assertions or evidence from open source communities. However, it's vitally important to recognise that safety standards do allow for 'non-traditional' answers and evidence, provided that we are prepared to make a reasoned argument to support these. My goal with the OSEP WG is to explore specific examples of this, to understand what Linux contributors (or maintainers) and safety system developers (or integrators) can do to both frame better answers and provide better evidence. Regards, Paul
|
|
|
Totally agreed with the problem space, and the proposed path forward. Paul - until we sort out the final details of "development process" WG evolution, can we use tomorrow's call for kickstarting this discussion. A good starting point would be the presentation from last week's LPC on Kernel cgroups and namespaces: Can they contribute to FFI claims? https://linuxplumbersconf.org/event/11/contributions/1079/Including some of the questions raised by Bruce and Priyanka in their closing slide. Regards Elana
-----Original Message----- From: devel@... <devel@...> On Behalf Of Paul Albertella Sent: Wednesday, September 29, 2021 12:23 PM To: devel@... Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims? Hi Elana, On 29/09/2021 06:50, elana.copperman@... wrote: And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on such questions. Yes, that's very much my intention! There are really two broad sets of criteria, which can be summarised in the following two questions: 1) What role does the feature have in achieving a safety goal? 2) What gives us confidence that the feature can fulfil that role? In my opinion, there's nothing to *prevent* us from using any Linux feature as the basis for a safety claim, provided that we can: * Document our answers to these questions (Assertions) * Provide material to support these answers (Evidence) The challenge is that we then have to satisfy a safety assessor that these are valid and sufficient! One of the issues we face when answering these questions for Linux (and open source software in general) is that the 'traditional' answers (as described in safety standards like ISO 26262) are not always well-supported by either assertions or evidence from open source communities. However, it's vitally important to recognise that safety standards do allow for 'non-traditional' answers and evidence, provided that we are prepared to make a reasoned argument to support these. My goal with the OSEP WG is to explore specific examples of this, to understand what Linux contributors (or maintainers) and safety system developers (or integrators) can do to both frame better answers and provide better evidence. Regards, Paul
|
|
|
toggle quoted message
Show quoted text
-----Ursprüngliche Nachricht-----
Von: devel@... <devel@...> Im Auftrag von
elana.copperman@...
Gesendet: Mittwoch, 29. September 2021 11:40
An: Paul Albertella <paul.albertella@...>; devel@...
Betreff: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel
cgroups and namespaces: Can they contribute to FFI claims?
Totally agreed with the problem space, and the proposed path forward.
Paul - until we sort out the final details of "development process" WG
evolution, can we use tomorrow's call for kickstarting this discussion.
A good starting point would be the presentation from last week's LPC on
Kernel cgroups and namespaces: Can they contribute to FFI claims?
https://linuxplumbersconf.org/event/11/contributions/1079/
Including some of the questions raised by Bruce and Priyanka in their closing
slide.
Regards
Elana
-----Original Message-----
From: devel@... <devel@...> On Behalf Of Paul
Albertella
Sent: Wednesday, September 29, 2021 12:23 PM
To: devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel
cgroups and namespaces: Can they contribute to FFI claims?
Hi Elana,
On 29/09/2021 06:50, elana.copperman@... wrote:
And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on such questions.
Yes, that's very much my intention!
There are really two broad sets of criteria, which can be summarised in the
following two questions:
1) What role does the feature have in achieving a safety goal?
2) What gives us confidence that the feature can fulfil that role?
In my opinion, there's nothing to *prevent* us from using any Linux feature
as the basis for a safety claim, provided that we can:
* Document our answers to these questions (Assertions)
* Provide material to support these answers (Evidence)
The challenge is that we then have to satisfy a safety assessor that these are
valid and sufficient!
One of the issues we face when answering these questions for Linux (and
open source software in general) is that the 'traditional' answers (as
described in safety standards like ISO 26262) are not always well-supported
by either assertions or evidence from open source communities.
However, it's vitally important to recognise that safety standards do allow for
'non-traditional' answers and evidence, provided that we are prepared to
make a reasoned argument to support these.
My goal with the OSEP WG is to explore specific examples of this, to
understand what Linux contributors (or maintainers) and safety system
developers (or integrators) can do to both frame better answers and provide
better evidence.
Regards,
Paul
-- Mit freundlichen Grüßen Jochen Kall -- Dr. rer. nat. Jochen Kall Funktionale Sicherheit ITK Engineering GmbH Im Speyerer Tal 6 76761 Rülzheim Tel.: +49 7272 7703-546 Fax: +49 7272 7703-100 Mobil:+491734957776 mailto:jochen.kall@... ( jochen.kall@... ) ______________________________________________________________ ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100 mailto:info@... ( info@... ) | http://www.itk-engineering.de ( http://www.itk-engineering.de/ ) Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Dr. Rudolf Maier Geschäftsführung/Executive Board: Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke Sitz der Gesellschaft/Registered Office: 76761 Rülzheim Registergericht/Registered Court: Amtsgericht Landau, HRB 32046 USt.-ID-Nr./VAT-ID-No. DE 813165046
|
|
|
Gabriele Paoloni
Hi All Hi Elana,
On 29/09/2021 06:50, elana.copperman@... wrote:
> And in a more general sense, what are the criteria for acceptance of
> such kernel features as the basis for safety claims such as FFI?
Given that the topic was presented in a micro conference the deck was intended to
trigger an open discussion rather than showing results. I agree with everything that Paul wrote down below and there is one more point I would
like to make: it is also helpful to consider the impact of containers on the availability
of the system (e.g. we could make a temporal FFI claim using an external
flow control monitor and use containers to make sure the risk of interference is
minimized to be confident enough on the external WTD to not trigger).
Anyway it is a good topic to discuss...
Thanks Gab
>
> @Paul Albertella <mailto:paul.albertella@...> – I would hope
> that your new WG will be helpful to make clear guidelines on such questions.
Yes, that's very much my intention!
There are really two broad sets of criteria, which can be summarised in
the following two questions:
1) What role does the feature have in achieving a safety goal?
2) What gives us confidence that the feature can fulfil that role?
In my opinion, there's nothing to *prevent* us from using any Linux
feature as the basis for a safety claim, provided that we can:
* Document our answers to these questions (Assertions)
* Provide material to support these answers (Evidence)
The challenge is that we then have to satisfy a safety assessor that
these are valid and sufficient!
One of the issues we face when answering these questions for Linux (and
open source software in general) is that the 'traditional' answers (as
described in safety standards like ISO 26262) are not always
well-supported by either assertions or evidence from open source
communities.
However, it's vitally important to recognise that safety standards do
allow for 'non-traditional' answers and evidence, provided that we are
prepared to make a reasoned argument to support these.
My goal with the OSEP WG is to explore specific examples of this, to
understand what Linux contributors (or maintainers) and safety system
developers (or integrators) can do to both frame better answers and
provide better evidence.
Regards,
Paul
|
|
|
Thanks, Jochen. This is excellent.
We should continue this discussion, as proposed in the parallel thread.
toggle quoted message
Show quoted text
-----Original Message----- From: Jochen Kall <Jochen.Kall@...> Sent: Wednesday, September 29, 2021 1:00 PM To: Elana Copperman <Elana.Copperman@...>; Paul Albertella <paul.albertella@...>; devel@... Subject: AW: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims? Hi everyone, just a quality of life service for those interested, the recording of the talk can be found here: https://youtu.be/iaK_wcL1ekY?t=12393Jochen -----Ursprüngliche Nachricht-----
Von: devel@... <devel@...> Im Auftrag von
elana.copperman@...
Gesendet: Mittwoch, 29. September 2021 11:40
An: Paul Albertella <paul.albertella@...>;
devel@...
Betreff: Re: [ELISA Technical Community] LPC 2021 presentation -
Kernel cgroups and namespaces: Can they contribute to FFI claims?
Totally agreed with the problem space, and the proposed path forward.
Paul - until we sort out the final details of "development process" WG
evolution, can we use tomorrow's call for kickstarting this discussion.
A good starting point would be the presentation from last week's LPC
on Kernel cgroups and namespaces: Can they contribute to FFI claims?
https://linuxplumbersconf.org/event/11/contributions/1079/
Including some of the questions raised by Bruce and Priyanka in their
closing slide.
Regards
Elana
-----Original Message-----
From: devel@... <devel@...> On Behalf Of
Paul Albertella
Sent: Wednesday, September 29, 2021 12:23 PM
To: devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation -
Kernel cgroups and namespaces: Can they contribute to FFI claims?
Hi Elana,
On 29/09/2021 06:50, elana.copperman@... wrote:
And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on
such questions.
Yes, that's very much my intention!
There are really two broad sets of criteria, which can be summarised
in the following two questions:
1) What role does the feature have in achieving a safety goal?
2) What gives us confidence that the feature can fulfil that role?
In my opinion, there's nothing to *prevent* us from using any Linux
feature as the basis for a safety claim, provided that we can:
* Document our answers to these questions (Assertions)
* Provide material to support these answers (Evidence)
The challenge is that we then have to satisfy a safety assessor that
these are valid and sufficient!
One of the issues we face when answering these questions for Linux
(and open source software in general) is that the 'traditional'
answers (as described in safety standards like ISO 26262) are not
always well-supported by either assertions or evidence from open source communities.
However, it's vitally important to recognise that safety standards do
allow for 'non-traditional' answers and evidence, provided that we are
prepared to make a reasoned argument to support these.
My goal with the OSEP WG is to explore specific examples of this, to
understand what Linux contributors (or maintainers) and safety system
developers (or integrators) can do to both frame better answers and
provide better evidence.
Regards,
Paul
|
|
|
Gabriele Paoloni
Yes agreed
Sorry, I replied to Paul and missed the follows up from Elana and Jochen. However I also think it is a good topic to elaborate on.
Thanks Gab
Thanks, Jochen. This is excellent.
We should continue this discussion, as proposed in the parallel thread.
-----Original Message-----
From: Jochen Kall <Jochen.Kall@...>
Sent: Wednesday, September 29, 2021 1:00 PM
To: Elana Copperman <Elana.Copperman@...>; Paul Albertella <paul.albertella@...>; devel@...
Subject: AW: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?
Hi everyone,
just a quality of life service for those interested, the recording of the talk can be found here:
https://youtu.be/iaK_wcL1ekY?t=12393
Jochen
> -----Ursprüngliche Nachricht-----
> Von: devel@... <devel@...> Im Auftrag von
> elana.copperman@...
> Gesendet: Mittwoch, 29. September 2021 11:40
> An: Paul Albertella <paul.albertella@...>;
> devel@...
> Betreff: Re: [ELISA Technical Community] LPC 2021 presentation -
> Kernel cgroups and namespaces: Can they contribute to FFI claims?
>
> Totally agreed with the problem space, and the proposed path forward.
> Paul - until we sort out the final details of "development process" WG
> evolution, can we use tomorrow's call for kickstarting this discussion.
> A good starting point would be the presentation from last week's LPC
> on Kernel cgroups and namespaces: Can they contribute to FFI claims?
> https://linuxplumbersconf.org/event/11/contributions/1079/
> Including some of the questions raised by Bruce and Priyanka in their
> closing slide.
> Regards
> Elana
>
> -----Original Message-----
> From: devel@... <devel@...> On Behalf Of
> Paul Albertella
> Sent: Wednesday, September 29, 2021 12:23 PM
> To: devel@...
> Subject: Re: [ELISA Technical Community] LPC 2021 presentation -
> Kernel cgroups and namespaces: Can they contribute to FFI claims?
>
> Hi Elana,
>
> On 29/09/2021 06:50, elana.copperman@... wrote:
> > And in a more general sense, what are the criteria for acceptance of
> > such kernel features as the basis for safety claims such as FFI?
> >
> > @Paul Albertella <mailto:paul.albertella@...> - I would
> > hope that your new WG will be helpful to make clear guidelines on
> > such
> questions.
>
> Yes, that's very much my intention!
>
> There are really two broad sets of criteria, which can be summarised
> in the following two questions:
>
> 1) What role does the feature have in achieving a safety goal?
> 2) What gives us confidence that the feature can fulfil that role?
>
> In my opinion, there's nothing to *prevent* us from using any Linux
> feature as the basis for a safety claim, provided that we can:
>
> * Document our answers to these questions (Assertions)
> * Provide material to support these answers (Evidence)
>
> The challenge is that we then have to satisfy a safety assessor that
> these are valid and sufficient!
>
> One of the issues we face when answering these questions for Linux
> (and open source software in general) is that the 'traditional'
> answers (as described in safety standards like ISO 26262) are not
> always well-supported by either assertions or evidence from open source communities.
>
> However, it's vitally important to recognise that safety standards do
> allow for 'non-traditional' answers and evidence, provided that we are
> prepared to make a reasoned argument to support these.
>
> My goal with the OSEP WG is to explore specific examples of this, to
> understand what Linux contributors (or maintainers) and safety system
> developers (or integrators) can do to both frame better answers and
> provide better evidence.
>
> Regards,
>
> Paul
>
>
>
>
>
>
>
>
>
>
|
|
|
Hi,
Regarding the Priyanka and Bruce's presentation, I think the pre-requisite for using namespaces and cgroups for FFI is to "qualify" these mechanisms. This means showing that they fulfill their (reverse-engineered?) requirements and also don't cause interference by themselves.
Thanks,
Eli
toggle quoted message
Show quoted text
-----Original Message----- From: devel@... <devel@...> On Behalf Of elana.copperman@... Sent: Wednesday, September 29, 2021 12:40 To: Paul Albertella <paul.albertella@...>; devel@... Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims? Totally agreed with the problem space, and the proposed path forward. Paul - until we sort out the final details of "development process" WG evolution, can we use tomorrow's call for kickstarting this discussion. A good starting point would be the presentation from last week's LPC on Kernel cgroups and namespaces: Can they contribute to FFI claims? https://linuxplumbersconf.org/event/11/contributions/1079/Including some of the questions raised by Bruce and Priyanka in their closing slide. Regards Elana -----Original Message----- From: devel@... <devel@...> On Behalf Of Paul Albertella Sent: Wednesday, September 29, 2021 12:23 PM To: devel@... Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims? Hi Elana, On 29/09/2021 06:50, elana.copperman@... wrote: And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on such questions. Yes, that's very much my intention! There are really two broad sets of criteria, which can be summarised in the following two questions: 1) What role does the feature have in achieving a safety goal? 2) What gives us confidence that the feature can fulfil that role? In my opinion, there's nothing to *prevent* us from using any Linux feature as the basis for a safety claim, provided that we can: * Document our answers to these questions (Assertions) * Provide material to support these answers (Evidence) The challenge is that we then have to satisfy a safety assessor that these are valid and sufficient! One of the issues we face when answering these questions for Linux (and open source software in general) is that the 'traditional' answers (as described in safety standards like ISO 26262) are not always well-supported by either assertions or evidence from open source communities. However, it's vitally important to recognise that safety standards do allow for 'non-traditional' answers and evidence, provided that we are prepared to make a reasoned argument to support these. My goal with the OSEP WG is to explore specific examples of this, to understand what Linux contributors (or maintainers) and safety system developers (or integrators) can do to both frame better answers and provide better evidence. Regards, Paul --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
|
|
|
+1
I didn't want to be the first one to say it, but this question applies to all Linux features or mechanisms.
Like
- SELinux
- seccomp
- BPF
- eBPF
- and, and, and...
This makes enabling Linux to be used in safety-critical applications very challenging...
John
toggle quoted message
Show quoted text
On 29/09/2021 14:18, Gurvitz, Eli (Mobileye) wrote: Hi,
Regarding the Priyanka and Bruce's presentation, I think the pre-requisite for using namespaces and cgroups for FFI is to "qualify" these mechanisms. This means showing that they fulfill their (reverse-engineered?) requirements and also don't cause interference by themselves.
Thanks,
Eli
-----Original Message-----
From: devel@... <devel@...> On Behalf Of elana.copperman@...
Sent: Wednesday, September 29, 2021 12:40
To: Paul Albertella <paul.albertella@...>; devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?
Totally agreed with the problem space, and the proposed path forward.
Paul - until we sort out the final details of "development process" WG evolution, can we use tomorrow's call for kickstarting this discussion.
A good starting point would be the presentation from last week's LPC on Kernel cgroups and namespaces: Can they contribute to FFI claims? https://linuxplumbersconf.org/event/11/contributions/1079/
Including some of the questions raised by Bruce and Priyanka in their closing slide.
Regards
Elana
-----Original Message-----
From: devel@... <devel@...> On Behalf Of Paul Albertella
Sent: Wednesday, September 29, 2021 12:23 PM
To: devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?
Hi Elana,
On 29/09/2021 06:50, elana.copperman@... wrote:
And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on such questions. Yes, that's very much my intention!
There are really two broad sets of criteria, which can be summarised in the following two questions:
1) What role does the feature have in achieving a safety goal?
2) What gives us confidence that the feature can fulfil that role?
In my opinion, there's nothing to *prevent* us from using any Linux feature as the basis for a safety claim, provided that we can:
* Document our answers to these questions (Assertions)
* Provide material to support these answers (Evidence)
The challenge is that we then have to satisfy a safety assessor that these are valid and sufficient!
One of the issues we face when answering these questions for Linux (and open source software in general) is that the 'traditional' answers (as described in safety standards like ISO 26262) are not always well-supported by either assertions or evidence from open source communities.
However, it's vitally important to recognise that safety standards do allow for 'non-traditional' answers and evidence, provided that we are prepared to make a reasoned argument to support these.
My goal with the OSEP WG is to explore specific examples of this, to understand what Linux contributors (or maintainers) and safety system developers (or integrators) can do to both frame better answers and provide better evidence.
Regards,
Paul
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
|
|
|
I think this was in the domain of Paul's new WG, and the basis for collaboration with his new flavor of the Dev Process WG.
toggle quoted message
Show quoted text
-----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor Sent: Wednesday, September 29, 2021 3:52 PM To: Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; devel@... Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims? +1 I didn't want to be the first one to say it, but this question applies to all Linux features or mechanisms. Like - SELinux - seccomp - BPF - eBPF - and, and, and... This makes enabling Linux to be used in safety-critical applications very challenging... John On 29/09/2021 14:18, Gurvitz, Eli (Mobileye) wrote: Hi,
Regarding the Priyanka and Bruce's presentation, I think the pre-requisite for using namespaces and cgroups for FFI is to "qualify" these mechanisms. This means showing that they fulfill their (reverse-engineered?) requirements and also don't cause interference by themselves.
Thanks,
Eli
-----Original Message-----
From: devel@... <devel@...> On Behalf Of
elana.copperman@...
Sent: Wednesday, September 29, 2021 12:40
To: Paul Albertella <paul.albertella@...>;
devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?
Totally agreed with the problem space, and the proposed path forward.
Paul - until we sort out the final details of "development process" WG evolution, can we use tomorrow's call for kickstarting this discussion.
A good starting point would be the presentation from last week's LPC on Kernel cgroups and namespaces: Can they contribute to FFI claims? https://linuxplumbersconf.org/event/11/contributions/1079/
Including some of the questions raised by Bruce and Priyanka in their closing slide.
Regards
Elana
-----Original Message-----
From: devel@... <devel@...> On Behalf Of
Paul Albertella
Sent: Wednesday, September 29, 2021 12:23 PM
To: devel@...
Subject: Re: [ELISA Technical Community] LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?
Hi Elana,
On 29/09/2021 06:50, elana.copperman@... wrote:
And in a more general sense, what are the criteria for acceptance of
such kernel features as the basis for safety claims such as FFI?
@Paul Albertella <mailto:paul.albertella@...> - I would
hope that your new WG will be helpful to make clear guidelines on such questions. Yes, that's very much my intention!
There are really two broad sets of criteria, which can be summarised in the following two questions:
1) What role does the feature have in achieving a safety goal?
2) What gives us confidence that the feature can fulfil that role?
In my opinion, there's nothing to *prevent* us from using any Linux feature as the basis for a safety claim, provided that we can:
* Document our answers to these questions (Assertions)
* Provide material to support these answers (Evidence)
The challenge is that we then have to satisfy a safety assessor that these are valid and sufficient!
One of the issues we face when answering these questions for Linux (and open source software in general) is that the 'traditional' answers (as described in safety standards like ISO 26262) are not always well-supported by either assertions or evidence from open source communities.
However, it's vitally important to recognise that safety standards do allow for 'non-traditional' answers and evidence, provided that we are prepared to make a reasoned argument to support these.
My goal with the OSEP WG is to explore specific examples of this, to understand what Linux contributors (or maintainers) and safety system developers (or integrators) can do to both frame better answers and provide better evidence.
Regards,
Paul
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
|
|
|
