All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 05/10] xsm: add XENMEM_soft_reset support
Date: Thu, 21 May 2015 11:49:46 +0200	[thread overview]
Message-ID: <87y4ki2rb9.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <555D1926.3020309@tycho.nsa.gov> (Daniel De Graaf's message of "Wed, 20 May 2015 19:30:46 -0400")

Daniel De Graaf <dgdegra@tycho.nsa.gov> writes:

> 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@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.

Hi Daniel, thank you for your review!

Did I get you right and you suggest we use two new vectors in MMU class
for soft reset: the first one to check that the domain making the
hypercall is allowed to do it and the second one to check that that
memory can be moved from d1 to d2? In that case the FLASK-related part
of the patch would look like that I suppose:

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 620d151..ab4fe7d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -54,10 +54,12 @@ define(`create_domain_common', `
 			psr_cmt_op };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
+			mmuext_op updatemp soft_reset };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
 			setparam pcilevel trackdirtyvram nested };
+	allow $2 $2:mmu reset_transfer;
 ')
 
 # create_domain(priv, target)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 11b7453..547d55c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -383,6 +383,21 @@ static int flask_memory_exchange(struct domain *d)
     return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
 }
 
+static int flask_memory_soft_reset(struct domain *d1, struct domain *d2)
+{
+    int rc;
+
+    rc = current_has_perm(d1, SECCLASS_MMU, MMU__SOFT_RESET);
+    if (rc)
+        return rc;
+
+    rc = current_has_perm(d2, SECCLASS_MMU, MMU__SOFT_RESET);
+    if (rc)
+        return rc;
+
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__RESET_TRANSFER);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1617,6 +1632,7 @@ static struct xsm_operations flask_ops = {
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
     .memory_exchange = flask_memory_exchange,
+    .memory_soft_reset = flask_memory_soft_reset,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index ea556df..6872c1a 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -366,6 +366,13 @@ class mmu
 #  source = domain making the hypercall
 #  target = domain whose pages are being exchanged
     exchange
+# XENMEM_soft_reset:
+#  source = domain making the hypercall
+#  target = domain being reset (source or destination)
+    soft_reset
+#  source = source domain being reset
+#  target = destination domain being reset
+    reset_transfer
 # Allow a privileged domain to install a map of a page it does not own.  Used
 # for stub domain device models with the PV framebuffer.
     target_hack

[...]

-- 
  Vitaly

  reply	other threads:[~2015-05-21  9:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  9:49 [PATCH v6 00/10] toolstack-based approach to pvhvm guest kexec Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 01/10] xen: introduce SHUTDOWN_soft_reset shutdown reason Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 02/10] libxl: support " Vitaly Kuznetsov
2015-05-20  9:44   ` Wei Liu
2015-05-13  9:49 ` [PATCH v6 03/10] xen: introduce DOMDYING_locked state Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 04/10] xen: Introduce XENMEM_soft_reset operation Vitaly Kuznetsov
2015-05-22  9:38   ` Jan Beulich
2015-05-22 15:36     ` Vitaly Kuznetsov
2015-05-22 16:26       ` Jan Beulich
2015-05-25  9:24         ` Tim Deegan
2015-05-25 10:06           ` Vitaly Kuznetsov
2015-05-25 16:13             ` Tim Deegan
2015-05-26  8:05               ` Vitaly Kuznetsov
2015-05-26  8:50                 ` Jan Beulich
2015-05-13  9:49 ` [PATCH v6 05/10] xsm: add XENMEM_soft_reset support Vitaly Kuznetsov
2015-05-20 23:30   ` Daniel De Graaf
2015-05-21  9:49     ` Vitaly Kuznetsov [this message]
2015-05-21 14:25       ` Daniel De Graaf
2015-05-22  9:40   ` Jan Beulich
2015-05-22 14:58     ` Daniel De Graaf
2015-05-22 15:26       ` Jan Beulich
2015-05-22 14:59     ` Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 06/10] libxc: support XENMEM_soft_reset operation Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 07/10] libxc: introduce soft reset for HVM domains Vitaly Kuznetsov
2015-05-20 15:10   ` Julien Grall
2015-05-20 15:20     ` Vitaly Kuznetsov
2015-05-20 15:28       ` Julien Grall
2015-05-13  9:49 ` [PATCH v6 08/10] xl: introduce enum domain_restart_type Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 09/10] libxc: add XC_DEVICE_MODEL_SAVE_FILE Vitaly Kuznetsov
2015-05-13  9:49 ` [PATCH v6 10/10] (lib)xl: soft reset support Vitaly Kuznetsov
2015-05-22 14:55   ` Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y4ki2rb9.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=drjones@redhat.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@linaro.org \
    --cc=keir@xen.org \
    --cc=olaf@aepfle.de \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.