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

[Julien Grall <julien.grall@xxxxxxx>]

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

> 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.
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?
Cheers,

--
Julien Grall

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