Category:Safety Certification: Difference between revisions

This page links to documents, public discussions, meetings, etc. related to Safety Certification of Xen Project based products or code-lines.

At this stage this category is primarily a place where to track various activities and also to see who is interested in certification efforts of Xen and who could perform which role.

Industry Groups having a stake in certifying Open Source Stacks

• Automotive Grade Linux Virtualization Expert Group

• Members with Xen based products: GlobalLogic (bronze), StarLab (bronze)
• Members which indirectly support/have supported Xen in this context: Renesas (platinum), Arm (gold)
• Members which have showed up at Xen channels more than once: ADIT (bronze), Harman (bronze), LG (bronze)
• Members which are also Advisory Board members: Amazon (silver), Qualcomm(silver), Oracle (bronze)

• Genivi: Hypervisor Team (or a group that will eventually become one)

• Members with Xen based products: EPAM (2nd tier), GlobalLogic (2nd tier)
• Members which indirectly support/have supported Xen in this context: Renesas (silicon), Arm (silicon)
• Members which have showed up at Xen channels more than once: Bosch (1st), Harman (1st), LG (1st)
• Members which are also Advisory Board members: Intel (silicon), Qualcomm(silicon)

• Linaro: I am not sure whether there is a Linaro group yet, if so it would be worth adding it here

Relevant Presentations and Papers

Xen Specific

• Summary Table Comparing Different Hypervisors (March 2018)
• Xen and the Art of Certification - Nathan Studer, DornerWorks, 2014: video, slides

Industry Wide

• The AGL software defined connected car architecture, April 2018: whitepaper
• TSC Sponsored BoF: Can Linux and Automotive Functional Safety Mix ? Take 2: Towards an open source, industry acceptable high assurance OS, Robin Randhawa, 2017: slides

Automotive Requirements

Automotive functions requirements for virtualized ECUs (copied from the AGL whitepaper)

To Do: It would be good, if we could map these to specific Xen Features, such that we see where there are gaps.

Computing

• C1: Static resource partitioning and flexible on-demand resource allocation (CPU, RAM, GPU and IO).
• C2: Memory/IO bus bandwidth allocation and rebalancing.

Peripherals sharing

• P1: GPU and displays shall be shared between execution environments supporting both fixed (each one talks to its own display or to a specified area on a single display) and flexible configurations (shape, z-order, position and assignment of surfaces from different execution environments may change at run time).
• P2: Inputs shall be routed to one or multiple execution environments depending on current mode, display configuration (for touchscreens), active application (for jog dials & buttons), etc.
• P3: Audio shall be shared between execution environments. Sound complex mixing policies for multiple audio streams and routing of dynamic source/sink devices (BT profiles, USB speakers/microphones, etc.) shall be supported.
• P4: Network shall be shared between execution environments. Virtual networks with different security characteristics shall be supported (e.g., traffic filtering and security mechanisms).
• P5: Storage shall support static or shared allocation, together with routing of dynamic storage devices (USB mass storage).

Security

• SE1: Root of Trust and Secure boot shall be supported for all execution environments.
• SE2: Trusted Computing (discrete TPM, Arm TrustZone or similar) shall be available and configurable for all execution environments.
• SE3: Hardware isolation shall be supported (cache, interrupts, IOMMUs, firewalls, etc.).
• SE4: Secure updates shall be supported.

Performance and Power consumption

• PP1: Virtualization performance overhead shall be minimal: 1-2% on CPU/memory benchmarks, up to 5% on GPU benchmarks.
• PP2: Predictability shall be guaranteed. Minimal performance requirements shall be met in any condition (unexpected events, system overload, etc.).
• PP3: Execution environments fast boot: Less than 2 seconds for safety critical applications, less than 5 seconds for Instrument Cluster, and 10 seconds for IVI. Hibernate and Suspend to RAM shall be supported.
• PP4: Execution environments startup order shall be predictable.
• PP5: Advanced power management shall be implemented with flexible policies for each execution environment.

Safety

• SA1: System monitoring shall be supported to attest and verify that the system is correctly running.
• SA2: Restart shall be possible for each execution environment in case of failure.
• SA3: Redundancy shall be supported for the highest level of fault tolerance with fallback solutions available to react in case of failure.
• SA4: Real time support shall be guaranteed together with predictive reaction time.

Functional Safety Requirements

Safety Certification

To Do: I left this out for now, but Safety Certification Challenges provides some initial pointers to groups of information.

Code Size impacting the cost of Safety Certification

To Do: Add coarse analyses from misc e-mail threads.

Products using Xen and OpenEmbedded that need/have a degree of Safety Certification

Products with a degree of Safety Certification

• DornerWorks Virtuosity

Automotive Products

• EPAM xen-troops
• Global Logic Nautilus

Embedded/Other Products

• OpenXT
• Star Lab Crucible
• Xilinx
• DornerWorks Virtuosity for i.MX 8

Contributor Spotlights

• GlobalLogic
• DornerWorks
• StarLabs
• Stefano Stabellini