WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

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

To: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Subject: [Xense-devel] Re: XSM hook for mapping a grant ref
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Tue, 15 May 2007 20:26:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 15 May 2007 13:25:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2BB42DF-5AF7-4E52-A548-623EA57215FE@xxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2BB42DF-5AF7-4E52-A548-623EA57215FE@xxxxxxxxxxxx>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>