Re: [Xen-devel] [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall

[Eric Trudeau <etrudeau@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Monday, March 03, 2014 11:35 AM
> To: Eric Trudeau
> Cc: Julien Grall; Arianna Avanzini; xen-devel@xxxxxxxxxxxxx;
> paolo.valente@xxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
> julien.grall@xxxxxxxxxx; viktor.kleinik@xxxxxxxxxxxxxxx; Ian Campbell; Tim
> Deegan
> Subject: Re: [Xen-devel] [RFC PATCH 2/3] arch, arm32: add the
> XEN_DOMCTL_memory_mapping hypercall
> 
> On lun, 2014-03-03 at 16:25 +0000, Eric Trudeau wrote:
> 
> > > > Right. FTR, xen/arch/x86/domain_build.c, has this (also in
> > > > construct_dom0):
> > > >
> > > >      /* DOM0 is permitted full I/O capabilities. */
> > > >      rc |= ioports_permit_access(dom0, 0, 0xFFFF);
> > > >      rc |= iomem_permit_access(dom0, 0UL, ~0UL);
> > > >      rc |= irqs_permit_access(dom0, 1, nr_irqs_gsi - 1);
> > > >
> > > > Do you want a patch to that/similar effect?
> > >
> > > Yes. Maybe a bit more smarter than permitting full I/0 caps for dom0.
> > >
> >
> > Our implementation does not require Dom0 access permission in order
> > for it to grant access permission to a DomU.  I suppose it wouldn't hurt
> > for iomem_permit_access because we allow iomem regions to be mapped
> > into multiple domains; however, I think the irqs_permit_access call keeps
> > multiple domains from "owning" the same IRQ.  I might be wrong about that.
> >
> As far as I understood it, it is not required here either. And in fact,
> such permission is not there, and things works for Arianna too.
> 
> However, it seemed a sane check to have in place (e.g., the x86
> implementation does check for that), that's why she's trying to
> introduce it properly. :-)
> 
> After all, as far as I remember, you do have something like this:
> 
>     if ( current->domain->domain_id != 0 )
>         break;
> 
> don't you?
> 
Yes, we only allow Domain 0 to perform the memory_mapping hypercall.
As mentioned in one of the related threads to the patch, in embedded 
system implementations like ours, we are partitioning devices to various
DomU's and Dom0 is really the control domain with a few shared devices.
If it gets hacked we want to make it that much harder to get access to
a device because it does not have access to it, although the hacker
potentially would make the hypercall to get access, etc.  We think of it
in the same way that normally on Linux, you run without privileges and
use sudo when you really want to get more control temporarily.

I checked the flow for when we route an IRQ to multiple domains and
it does not check for more than one domain having permission to access
the PIRQ, it checks whether another domain already has the IRQ routed
to it.  So, even with IRQs, it should not be a problem to have Dom0 have
permission to all non-hypervisor IRQs.

> Regards,
> Dario
> 
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel