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

Re: [Xen-devel] xsm_op() polymorphism


  • To: "John Levon" <levon@xxxxxxxxxxxxxxxxx>
  • From: "George S. Coker, II" <george.coker@xxxxxxxxx>
  • Date: Mon, 10 Dec 2007 19:05:03 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 10 Dec 2007 16:05:48 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tFN0lpmELXsHMA9UISKD8VzRz9MGTMteSWR0Zgu27VuqGOMXMDnYfPu4Zr9mfWcXbs5V23/xR/4SxAA1cYLl/ylJx4MciDxZcNqWUQa1RzvjCVwoeZyQ1g6F0VfC8JPiMj6+EEJCVWAEeKc4yzkMp5YayVaBszx7U3EwQ8ipFaU=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Dec 10, 2007 2:41 PM, John Levon <levon@xxxxxxxxxxxxxxxxx> wrote:
>
> If I'm reading the code right, then the xsm_op() hypercall is "untyped"
> in the sense that you have to know why XSM is loaded before you can
> interpret any of the contents (that is, the first argument points
> directly to a flask op or acm op structure). This seems less than ideal
> - can't we work out a way to make the struct self-identifying?
>

It depends on what you are concerned about.  There are the magic
numbers that are used right now to identify policy modules on boot but
could become embedded as the first word of the xsm op structure.  This
would help the hypervisor be consistent with user-space - if that's
what you are concerned about.  It was not the intent to make the
hypervisor runtime agile wrt a given security module except to not
prevent a security module from runtime disablement - for obvious
reasons more flexibility here is fraught with consistency problems.

_______________________________________________
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®.