From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH 5/6] tools/libxl: Allow dom0 to be destroyed
Date: Wed, 12 Mar 2014 10:27:43 -0400
Message-ID: <53206EDF.2060901@tycho.nsa.gov>
References: <1393973494-29411-1-git-send-email-dgdegra@tycho.nsa.gov>	<1393973494-29411-6-git-send-email-dgdegra@tycho.nsa.gov>	<21271.4682.893594.815515@mariner.uk.xensource.com>	<5317A6EA.9030905@tycho.nsa.gov>
	<21277.60478.702267.24058@mariner.uk.xensource.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: <21277.60478.702267.24058@mariner.uk.xensource.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: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 03/10/2014 12:45 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [PATCH 5/6] tools/libxl: Allow dom0 to be destroyed"):
>> In reply to both this and Jan's earlier email:
>>> So this gets deleted without replacement? How is the hardware
>>> domain being protected from (accidental or malicious) deletion
>>> then? Even if this is being dealt with in the hypervisor, I'd be
>>> afraid of the failure resulting in a cryptic error message instead
>>> of the very clear one above.
>>
>> The existing check seems to be a useful guard against accidentally
>> breaking parts of a running system.  Would requiring a -f flag on the
>> destroy operation to work on domain 0 be preferable?
>
> That would be tolerable if we can't find a better way to tell whether
> it's safe or not.
>
> I guess you don't want dom0 to be able to destroy itself - or do you ?
> Perhaps the right answer is to require -f for a domain to destroy
> itself.
>
> ian.

A domain can't destroy itself anyway (the hypervisor prevents this), so
if there was a simple way for xl to check if the domain ID was its own
ID, this would work.  I am not aware of a good, simple way to make this
check, so leaving it at preventing dom0's destruction will at least not
regress in usability.

-- 
Daniel De Graaf
National Security Agency