Re: LPC 2021 presentation - Kernel cgroups and namespaces: Can they contribute to FFI claims?

Gabriele Paoloni

Hi All

On Wed, Sep 29, 2021 at 11:26 AM Paul Albertella <paul.albertella@...> wrote:
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...

> @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

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.



Join to automatically receive all group messages.