From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig
Date: Mon, 4 Jan 2016 15:01:12 -0500
Message-ID: <568ACF88.1060607@tycho.nsa.gov>
References: <1450759603-24249-1-git-send-email-cardoe@cardoe.com>
	<1450819607-3763-1-git-send-email-cardoe@cardoe.com>
	<1450819607-3763-2-git-send-email-cardoe@cardoe.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>
In-Reply-To: <1450819607-3763-2-git-send-email-cardoe@cardoe.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: Doug Goldstein <cardoe@cardoe.com>, xen-devel@lists.xen.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

On 22/12/15 16:26, Doug Goldstein wrote:
> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
> CONFIG_XSM.
>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

The dependencies for LATE_HWDOM are backwards: it is an optional X86-only
feature (which probably should be off by default) that depends on XSM to
work properly.

How about this for the help text:

Allows the creation of a dedicated hardware domain distinct from
domain 0 that manages devices without needing access to other
privileged functionality such as the ability to manage domains.
This requires that the actual domain 0 be a stub domain that
constructs the actual hardware domain instead of initializing the
hardware itself.  Because the hardware domain needs access to
hypercalls not available to unprivileged guests, an XSM policy
is required to properly define the privilege of these domains.

This feature does nothing if the "hardware_dom" boot parameter is
not present.  If this feature is being used for security, it should
be combined with an IOMMU in strict mode.

If unsure, say N.