This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid

To: Christian.Limpach@xxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Fri, 19 May 2006 19:21:08 +0200
Cc: Chris Wright <chrisw@xxxxxxxxxxxx>, Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <chris@xxxxxxxxxxxxx>
Delivery-date: Fri, 19 May 2006 10:21:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <3d8eece20605190243v626b894bp1f5e6f4ff23e56d1@xxxxxxxxxxxxxx> (Christian Limpach's message of "Fri, 19 May 2006 10:43:18 +0100")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87y7wzmeqb.fsf@xxxxxxxxxxxxxxxxx> <a74fd46bb61fffb16ab812859d83d8e8@xxxxxxxxxxxx> <20060519074112.GF2724@xxxxxxxxxxxxxxxxx> <3d8eece20605190243v626b894bp1f5e6f4ff23e56d1@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
"Christian Limpach" <christian.limpach@xxxxxxxxx> writes:

> On 5/19/06, Chris Wright <chrisw@xxxxxxxxxxxx> wrote:
>> * Keir Fraser (Keir.Fraser@xxxxxxxxxxxx) wrote:
>> > Christian has a fair point that, if you're just reading it out of
>> > xenstore, you could do that directly from user space. I suppose there
>> > is an argument of necessary privileges to do so however, since you need
>> > to be root to open the xenstore device file.
>> Privileges part is a bit annoying.  But if the envisioned user
>> is unprivilged, some init script could always stash uuid in a
>> world readable file.
> This solution, as any solution which exposes the uuid to the guest,
> will break if/when we support VM forking.

Is there any scenario other than VM forking that makes the UUID

Can we agree that machines having a UUID is useful?  Real machines
have one, for a reason.

VM forking has no non-virtual equivalent, hasn't it?  It's just one of
the things that are different in a virtual environment.  If your
virtual machine differs in a noticeable ways from real machines, you
can't expect all software to just work.  Software broken by the
difference needs to be adapted to the environment.  In the case of
forking VMs, you have to teach it to expect and cope with UUID
changes.  I don't see why we should break software that wants a UUID
now, by refusing to disclose the UUID we have, rather than possibly
later, when we fork VMs.

>                                            Nevertheless, at this point
> I'd almost prefer adding a version sub hypercall since that gives you
> at least a chance at getting an up to date value.

What's the technical advantage of a version sub hypercall over

>                                                    Alternatively, you
> could add some code to the xenstore dev driver to only allow read-only
> access for non-root users.

Does the dev driver enforce root?  Isn't that policy in the kernel?

Is it safe to allow unpriveleged read-only access to *all* of xenstore
in domU?


Xen-devel mailing list