From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xenproject.org
Cc: 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>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH v6 05/10] xsm: add XENMEM_soft_reset support
Date: Wed, 20 May 2015 19:30:46 -0400 [thread overview]
Message-ID: <555D1926.3020309@tycho.nsa.gov> (raw)
In-Reply-To: <1431510585-12544-6-git-send-email-vkuznets@redhat.com>
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.
[...]
> --- 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
next prev parent reply other threads:[~2015-05-20 23:31 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 [this message]
2015-05-21 9:49 ` Vitaly Kuznetsov
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=555D1926.3020309@tycho.nsa.gov \
--to=dgdegra@tycho.nsa.gov \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--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=vkuznets@redhat.com \
--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.