[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




"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.

   Stefan

>
> George  
>
> --
> George S. Coker, II <gscoker@xxxxxxxxxxxxxx>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.