Written by Elana Copperman, ELISA project ambassador and System Safety Architect at Mobileye (Intel)
This blog has been updated with the video from the Linux Security Summit (LSS), which took place on September 29-October 1.
Are you attending the upcoming Embedded Linux Conference (ELC) on September 27-30 or the Linux Security Summit (LSS) on September 29-October 1? This year, attendees have the option of joining the conference on-site in Seattle, Washington or virtually from their homes and workplaces.
Security and Safety have common goals, yet often follow divergent development paths. We will take a look at various Linux features which were originally designed for security, investigating if/how these features may be relevant to enable safety critical applications.
For example, we’ll discuss:
Memory protection features
Isolation techniques and FFI (Freedom From Interference)
Timing and execution
ebpf and profiling
Safety extensions to Linux drivers
I will present practical implications – focusing on where security and safety meet and where they don’t meet. The presentation, which is intended for experienced software developers and architects, will focus on how these features may be used in real systems. The goal is to spark discussion on how safety mechanisms may be designed in Linux-based safety critical systems, by learning from solutions in the security domain. Watch the video below or check out the presentation here.
Click here to register for the Linux Security Summit or here to learn more about the conference.
The Linux Plumbers Conference, which happened virtually on September 20-24, had a packed schedule of microconferences and tracks for the kernel, networking & BPF, GNU Tools, Birds of Feather and more. To see the complete schedule, check out the main conference page at https://www.linuxplumbersconf.org/event/11/.
Shuah Khan, Chair of the ELISA Project Technical Steering Committee and a Kernel Maintainer and Linux Fellow at the Linux Foundation, teamed up with Gabriele Paoloni, Chair of the ELISA Project Governing Board, Safety Architecture Working Group Chair and an Open Source Community Technical Leader at Red Hat, to run the Kernel Dependability and Assurance Microconference on Thursday, September 23. The Kernel Dependability and Assurance Microconference focused on infrastructure to be able to assure software quality and that the Linux kernel is dependable in applications that require predictability and trust.
If you missed the conference, you can watch the video below.
Additionally, several other ELISA Project ambassadors and community members presented sessions including Daniel Bristot de Oliveira, Principal Software Engineer at Red Hat, Sudip Mukherjee, a Kernel Engineer at Codethink, and Lukas Bulwahn with Elektrobit GmbH.
Check out the schedule below for the Microconference on Thursday, September 23 at 7 – 11 am PDT.
Written by Shuah Khan, Chair of the ELISA Project Technical Steering Committee
Please join me in welcoming Jason Smith, Paul Albertella and Philipp Ahmann to the ELISA TSC. They have made significant contributions to the ELISA project and their addition will strengthen the TSC and help us continue to make progress with our mission.
A brief summary of their background and contributions are as follows:
Jason Smith, the Principal Engineer for Robotics and Control Systems Consumer Technology at UL LLC., has:
– Contributed a Linux in Basic Safety White paper to the project
– Participates in the Medical Devices Working Group regularly
– Contributed the analysis of 62304 SOUP
– Speaks frequently at ELISA Workshops and is an ELISA ambassador
Paul Albertella, Consultant at Codethink, has:
– Participated in ELISA since the inception.
– Presented technical content at the last two ELISA workshops
– Contributes in the TSC and other working groups, where he’s been a constructive collaborator
– 20+ years of software engineering experience and understands the open source ecosystem challenges
Philipp Ahmann, a manager at ADIT (a joint venture of Robert Bosch GmbH and DENSO Corporation) has:
– Participated in ELISA since the start of the project
– Took the lead in helping the project to improve communication and set up our LinkedIn presence
– Volunteered to be an active ambassador on behalf of the project
– Participates in the TSC and other working groups, where he’s known to be a very constructive contributor with an excellent overview across all the different areas we’re working on
– Demonstrates a helpful attitude by being willing to step in and host meetings when the chair is not available
– He is able to actively listen, and helps bring focus to the key elements we need for the project
I look forward to collaborating more closely with all three of our new TSC members. As a reminder, all are welcome to join the bi-weekly public technical community meeting and to contribute your perspectives. You can find the meeting details and subscribe to the calendar here: https://lists.elisa.tech/g/devel/calendar.
Written by EliGurvitz, ELISA Project Ambassador and Functional Safety Architect at Intel (Mobileye)
In a functional safety system FFI is required when the system consists of elements of different Safety Integrity Levels (ASIL).This is to ensure that elements allocated with a lower ASIL do not interfere with elements allocated with a higher ASIL; if FFI cannot be demonstrated the lower ASIL elements must be upgraded to the higher ASIL.
The Architecture Working Group has been discussing “Freedom From Interference (FFI)” in the last several meetings and is considering two aspects:
FFI between user space processes allocated with different ASIL
FFI between Linux Kernel components/drivers/subsystems allocated with different ASIL
This blog post focuses on the second bullet.
FFI is a key goal of a possible Safety Concept for Linux because Linux is too complex and has too many features, thus considering Linux as a single element of a certain ASIL would result in a very high functional safety qualification effort. If the application runs in a single threaded process and handles interrupts synchronously, then it may be possible to avoid allocating Safety Requirements to the OS and mitigate all failures with application-level safety mechanisms. But this kind of use requires just a simple OS and Linux is an overkill. Using Linux in the way it was meant to be used means it will be the OS of a multi-core SoC that runs many processes with different requirements of different ASILs.
This mode of use is referred to in ISO 26262 part 6 section 7.4.8:
This section refers to ISO 26262 part 9 Clause 6 “Criteria for co-existence of elements”. This clause states:
The Architecture WG investigation considers the Linux kernel partitioned into sub-elements of mixed criticality, therefore the goal is to show FFI between the sub-elements. The approach to FFI that is currently being discussed in the Architecture WG was developed by ELISA Project members Mobileye and BMW.
The first step in demonstrating FFI between safety-related and non-safety-related sub-elements is to identify the sub-elments and to allocate them with an ASIL. Since we are analyzing a SW component, the sub-elements are functional areas (or features) of the kernel, e.g. memory management or file systems, and they are made of C language functions. We classify the C functions according to the allocated ASIL by using the Call Tree Tool.
The goal of Call Tree is to statically generate the tree of function calls departing from a specified input one; hence starting for example from a syscall, Call Tree would generate the tree of all invoked functions. Call Tree scans the Linux source code by using the GNU CFlow utility and generates an SQLite database that contains all functions and their calling relations – this provides an almost full call-tree for every C function.
To classify every Kernel function we allocate Kernel entrypoints (syscalls and interrupt handlers) with safety requirements and associated ASIL; hence every function falling in a certain tree inherits the ASIL associated with the top level entrypoint. If a function is present in multiple trees, it is then assigned with the highest ASIL across those allocated to the different trees.
For example, if there’s a safety requirement for “safe dynamic memory” then we consider the related system calls – mmap, sbrk – as safety related. The union of all functions in the call trees of mmap and sbrk are considered SR and inherit the ASIL allocated to mmap and sbrk.
Once we have partitioned the Kernel the next step is to consider the possible types of interference. These types are defined in Annex D or ISO 26262 part 6. There are three types of interference:
Temporal – interference related to time or scheduling. The most common case is when one kernel thread prevents other threads from getting CPU cycles, thereby causing delays. Another example is a process crashing.
Spatial – interference related to space, or memory. For example, a lower ASIL driver may corrupt a kernel data structure.
Communication – normally this type of interference relates to transfer of data between two entities over a communication channel. In our analysis we consider static and global variables and pointers as communication channels between sub-elements of the kernel.
The Architecture Working Group plans to deal with all types of interference and currently we are considering the third type – communication interference. We are looking at areas where the internal state of the kernel can be corrupted because of the interaction between NSR and SR C functions (or more generally, C functions of different ASIL ratings).
The internal state of the kernel consists of many persistent data structures. These data structures, for example linked lists, are pointed to by global and static variables and pointers. Corruption of these data structures can occur in different ways.
Data structures that are accessed via global variables can be corrupted when a lower ASIL function (for example a driver that is rated as ASIL QM) accesses the same data structure that is also used by an ASIL-B function, as depicted in the diagram below.
Corruption of data structures that are accessed via static variables can occur when a static variable is used by a higher ASIL (or SR) function but this function is used by a lower ASIL (or NSR) function. The NSR function may pass a faulty argument to the SR function and the SR function may use this argument to modify the data structure. The faulty data structure is later used in a safety-related flow. This failure mode is depicted in the diagram below.
This description is only a preliminary formulation of the concept of communication interference within the kernel. The working group is debating the correct use of terms, the concept itself, the correct use of the Call Tree Tool and the selection of ASIL rated system calls for our sample automotive use case – The Tell-Tale signal.
If you are interested in safety engineering, the Linux kernel, or both, then please join us in these discussions. The nice thing about applying the existing Functional Safety standards to the Linux kernel is that there’s plenty of space and freedom for creativity, as these standards were designed for much simpler HW and very much simpler SW. It is as if there’s a written tradition of Safety architecture – the ISO 26262 standard and an Oral interpretation of it which creates a more modern tradition of Safety. You can be a part of creating this tradition. I should also take back the word “creativity” I used four lines above because it will certainly trigger a hot debate around the question of whether Safety likes “creativity” or hates it. So I’ll clarify that we are trying to be creative in a conservative way.
Learn more about the ELISA Architecture Working Group or any of the other groups in this white paper.
In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions titled “A Guided Tour Through the PREEMPT RT castle” presented by Thomas Gleixner, CTO at Linutronix GmbH.
The tour through the inner workings of PREEMPT_RT will start at the observation deck to give an conceptual overview. From there it will take the participants through the various chambers which contain a broad range of historic and contemporary operating system technologies. The tour will not only take the hallways it is also going to explore some of the secret passages and the brave-hearted can take a glimpse at the horror cabinets.
General knowledge about operating system concepts is recommended for taking the tour, but of course it’s open for everyone and all chambers have exit doors if it gets too spooky.
In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions titled “ELISA and AUTOSAR Adaptive Brainstorm” led by Philipp Ahmann, ADIT GmbH, Huzaifa Saadat, Autosar Experts & Wolfgang Schramm, Continental AG.
AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry. The ELISA Project started working more closely with AUTOSAR and Automotive Grade Linux (AGL) and now has a Working Group dedicated to this collaboration.
The AUTOSAR Consortium Working Group Safety works closely with the ELISA Project Automotive Working Group. Previously, the group collaborated to figure out which requirements are put to the system and if assumptions from the Automotive WG can fit with AAUTOSAR expectations. The discussions with AUTOSTAR should harden the work within the ELISA Automotive WG. In this workshop video, Philipp Ahmann, Huzaifa and Wolfgang discuss the work within the ELISA Project, collaboration and host a brainstorm about next steps and more. Watch it here:
Click here learn more about the ELISA Project, here for the Working Groups and here to join our mailing list.
In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions led by Daniel Bristot de Oliveira, Principal Software Engineer at Red Hat, and Gabriele Paoloni, Senior Software Architect at Intel, titled “A Maintainable and Scalable Kernel Qualification Approach for Automotive.”
In this presentation, Daniel and Gabriele present an innovative approach that aims for the Functional Safety qualification of Linux by leveraging both ISO26262-6 and ISO26262-8.12.
The goal of this presentation was to get feedback on the approach suitability from a Functional Safety point of view, the approach usability in the current Linux mainline development flow and discuss about the next steps.
If you would like to learn more, Daniel and Gabriele will be giving an updated presentation at Embedded Linux Conference on September 28. Learn more about the session and other ELISA talks here.
Since launching in 2019, the ELISA Project has continued to grow in membership, community contributions and working groups. The project’s more than 20 member companies, which include ADIT, AISIN AW CO., arm, Automotive Grade Linux, BMW Car IT GmbH, Codethink, Elektrobit, Horizon Robotics, Huawei Technologies, Intel, Kuka, Linuxtronix, Mentor, NVIDIA, OTH Regensburg, Red Hat, Suzuki, Toyota and Wind River, collaborate to define and maintain a standardized set of processes and tools that can be integrated into Linux-based, safety-critical systems seeking safety certification.
Today, the ELISA Project is excited to announce that its next technical workshop will take place virtually on November 8-10. The event is free and open to developers, users and contributors of ELISA from around the globe looking to learn, network and collaborate.
The Call for Papers is now open and accepting submissions that will tackle technical strategies for development and deployment as well as real-world applications and use cases. Submit a speaking proposal by Friday, October 1 here: https://events.linuxfoundation.org/elisa-workshop/program/cfp/.
The last workshop took place in May with 239 participants from 37 different countries. It featured sessions that showcased working group milestones, open discussions about projects and use cases in automotive and medical. Additionally, this workshop involved more collaboration with adjacent communities, such as Xen, Real Time Linux and AUTOSAR. For a complete recap of the workshop, click here.
The ELISA Workshops are hosted once a quarter and are focused on education and outreach for new community members, the exchange of ideas and feedback from the linux kernel and safety communities, as well as productive collaboration to make tangible progress toward achieving the mission and goals of the ELISA Project.
Registration for the event is also open. You can register here.
In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions led by Jason Smith, Principal Engineer at UL LLC, about the “Linux in Basic Safety Applications.”
Linux is more often being used in applications with safety relevance:
Complex safety-related functions necessitating the advantages of an OS, or
Complex end application necessitating the advantages of an OS, now being asked to perform one or more basic safety-related functions (for example: voltage, current, temperature monitoring)
In both cases, software used to implement the safety-related functions may be required to conform/comply with applicable functional safety standards.
In this presentation, Jason will discuss linux in basic safety applications, the goals and progress of the white paper the ELISA Project is working on and details about how to get involved.
Click here learn more about the ELISA Project, here for the Working Groups and here to join our mailing list.
In May, the ELISA Project hosted its 7th Workshop with 239 participants from 37 different countries. For a complete recap of the workshop, click here. Today, we’ll take a look at one of the sessions led by Jochen Kall, Expert Engineer Safety at ITK Engineering on behalf of Toyota about the “Open Source Software Safety Concept Tooling in Freeplane.”
The Automotive Working Group uses an open source software mindmap based tooling for developing and documenting Safety Concepts as well as managing the requirements therein. In this session, an introduction to the tool, its capabilities, and use cases is given, followed by a setup/tutorial session guiding the audience through installation and setup of the tool as well as a demonstration of how it can be used in safety engineering.
Freeplane is available on github ((https://github.com/Jochen-Kall/Safety_concept_tool) and helps Safety/Requirements Engineering tasks with support for: – Avoiding duplication of repeated requirements, leveraging clones – Managing artifact types, ASILs ,etc and their respective constraints – Allocating to architectural elements – Code tagging – Safety Consistency checking – Tainting/Changing Propagation in the tree – Exporting / Importing [WIP]
Watch the video below and let us know if you have questions!
Click here learn more about the ELISA Project, here for the Working Groups and here to join our mailing list.