[Xen-devel] Re: xsm: Consolidate xsm processing within domain control hypercall.

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On 12/4/07 4:46 PM, "Mike D. Day" <ncmike@xxxxxxxxxx> wrote:

> On 04/12/07 16:20 -0500, George S. Coker, II wrote:
>> A couple of things:
>> 
>> - For these modifications to work, updates also have to be made to the dummy
>> module for XSM_ENABLE=y to compile
>> 
>> - I do not think these modifications are a win.  I would like to see this
>> changeset reverted for the following reasons:
>> 
>> 1) While it may reduce the number of lines of code in the domctl hypercall,
>> it won't really reduce the overall number of lines of code in the hypervisor
>> if a module chooses to implement security operations on all of the donctl
>> operations. 
> 
> True, but it does concentrate the code in the security module. Also,
> it only requires one entry point to the security module from within
> the domctrl hypercall. I think that makes the code more maintainable
> and less likely that new domctl operations will bypass xsm security.
> 
I would argue that it gives the false sense of coverage because the actual
coverage is obfuscated from developers and users.  The danger is that one
could be too dismissive here because we're assuming coverage that may or may
not be implemented.

> 
>> 2) This will also impose on the security modules the responsibility to
>> acquire and hold locks on hypervisor resources.  It would seem dangerous to
>> give modules this responsibility.
> 
> I don't see it, the locking logic is still the same. Can you show me
> where the module needs to acquire locks differently than without the
> patch?
> 
>> 3) Performance will be impacted because of the additional multiplexing in 1)
>> and additional resource management in 2).
> 
> I thought about this. I concluded it probably isn't measurable and
> even if so, it really doesn't matter because domctl hypercalls are
> infrequent and never performance-critical.
> 
> Mike

-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel