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

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

On 12/17/07 6:58 PM, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> 
> "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote on 12/17/2007 05:00:39
> PM:
> 
>> 
>> 
>> 
>> 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? 
> 
> Reading the extended vCPU context is part of suspend and migration operations,
> among a set of other hypercalls. Now these operations will fail if for example
> only reading the extended vCPU context is denied by a different hook than
> reading the 'normal' vCPU context. Also the operations will fail depending on
> the processor type. I am afraid that none of this  makes it easier to write a
> policy. 
> 
In looking into the issue further, it appears that the suspend code will
silently take the security fault on get_ext_vcpucontext and manifest the
fault as not implemented vice not permitted.  This issue and others like it
can be handled by a simple modification to libxc for more explicit error
checking.  Thanks for pointing this issue out.  I'll update my patches in
the new year.

While both get_ext_vcpucontext and get_vcpucontext are required for the
correct operation of the suspend code, they are distinct code paths.  XSM
strives to be consistent with Xen by recognizing this distinction and not
burying architectural assumptions in some parts of the framework while
explicitly stating others.  Although, I think the vcpucontext operations may
be an exception since it is the only (off the top of my head) example of
complementary functionality that spans arch and common trees.  However, I
would rather XSM not make this exception and remain consistent with Xen.  In
this case and others like it, XSM provides a given security module the
flexibility to drop the arch and common distinction and marshal both code
paths through a common security operation, but I don't think the framework
should make these kind of implementation choices especially since the
framework has no impact on policy complexity.

George



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