[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 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
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
much, except for https://www.freertos.org/FreeRTOS-
which describes SafeRTOS a commercial safety certified FreeRTOS and
(mostly) API compliant version of FreeRTOS. Or am I missing something
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?


Julien Grall

Xen-devel mailing list



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