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 <vkuzn...@redhat.com>
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@lists.xen.org
http://lists.xen.org/xen-devel
