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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.


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

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