[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.
> 
True, but it makes the security interface incredibly broad.

> 
>> 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?
> 
It's not that the locking logic is different.  A security module may be
sloppy about its locking and cause Xen to crash without specifically
indicating a flaw in the security module.

Getting locks right is tricky business, it would seem the Xen would want the
responsibility for the locking of resources to avoid the ills of race
conditions, etc.

>> 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.
> 
True, this isn't the substantive argument.  I'm concerned about points 1) &
2).

> Mike

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



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