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

[Stefan Berger <stefanb@xxxxxxxxxx>]

"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