From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH v6 05/10] xsm: add XENMEM_soft_reset support
Date: Wed, 20 May 2015 19:30:46 -0400
Message-ID: <555D1926.3020309@tycho.nsa.gov>
References: <1431510585-12544-1-git-send-email-vkuznets@redhat.com>
	<1431510585-12544-6-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1YvDSX-0005j3-P0
	for xen-devel@lists.xenproject.org; Wed, 20 May 2015 23:31:33 +0000
In-Reply-To: <1431510585-12544-6-git-send-email-vkuznets@redhat.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
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>
List-Id: xen-devel@lists.xenproject.org

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