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. 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. Regards, Derek Murray. _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
George S. Coker, II
2007-May-15 20:26 UTC
[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@lists.xensource.com http://lists.xensource.com/xense-devel