On Fri, 2007-05-11 at 14:32 +0100, Derek Murray wrote:
> On 9 May 2007, at 18:04, George S. Coker, II wrote:
> > Some review of the current hooks is needed to ensure that existing
> > uses
> > of IS_PRIV() are completely covered. I believe this is the case for
> > almost all of the XSM hooks. In most code paths where there is an
> > IS_PRIV() call there is an XSM hook immediately following. mmu_update
> > is perhaps an exception. I believe the hook is in the right place to
> > control the use of mmu_update and probably does not require an extra
> > hook in set_foreigndom() but there is a side effect from
> > set_foreigndom() (FOREIGNDOM is set to some value in the absense of
> > IS_PRIV()) that must be dealt with in the mmu_update hook.
>
> I've checked through changeset 15011 with your latest XSM patchset,
> and looked at each instance of IS_PRIV(). I've attached the report
> with this message.
>
>
> The uses of IS_PRIV() boil down to a few categories:
>
> 1. Allow privileged domain only.
> 2. Allow self and privileged domain only.
> 3. set_foreigndom()
> 4. Allow self only, but with a different return code (EINVAL instead
> of EPERM) for privileged domain.
> 5. Make no access control decision; instead use IS_PRIV() to modify a
> register value.
>
> The presence of XSM hooks can also be categorised:
>
> 1. IS_PRIV() directly followed by XSM hook.
> 2. IS_PRIV() at start of do_*_op function, followed by XSM hooks for
> the individual cases.
> 3. IS_PRIV() at start of list-processing function, followed by XSM
> hook for each item in the list.
> 4. IS_PRIV() followed by no XSM hook (mostly in IA64 code).
We're not there yet for IA64, but we will be....any testers out there?
So I think XSM is "there" for all of the IS_PRIV uses, with the
exception of set_foreigndom() and modification of a register value in
traps.c. (I honestly haven't spent any time thinking about the XSM
equivalent to the use of IS_PRIV in traps.c)
> The untidiest cases are where set_foreigndom() is involved. These
> involve do_mmu_update(), do_update_va_otherdomain() and some
> mmuext_ops. In particular, on the do_update_va_otherdomain() path,
> IS_PRIV is checked twice. It would seem to me that the cleanest way
> to do this is to have the permission check first (can domain X access
> MFN Y of domain Z?), then carry out the set_foreigndom() logic.
>
I think I agree.
> I am unsure about the location of the xsm_mmu_normal_update() hook.
> What sort of policy do you envisage being enforced here? In
> particular, the hook is based on the current domain and the value
> that is to be written into the page table. In mod_l1_entry(),
> get_page_from_l1e() is called, which ensures that the page belongs to
> FOREIGNDOM, so would it be possible just to place the hook before
> set_foreigndom()? This would have the added benefit of fewer calls to
> the hook, when multiple updates have been batched together.
>
> I am assuming that there are no latent examples of privilege-as-being-
> dom0 in the code, but I haven't confirmed this.
I believe you are correct, although this was not always the case, I think.
> On 9 May 2007, at 18:13, George S. Coker, II wrote:
> > I believe we have similar goals here. It should be possible
> > through the
> > XSM framework and the Flask-XSM module to define a policy that
> > enables a
> > fine grain usage model such as disaggregation of the domain builder as
> > well as others. The benefit to Flask-XSM is the flexibility
> > provided is
> > completely general as it is derived through definition of a policy
> > not a
> > specific module.
>
> It sounds to me that Flask-XSM provides the flexibility that would be
> needed for defining a disaggregation policy. I wonder, though,
> whether the Chinese Wall and Simple Type Enforcement ACM modules
> (which, if I understand correctly, are separate Xen Security Modules
> in this framework) would best be written with the IS_PRIV()-
> replacement code separated out into a "shim" policy as Keir suggested
> in this thread. Perhaps these modules should delegate to the dummy
> policy, and, if they pass these hooks, then try the dynamic policy?
> This would ensure that the Xen static privilege code is in a single
> location and would hence be kept consistent.
>
Currently the existing ACM module is implemented as a single XSM module
which stacks (internally) the Chinese Wall and Simple Type Enforcement
functionality. (This is the preferred approach for stacking.) ACM-XSM
is one module with the flexibility to enforce STE and/or CW policy.
The existing ACM was designed to be complementary to Xen's IS_PRIV().
Moving IS_PRIV() to the default/dummy XSM module does not alter this
relationship as the hooks used by ACM are orthogonal to the IS_PRIV()
hooks. On init of the XSM (because ACM-XSM does not define replacements
for these IS_PRIV() hooks), the hooks from the dummy/default module are
integrated (or "shimmed") in to the ACM-XSM module. So I think XSM can
do what you and Keir are suggesting.
> Thanks for your input on this, and if I can be of any more help,
> please let me know.
>
> Regards,
>
> Derek Murray.
--
George S. Coker, II <gscoker@xxxxxxxxxxxxxx> 443-479-6944
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home