[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xense-devel] Re: XSM hook for mapping a grant ref



On Tue, 2007-05-15 at 12:11 +0100, Derek Murray wrote:
> George et al,
> 
> In another thread today, my attention has been drawn to the  
> grant_operation_permitted() hook that is called when a domain  
> attempts to map a grant reference. This effectively checks whether or  
> not the mapping domain has any I/O memory capabilities, and allows  
> the mapping if it does. The comment for this macro states that:
> 
> "Until TLB flushing issues are sorted out we consider it unsafe for  
> domains with no hardware-access privileges to perform grant map/ 
> transfer operations."
> 
> It seems reasonable that we could have trusted domains which one can  
> assume will handle these situations gracefully. Hence, I think there  
> is a case for an XSM hook that determines whether or not a domain is  
> allowed to map any grants. Arguably, this could be combined with the  
> check in xsm_map_grantref, though I would be unsurprised if there is  
> a reason for the grant_operation_permitted hook residing where it is  
> currently.
> 
As you point out the existing XSM hooks can subsume the
grant_operation_permitted() check.  I don't see any obvious reason for
the placement of grant_operation_permitted() except that it depends only
on the caller of do_grant_table_op and may be most efficient to perform
the check in place.

No doubt there is more work to be done identifying those places where
Xen is enforcing a subtle security policy.  grant_operation_permitted()
is a prime example.

> This also raises the question of whether XSM should be integrated  
> with the existing I/O capabilities system, so that there is one  
> consistent view for a domain's privileges.
> 

I think we have the right XSM hooks covering the critical allocation
paths for the I/O capabilities system.  I am presently thinking of the
checks covered by xsm_irq_permission, xsm_iomem_permission, and
xsm_ioport_permission hooks.  These hooks enable a security module to
check whether the caller can allocate I/O resources to a domain and if
I/O resources can be allocated to a domain.  This should enable a
security module to enforce policy over the setup of the I/O capabilities
system.  

I think it is reasonable to consider representing the I/O capabilities
system under XSM.  However, I think XSM's present coverage of the I/O
capabilities system is spotty.  For example, there are no XSM hooks in
the code paths where ioport_access_permitted is checked, but XSM does
have hooks that subsume iomem_access_permitted and, until recently (see
earlier list discussion on XSM) irq_access_permitted.  A concern has
been duplication between the I/O capabilities and XSM.  This is clearly
not the intention of your proposal.

I would think the rangeset structures and functionality should persist,
but we might want to consider XSM hooks that cover the
irq/ioport/ioemem_access_permitted checks().  This way the operation of
Xen remains sound - we shouldn't strip away functionality that ensures
sane behavior for Xen.  However, independent of Xen, one could then
define and analyze a single policy that completely describes a domain's
privileges on a platform.

For the irq/ioport/iomem_access_permitted() checks, do you think there
is something specific to their positioning?

George


_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.