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
|
Home