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

Re: [Xen-devel] [PATCH v6 05/10] xsm: add XENMEM_soft_reset support



On 05/13/2015 05:49 AM, Vitaly Kuznetsov wrote:
Dummy policy just checks that the current domain is privileged,
in flask policy soft_reset is added to create_domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>

I think the FLASK policy should also check that memory can be moved
from d1 to d2, independent of the check that the toolstack can move
the memory of d1 (or d2).  While I would expect that the security
contexts of d1 and d2 would be identical in most cases (and only
allow that in the example policy), there may be reasons to change
the context along with the kexec operation.  The best examples I
can think of are kexec from a bootloader domain of some kind, or
an installation that transitions into an active system that needs
access to a different network or set of peer domains.

For the example, policy, I'd add something like
        allow $2 $2 : mmu reset_transfer;
to the create_domain interface.

[...]
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -366,6 +366,10 @@ class mmu
  #  source = domain making the hypercall
  #  target = domain whose pages are being exchanged
      exchange
+# XENMEM_soft_reset:
+#  source = source soft reset domain
+#  target = destination soft reset domain
+    soft_reset

These comments are a bit ambiguous.  I would suggest something like:
#  source = domain making the hypercall
#  target = domain being reset (source or destination)

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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