WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "George S. Coker, II" <george.coker@xxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] XSM support for recently added priv hypercall ops
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Mon, 17 Dec 2007 17:00:39 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 17 Dec 2007 14:00:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <ff0b9d4e0712131620p1e12ced7s467fac9ea79c2e72@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchA+EJkgRr1PqzrEdyMVwAWy5GONg==
Thread-topic: [Xen-devel] XSM support for recently added priv hypercall ops
User-agent: Microsoft-Entourage/11.3.6.070618


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