Mailing List Archive

XSM and privcmd_ioctl_mmap
Hi,
I'm using the v6 XSM patch-set (
http://lists.xen.org/archives/html/xen-devel/2012-11/msg01920.html) to
perform dom0 disaggregation but I came across two ioctl functions in the
Linux privcmd driver that were getting -EPERM errors in my secondary
control domU. The problem is that the permission checks are not coming from
XSM but the Kernel itself, when XSM should be in charge of access control.

The two functions in Linux 3.x kernel are *privcmd_ioctl_mmap *and *
privcmd_ioctl_mmap_batch*:

driver/xen/privcmd.c@199 and @319 in Linux 3.7.0:

* if (!xen_initial_domain())*
* return -EPERM;*
*
*
Are these checks still needed when the XSM patches are applied?

Thanks,
Tamas
Re: XSM and privcmd_ioctl_mmap [ In reply to ]
On 12/26/2012 12:53 AM, Tamas Lengyel wrote:
> Hi,
> I'm using the v6 XSM patch-set (
> http://lists.xen.org/archives/html/xen-devel/2012-11/msg01920.html) to
> perform dom0 disaggregation but I came across two ioctl functions in the
> Linux privcmd driver that were getting -EPERM errors in my secondary
> control domU. The problem is that the permission checks are not coming from
> XSM but the Kernel itself, when XSM should be in charge of access control.
>
> The two functions in Linux 3.x kernel are *privcmd_ioctl_mmap *and *
> privcmd_ioctl_mmap_batch*:
>
> driver/xen/privcmd.c@199 and @319 in Linux 3.7.0:
>
> * if (!xen_initial_domain())*
> * return -EPERM;*
> *
> *
> Are these checks still needed when the XSM patches are applied?
>
> Thanks,
> Tamas

No, those checks were never needed, with or without XSM; they were trying
to enforce hypervisor-level access control in Linux, which was at best a
slight performance improvement. They should be removed; I will submit a
patch to remove them if you don't want to submit it yourself, since they
do break control domains.

--
Daniel De Graaf
National Security Agency

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