Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Artem Mygaiev <artem_mygaiev@xxxxxxxx>]

Hello Jarvis

On 22.05.18 15:08, Jarvis Roach wrote:
> > Hi Stefano
> >
> > On 10.05.18 22:51, Stefano Stabellini wrote:
> > > On Thu, 10 May 2018, Praveen Kumar wrote:
> > > > > Yeah, you are right. It looks like turning Dom0 into a DomU is not
> > > > > good enough. Maybe for this option to be viable we would actually
> > > > > have to terminate (or pause and never unpause?) dom0 after boot.
> > > > Just a thought !
> > > > How about keeping Dom0 still be there, but DomUs given Dom0
> > > > privilege, with restricted permission on mission critical resources ?
> > > > And if anyhow Dom0 crashes, the best contended among the existing
> > > > DomUs take the ownership of Dom0 ?
> > > I don't think this is easily doable, also it wouldn't solve the issue
> > > of removing dom0 from the system. But see below.
> > >
> > >
> > > > > > However, you surely need an entity to handle domain crash. You
> > > > > > don't
> > > > want to
> > > > > > reboot your platform (and therefore you safety critical domain) for
> > > > > > a
> > > > crashed
> > > > > > UI, right? So how this is going to be handled in your option?
> > > > > We need to understand the certification requirements better to know
> > > > > the answer to this. I am guessing that UI crashes are not handled
> > > > > from the certification point of view -- maybe we only need to
> > > > > demonstrate that the system is not affected by them?
> > > > Where can we find the certification requirements details ?
> > ISO26262: https://www.iso.org/standard/51362.html
> > IEC61508: https://webstore.iec.ch/publication/5517
> >
> > > Yes, I think we need to understand the requirements better to figure
> > > out the right way forward for Dom0.
> > >
> > > For instance, here is another idea: we could have Xen boot multiple
> > > domains at boot time from device tree, as suggested in the dom0-less
> > > approach. All of the domains booted from Xen are "mission-critical".
> > > The first domain could still be dom0. Once booted, Dom0 can start
> > > other VMs, however, Xen would restrict Dom0 from doing any operations
> > > affecting the first set of mission-critical domains.
> Does the first domain have to be dom0? Would it be possible to have domains 
> boot in parallel (especially if allocated to separate CPU cores) such that a 
> simple OS (like FreeRTOS) would complete booting before dom0/Linux? In other 
> words, does the hypervisor have any dependencies on dom0 having performed 
> certain functions (interrupt configuration, MMU table initialization, timers, 
> etc.) before it can create and start additional VMs?
We actually have one of the options to run FreeRTOS in dom0 (see earlier 
emails in this thread)
> > > This way, we would get the flexibility of being able to start/stop
> > > domains at run time, but at the same time we might still be able to
> > > avoid certifications for Dom0, because Dom0 cannot affect the mission
> > > critical applications.
> > Such dom0 shall have no mission-critical domains memory access, no HW
> > access (SMMU, DVFS Power, etc.), and so on. EL3 software (optee or similar
> > on ARM) shall also be safety certified and not controlled from dom0
> > > Is this approach actually feasible? We need to read the requirements
> > > to know. I am hoping Artem will chime in on this :-)
> >   >
> >
> > I think this approach is feasible indeed, if we can prove isolation and fault
> > tolerance for FuSa parts of the system.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel