Re: [Xen-devel] [PATCH 00/18] RFC: Merge IS_PRIV checks into XSM hooks

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 08/07/2012 01:12 AM, Shakeel Butt wrote:
> I have just two comments:
> 
> 1. Although the apparent benefit of this patch series seems dom0
> disaggregation [VEE'08,SOSP'11] but (completely covered) xsm hooks
> will facilitate the implementation of recently proposed system like
> CloudVisor [SOSP'11] and Self-service Cloud [CCS'12] and can be used
> to further explore access control and flexibility for different
> scenarios.

I wasn't intending to exclude the other uses of XSM that this series will
benefit; dom0 disaggregation is just the most obvious case that requires
the larger changes like removing IS_PRIV checks.
 
> 2. This patch series is the hypervisor part of the dom0 disaggregation
> idea realization. I think the next step should be applying similar
> ideas to xen tools and Linux kernel. For example in Linux kernel
> is_initial_domain() is equivalent to IS_PRIV, what should be the xsm
> equivalent solution here. Other parts which need some discussion or
> thinking are xenbus, xenstored, privcmd (and others).
> 
> Shakeel

Linux should not be doing any access control for the hypervisor based on
xen_initial_domain; this is the hypervisor's job, and duplicating access
checks based on this bit will just make it more likely to be inconsistent.

The actual equivalent for XSM in Linux is SELinux; a method for mapping
between the XSM/FLASK labels in the hypervisor and SELinux labels in a
domain will be needed to make security policy extend from the hypervisor
down to processes. Currently, Xen interfaces are labeled as a whole, so
a process with access to these interfaces has access to everything that
the domain it is running in has access to. This is often sufficient,
especially if stub domains (Linux or minios) are used to limit the access
that any given domain requires.

The xen_initial_domain() access checks are mostly confined to controlling
if PV Linux domains attempt direct access to hardware: things like ACPI
support, IRQ configuration, direct PCI access, etc. It should be possible
to use the rest of the Xen toolstack from a domU, once this series is
applied.

Xenstore can already be split into its own stub domain (or domains, as in
the Xoar paper). The permissions model in Xenstore has a privileged bit
similar to IS_PRIV; extending XSM controls into Xenstore similar to how
SELinux controls were extended into DBus will address this.

-- 
Daniel De Graaf
National Security Agency

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