Re: [Xen-devel] XSM support for recently added priv hypercall ops

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

On 12/13/07 7:20 PM, "George S. Coker, II" <george.coker@xxxxxxxxx> wrote:

>> 
>> when these hooks are enforced, do today's libraries and applications react
>> approriately?
>> 
> I believe yes, these hooks are in code paths where today IS_PRIV is
> also checked
> and may cause a return value of -EPERM or -ESRCH.  In my checking, few
> of the libraries and
> applications that I know about are sensitive to the exact value of the
> return, but I understand that this isn't
> always true.
> 
>> Would it not make sense to use the same hook for getting the cpu context and
>> the extended cpu context?
>> 
> I would like to distinguish the difference between the implementation
> of a security module and the implementation of the framework.  The
> framework defines distinct hooks for flexibility.  A security module
> may instrument the same security function for all hooks because the
> goals of the module are simple, e.g. is the caller privileged or not.
> However, a security module may instrument distinct security functions
> to meet finer grain goals.  One example could be to eliminate or limit
> the use of particular code paths.  I would prefer that XSM not place
> constraints on the goals of a security module.
> 
> For the get/set_vcpucontext and get/set_ext_vcpucontext hooks, the
> get/set_vcpucontext hooks are in the common domctl code path and are
> architecture neutral.  The get/set_ext_vcpucontext hooks are only
> found, today, in the x86 code path.  Forcing the same hook assumes
> something which isn't true, that all architectures are the same and
> the impact of these operations are the same on all
> architectures/platforms.
> 

Stefan,

In looking at the vcpucontext case again, it would be entirely reasonable to
create a generic hook with an additional argument for the hypercall op.  A
module would then have the burden of checking the op for the architecture
dependent ops.  However, I dislike this approach because it obscures an arch
dependency of the hook, something which has not been done for the other ops.
I find the inconsistency problematic.

Do you have a specific observation here, perhaps based on other
architectures?

George  

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



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