Re: Xen and safety certification, Minutes of the meeting on Apr 4th

From: Artem Mygaiev <artem_mygaiev@epam.com>
To: Jarvis Roach <Jarvis.Roach@dornerworks.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Praveen Kumar <kpraveen.lkml@gmail.com>
Cc: "Davorin Mista" <davorin.mista@aggios.com>,
	"Lars Kurth" <lars.kurth@citrix.com>,
	"Edgar E. Iglesias" <edgar.iglesias@xilinx.com>,
	"paul_luperto@prqa.com" <paul_luperto@prqa.com>,
	"Volodymyr Babchuk" <volodymyr_babchuk@epam.com>,
	"Rich Persaud" <persaur@gmail.com>,
	"Mirela Simonović" <mirela.simonovic@aggios.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@dornerworks.com>,
	"julien.grall@arm.com" <julien.grall@arm.com>,
	"robin.randhawa@arm.com" <robin.randhawa@arm.com>,
	"committers@xenproject.org" <committers@xenproject.org>,
	"anastassios.nanos@onapp.com" <anastassios.nanos@onapp.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Jonathan Daugherty" <jtd@galois.com>,
	"Denys Balatsko" <denys.balatsko@globallogic.com>,
	"vfachin@de.adit-jv.com" <vfachin@de.adit-jv.com>
Subject: Re: Xen and safety certification, Minutes of the meeting on Apr 4th
Date: Tue, 22 May 2018 16:08:30 +0300	[thread overview]
Message-ID: <6af21f78-38fb-0f37-01dc-6a152c7f0cc0@epam.com> (raw)
In-Reply-To: <c137e3b91d234a2ca15c8e9c6ac2955f@dornerworks.com>

Hello Jarvis

On 22.05.18 15:08, Jarvis Roach wrote:
>> 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?
> 

We actually have one of the options to run FreeRTOS in dom0 (see earlier 
emails in this thread)

>>> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel