[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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?

> > 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.