[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5] Merge IS_PRIV checks into XSM hooks
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |