Re: [Xen-devel] [PATCH v5] Merge IS_PRIV checks into XSM hooks

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 11/19/2012 04:45 AM, Jan Beulich wrote:
> As to getting the series applied, I suppose that'll be a little difficult,
> as it mixes changes to various parts of the tree, and hence no
> single maintainer would generally be able to apply the whole series
> without respective other parts fully acked by the corresponding
> maintainers. Is there a way to either indicate eventual fully
> standalone patches, or order/split it so that at least tools side and
> hypervisor side changes are separated from one another, or mixed
> patches all go at the beginning or end of the series?

The only patch related to tools is patch #1; the other patches only touch
the hypervisor or the example FLASK policy (which is under tools/). The
hypervisor patch that #1 relies on is already in 4.3, none of the rest of
the series depends on it (except where someone might want to use the
functionality it adds).

On 11/19/2012 05:26 AM, Tim Deegan wrote: 
> This whole series makes me very uncomfortable.  I can see its usefulness,
> and as a supporter of disaggregations I like the idea of fine-grained
> control, but it really does obscure the security checks, and makes it
> less likely that people implementing new operations will get their
> security checks right.

I agree about the increased possibility to get things wrong, but I think
that's going regardless of how you move away from a simple binary permission
check. I have tried to address this by adding generic checks where possible
(domctl, sysctl) so that new code added there has sane default protection.
Another thing I can think of is to make the existing code as easy to
understand as possible so people copying "how it's currently done" get it
right; suggestions here would be appreciated as I tend to understand my
own code too well to see how it's confusing - the construction of new hooks
in dummy.h is one part that I hope to improve on.

> Since there are only a small number of default checks (IS_PRIV,
> IS_PRIV_FOR, self-only, ???), I wonder whether they could be explicitly
> included in the xsm invocation (as some sort of 'enum
> xsm-default-policy' argument), to make it clear what's going on without
> the reader having to grobble around in xsm files?

Ian made a similar suggestion in reply to #6, suggesting adding the type
(guest, stubdom, toolstack, dom0/hardware) to the XSM hook's name so that
one can get a quick idea of what the hook is for at a glance. This seems
like a useful addition, although the handling of more complex hooks like
xsm_mmu_update may still require the reader to look in the XSM code to
figure out what is being checked.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel