> On May 10, 2018, at 15:51, Stefano Stabellini <sstabell...@kernel.org> 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 ?
>
> 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.
>
> 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.
>
> Is this approach actually feasible? We need to read the requirements to
> know. I am hoping Artem will chime in on this :-)
Is any of the x86 hardware domain (non dom0) work applicable to Arm?
https://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00314.html
Daniel is giving a talk on TCB reduction with a Xen hardware domain:
http://platformsecuritysummit.com/#degraaf
Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
