Hi Elana,

Sorry to go against your grain, but I decided to change the title to split the discussions for the two proposals. Otherwise, I think that the threads will get overly complicated.

For a start...

Call the WG what you want, but I find "Linux Developers" confusing. It could people who develop with Linux or people who develop Linux... or something entirely different. Under Linux I think of the people who contribute to the kernel, such as those listed in the statistics for a release (such as [1]).

I suggest something along the lines "Kernel Features" or "Applying Kernel Features".

The scope of this WG does not in any way include safety qualification or any safety claims on how the integrator can or should use these
features or patches. The only claims that would be made are a
description of the feature and its functional impact. Evidence to
support deployment of any feature in a safety-critical system may be
clarified by work products produced by the other ELISA WGs, focusing
on collaboration as outlined by Paul above.

I think that an independent Elisa WG must directly fulfil the project mission statement [2]. How do you reconcile the mission of the Linux Developers WG with the Elisa mission statement? (BTW, the "amenable to safety certification" comes from me and although the statement is ambiguous through its complexity, the intention is that the project work products, not just the safety-critical systems, be amenable).


[1] https://lwn.net/Articles/867540/
[2] https://elisa.tech/wp-content/uploads/sites/75/2020/08/elisa_technical_charter_082620.pdf

Cheers

John

On 14/09/2021 16:40, elana.copperman@... wrote:

Thanks, Paul, for your clear summary of previous discussions.
My added inputs are included below Paul's text.  The proposed name for the new WG remains TBC, I am open to suggestions.
As noted by Paul, this has been extensively discussed in the recent Dev Process WG weekly calls.
My expectation is to announce this new format in the upcoming ELC/LSS conference, as well as in the
next ELISA workshop, thus inviting new members to join and to contribute.
Regards
Elana
------------------------------------------------------------------------
*From:* devel@... <devel@...> on behalf of Paul Albertella <paul.albertella@...>
*Sent:* Tuesday, September 14, 2021 4:05 PM
*To:* devel@... <devel@...>
*Subject:* [ELISA Technical Community] New WG proposal: Safety Engineering Process
Hi,
The Development Process working group has been discussing proposals for
the evolution of the group. The WG has historically attempted to cover a
number of goals in a single context, which has occasionally created
confusion; to address this, we propose to split into two separate
working groups, each with a clearer focus.
Elana Copperman and I have proposed mission statements and planned
activities for these two new groups, which have been discussed in the
Dev Process WG weekly calls.
Having reached some consensus about a way forward in that forum, I'd now
like to share my proposal (see below) with the wider ELISA community for
comment, before seeking to formalise the group at the TSC. I hope that
Elana will share details of her proposal in due course.
Regards,
Paul
---------------------------------------------------------------------
Proposed working group name
---------------------------
Safety Engineering Process
Proposed WG chair
-----------------
Paul Albertella
Proposed meeting schedule
-------------------------
Weekly on Thursday, in the same slot as the current Dev process call
Proposed mission statement
--------------------------
This working group aims to examine safety-related claims that we might
like to make about Linux as part of a system, and to explore how we can
gather and present evidence to support such claims as part of a safety
engineering process.
We are interested in two broad classes of claims and evidence:
a) Those relating to development practices for Linux as a whole; for
example, the peer review process for patches, the testing performed on a
kernel stable branch when preparing a release, or the testing performed
by a system integrator for a product that incorporates Linux
b) Those relating to specific properties or behaviour of Linux; for
example, features that we can enable or disable in a kernel config, the
(inferred) design of a subsystem, the characteristics of a driver, or
tests that can verify aspects of a given feature
For (b), we will focus on engineering process aspects (construction,
verification, integration, use and maintenance) relating to the feature
or property, rather than technical details of its design/implementation.
In both cases we may examine practices or processes that are undertaken
by the Linux kernel community, as well as communities or organisations
that consume Linux (e.g. AGL, LTP), or we may identify practices or
processes from other sources that might be used by organisations who
want to use Linux to build systems with safety requirements.
Planned activities
------------------
Our objectives are to:
* Define claims that we would like to make about Linux and/or the
   processes used to develop it or integrate it as part of a product
* Identify evidence that we might use to support these claims
* Identify strategies or tools that we can use to gather, generate or
   reformulate evidence (perhaps in collaboration with the Tools WG)
* Examine the evidence gathered and document our findings
* Share and peer-review our findings in an elisa.tech Github repo
Possible claims might be proposed by another WG, perhaps in relation to
a specific use case, technique or safety argument, or we may select our
own. Claims that we examine may not all be safety claims, per se; some
might relate to software quality, for example, or functionality that
does not have an explicit safety role, since both of these may be needed
to support safety arguments.
We will use contributors’ knowledge of specific safety standards to
inform our work where appropriate - for example to determine what
criteria to apply for a given class of evidence - but specifying how a
given claim and its supporting evidence may be used as part of a
certification process should be considered out of scope.
Where we do not have consensus on results or conclusions, we will
document the different perspectives and/or open questions. We will
manage the material produced in an elisa.tech Github repo and
collectively review it in GitHub PRs, inviting review or input from the
rest of the ELISA community where appropriate.
As part of this work, we also plan to write a summary of the results and
conclusions of the work done by the Development Process WG, which will
also be made available in an elisa.tech Github repo. This is intended to
provide background for new participants and other WGs, as well as a
baseline / conceptual framework for the work of the new group.
Collaboration
-------------
The group expects to collaborate with the existing working groups and
with the new group proposed by Elana, both to identify or discuss claims
and evidence for analysis, and to address wider questions relating to
safety engineering processes. Where we work with another group on given
topics, we may jointly present the results at an Elisa workshop.
*********************************************************************************************
Proposed working group name
---------------------------
Linux Developers WG
Proposed WG chair
-----------------
Elana Copperman
Proposed meeting schedule
-------------------------
Weekly on Mondays, pending availability of participants
Proposed mission statement
-------------------------
*
*
To identify existing Linux Kernel features which may be leveraged
for use in safety critical systems.
*
For example,
1.
Mechanisms for protections of various memory types.
2.
Dynamic analysis for multi-threaded systems.
3.
Kernel profiling using ebpf-based tools.
4.
Isolation techniques and FFI (Freedom From Interference)
5.
Safety extensions to Linux drivers.
6.
*
To bring together kernel developers and producers of safety critical
systems to demonstrate use of
*
such features in real systems, and to learn from these experiences
together as a community.
*
*
To propose enhancements to such features and to work as a community
to design / implement /
o
deploy kernel patches.  Such patches should help to make those
features more amenable
o
for use in safety critical systems.
o
*
To recommend tools or processes to be provided by other ELISA WGs so
that those patches
*
and features can be used by designers and integrators producing
safety critical systems.
*
*
*Planned activities
------------------
*
The scope of this WG does not in any way include safety qualification or any safety claims on how the *
*integrator can or should use these features or patches.  The only claims that would be made are a *
*description of the feature and its functional impact. *
**Evidence to support deployment of any feature in a safety-critical system may be clarified by work
products produced by the other ELISA WGs, focusing on collaboration as outlined by Paul above.
The work group will invite developers of safety critical systems to identify and to enhance existing
kernel features with elements that may be used effectively to support safety claims.