[Xen-devel] Notes of Design Session: Xen Certification in Automotive Industrial

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

There were also attendees from Advanced Driver Information Technology, Audi & 
Bosch whose e-mail addresses I don't have
This was quite a muddled discussion, which was not easy to capture. 
This is a first go at capturing it, but I missed large swathes of it
Feel free to add/correct as needed

Also, I am not quite sure who said what, because it was quite fast at points

The discussion was prompted by http://sched.co/Aj9l
The design session is at http://sched.co/AjE3

Regards
Lars

Introduction
============

Critical systems/automation control systems require isolation but certification
Security such as XSM/Flask is also a requirement

Xen is the best solution from a security PoV

Can use Xen as HV and isolation system
In such a scenario the Hypervisor and uKernels running guests would have to be 
certified for specific use-cases


Certification Problem
=====================

Requires development process to be executed in a specific way (e.g. ISO2 
26262/ASIL-B certification)
Note that different certifications will have slightly different requirements

The development model required by to certify is quite different from FOSS 
development models

Only way to do this today: 
Fork a specific version of Xen (or any FOSS project), follow the process with 
maybe pooling resources, ... 

This would require key stake-holders collaborating on a certified version of a 
Xen "distro" around some defined use-cases


Iurii's proposal
================
See http://sched.co/Aj9l and attached slides
The basic idea is to separate the system below the hypervisor (e.g. via 
TrustZone, TEE)

In other words, we would try to not certify the hypervisor
In such a scenario, the main focus of certification would be to prove that one 
part of the system does not influnce the other
E.g. this is for example done for QNX with software running outside the 
certification boundary. E.g an uncertified vault interacting with a certified 
one

E.g. shared memory between certified + uncertified
=> basically we will need to prove that ANY data in shared memory written by 
uncertified world, does not negatively affect certified world

Iurii also highlighted that the key point of certification is NOT that you can 
avoid mistakes, but that YOU CAN DETECT IT

Then we looked at some Xen examples, such as whether 0-copy in Xen would still 
be doable
To which the answer was yes

There was also a question on whether HW would need to be certified
To which the answer is that for example the Renesas R-CarH3 is compliant with 
ISO 26262 (ASIL-B)

Then there was a bit of discussion around use-cases and specifications
======================================================================
The first thing which was discussed was use-cases.
The basic premise is that you don't certify code, but use-cases (including 
everything from HW to SW which are touched by a use-case)
Changes in code (e.g new features or security fixes) may require a 
certification to lapse and require it to be redone
Bit it is possible to safety certify deltas (e.g. patches or security fixes)

If we don't know the exact use-cases to be certified, we can't be ready for the 
certified world

One approach which can help is to cover as many possible use-cases upfront, for 
example in PV protocols
By getting protocols as future-proof as possible and by supporting a maximum 
number of possible use-cases, we can avoid future re-certification 

Aka: try to not pollute future designs and keep things as stable as possible in 
the long run


Is there anything we can do as a community to make certification easier
=======================================================================
This was a little bit muddled

* Try to get protocols as watertight and waterproof as possible
  - Need to understand the UC's: this could be reflected in version of 
protocols and ABIs - e.g. alpha version, beta version, ... 

* Compile time code removal: 
  - KCONFIG may help
  - However as a community we can only security support a very small number of 
combinations

* Is the Security process (https://www.xenproject.org/security-policy.html) is 
incompatible with the certification process?
  - No clear answer, but this sounded like a yes
  - There was a little bit of discussion around this or afterwards along the 
lines that certification only requires
    to take action if an organisation was made aware of an issue (being on a 
security pre-disclosure list us therefore a
    possible disadvantage for a vendor with a certified product)
  - But certification is only one issue: a high-profile vulnerability may case 
all sorts of other issues

* Around the Software - Hardware interface
  - Need to ensure that software can handle the HW bugs
  - SW can only be used on only specific certified HW (e.g. Renesas R-CarH3)
  - Starting to test against such HW is a good first step

* Feature Classification and the work we are/have been doing for becoming a CNA 
may help
  - See http://sched.co/AjHl & http://markmail.org/message/zxtisdcbh6k7mdr5

* Protocols
  - Need to have extensible protocols where changes are isolated (think we are 
already doing this for new stuff)
 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel