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

[Praveen Kumar <kpraveen.lkml@xxxxxxxxx>]

Hi,

On Tue, May 8, 2018 at 9:20 PM Stefano Stabellini <sstabellini@xxxxxxxxxx>
wrote:

> On Tue, 8 May 2018, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 08/05/18 01:11, Stefano Stabellini wrote:
> > > On Fri, 6 Apr 2018, Stefano Stabellini wrote:
> > > > > > > > 3) Understand how to address dom0. FreeRTOS Dom0 sounds
like a
> > > > > > > > good
> > > > > > > > solution.
> > > > > > > > Next step: reach out to Dornerworks and/or others that
worked with
> > > > > > > > FreeRTOS on Xen before. Figure out whether FreeRTOS is
actually a
> > > > > > > > suitable solution and what needs to be done to run FreeRTOS
as
> > > > > > > > Dom0.
> > > > > > >
> > > > > > > Some things to check at this stage:
> > > > > > > a) I believe there is a safety certified version of FreeRTOS
- I
> > > > > > > could not
> > > > > > > find
> > > > > > > much, except for https://www.freertos.org/FreeRTOS-
> > > > > > >
Plus/Safety_Critical_Certified/SafeRTOS-Safety-Critical-Certification.shtml
> > > > > > > -
> > > > > > > which describes SafeRTOS a commercial safety certified
FreeRTOS and
> > > > > > > (mostly) API compliant version of FreeRTOS. Or am I missing
> > > > > > > something
> > > > > > > here?
> > > > > > > b) There is a DomU capable version from Galois (Jonathan
Docherty
> > > > > > > CC'ed) -
> > > > > > > I don't know whether others also have such versions
> > > > > >
> > > > > > I ported the version of FreeRTOS that Xilinx distributes with
their
> > > > > > SDK to
> > > > > > run as a domU on the ZUS+ in 2016 and round tripped the change
set
> > > > > > back to
> > > > > > Richard Barry.
> > > > > > I've also heard interest in running RTEMS as a guest OS.
> > > > > >
> > > > >
> > > > > We've had experience in running QNX in domu, but that was not very
> > > > > welcomed by
> > > > > BB QSSL folks back then :) They dont really like OSS
> > >
> > > One more option (apparently taken by others) is to demonstrate that
> > > after boot Dom0 cannot affect the system anymore.
> >
> > Can you describe what you mean by "affecting the system anymore".

> I don't actually know: I have been told that this is a strategy pursued
> by other hypervisors. I guess we'll find out more details as we get more
> familiar with the certification requirements.


> > > To do that, we would
> > > have to get rid of Dom0 entirely after booting all domains, or,
> > > deprivilege/restrict its possible effects on the system. Something
like
> > > turning Dom0 into a DomU after booting all the other guests.
> > > This might actually be easier to achieve than "dom0-less" or using
> > > FreeRTOS as dom0.
> >
> > Other than accessing the hypercall, there are few other way for Dom0 to
affect
> > the platform:
> >       - Dom0 by default has access to all the hardware but the one
assigned
> > to DomUs. Those hardware may give the possibility to affect the
> > platform irreversibly (or even rebooting).
> >       - Not all DMA-capable devices are today protected by an IOMMU
> >
> > You probably can create something similar to the hardware domain as on
x86
> > (i.e all the hardware is owned by a separate domain other than Dom0),
but then
> > it is only shifting the problem.

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


> > 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 ?
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel