Xen devel - Sep 2008 - [PATCH] [Xend] Move some backend configuration

This patch moves some dom0 variables and backend device
configuration from frontend directories to 
/local/domain/<backdomid>/backend or /vm.

Also,
- the first console is created as a xend device and moves
  from console/0 to device/console/0
- /vm_path/<domid> is introduced, referencing the /vm path
- /vm_path/device/backend holds the backend device location,
  rather than storing it in the frontend directory
- a few helpers are added to xs.c to deal with this

Signed-off-by: Pascal Bouchareine <pascal@gandi.net>

-- 
\o/   Pascal Bouchareine - Gandi 
 g    0170393757           15, place de la Nation - 75011 Paris      


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 04:24:43PM +0200, Pascal Bouchareine wrote:
> This patch moves some dom0 variables and backend device
> configuration from frontend directories to 
> /local/domain/<backdomid>/backend or /vm.
What is the point of this? These paths, however wrong they might be, are
API, surely.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/9/08 15:43, "John Levon" <levon@movementarian.org> wrote:
> On Tue, Sep 30, 2008 at 04:24:43PM +0200, Pascal Bouchareine wrote:
> 
>> This patch moves some dom0 variables and backend device
>> configuration from frontend directories to
>> /local/domain/<backdomid>/backend or /vm.
> 
> What is the point of this? These paths, however wrong they might be, are
> API, surely.
Which guaranteed API would that be? These paths are private to the toolstack
implementation. Perhaps the only exception is the
xenconsoled-to-console-client xenstore path, but that is the one that most
urgently needs to change, since we can''t trust domUs not to mess with
the
tty path, for example.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 03:48:29PM +0100, Keir Fraser wrote:
> On 30/9/08 15:43, "John Levon" <levon@movementarian.org>
wrote:
> 
> > On Tue, Sep 30, 2008 at 04:24:43PM +0200, Pascal Bouchareine wrote:
> > 
> >> This patch moves some dom0 variables and backend device
> >> configuration from frontend directories to
> >> /local/domain/<backdomid>/backend or /vm.
> > 
> > What is the point of this? These paths, however wrong they might be,
are
> > API, surely.
> 
> Which guaranteed API would that be? These paths are private to the
toolstack
> implementation. Perhaps the only exception is the
Precisely the problem, there''s absolutely no idea or indication what is
and isn''t private. Thus you get libvirt looking in places it maybe
shouldn''t, but how are they supposed to know?

I''m pretty sure this patch breaks libvirt again.
> xenconsoled-to-console-client xenstore path, but that is the one that most
> urgently needs to change, since we can''t trust domUs not to mess
with the
> tty path, for example.
If it''s a security fix (and I see the issue), it needs to be much more
public than this patch was, and of course backported to at least 3.2
ASAP.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/9/08 15:48, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
> On 30/9/08 15:43, "John Levon" <levon@movementarian.org>
wrote:
> 
>> On Tue, Sep 30, 2008 at 04:24:43PM +0200, Pascal Bouchareine wrote:
>> 
>>> This patch moves some dom0 variables and backend device
>>> configuration from frontend directories to
>>> /local/domain/<backdomid>/backend or /vm.
>> 
>> What is the point of this? These paths, however wrong they might be,
are
>> API, surely.
> 
> Which guaranteed API would that be? These paths are private to the
toolstack
> implementation. Perhaps the only exception is the
> xenconsoled-to-console-client xenstore path, but that is the one that most
> urgently needs to change, since we can''t trust domUs not to mess
with the
> tty path, for example.
Actually I''m wrong: avoiding finding backend paths by looking in
frontend-writable xenstore nodes is even more important. But that bit of the
patch should be uncontentious: it''s just xend adding extra private
state in
xenstore for its own private use.

The ''helper'' functions added to libxenstore perhaps make this
look more like
an interface change than it actually is. Noone is forced to use those extra
utility functions, and they''re only going to make sense when the
/vm_path/
stuff has been set up by xend. Arguably those functions should be
implemented in the xend python wrapper for xenstore, and perhaps duplicated
as necessary in the console client (or arguably the client could safely
assume the console daemon is in dom0 and hardcode the backend path prefix!).

The console client-to-daemon interface change is unfortunate, but I
can''t
think of an easy alternative fix.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 04:02:32PM +0100, Keir Fraser wrote:
> frontend-writable xenstore nodes is even more important. But that bit of
the
> patch should be uncontentious: it''s just xend adding extra private
state in
Yep, no problem with that.
> The console client-to-daemon interface change is unfortunate, but I
can''t
> think of an easy alternative fix.
No me neither, I think you''re indeed forced to break the API and
libvirt
will just have to change.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/9/08 15:58, "John Levon" <levon@movementarian.org> wrote:
>> Which guaranteed API would that be? These paths are private to the
toolstack
>> implementation. Perhaps the only exception is the
> 
> Precisely the problem, there''s absolutely no idea or indication
what is
> and isn''t private. Thus you get libvirt looking in places it maybe
> shouldn''t, but how are they supposed to know?
> 
> I''m pretty sure this patch breaks libvirt again.
I don''t really see why it would. Beyond the console-client-to-daemon
interface change (which we can make not depend on the /vm_path stuff) the
rest is changing things which I believe are internal to xend.

If libvirt is really going in at this private state, perhaps we could patch
xend so that it writes to the new locations *in addition to* the old
locations. It then has its own guaranteed-private and -consistent state,
while libvirt can still read from old locations.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 03:58:18PM +0100, John Levon
wrote:
> Precisely the problem, there''s absolutely no idea or indication
what is
> and isn''t private. Thus you get libvirt looking in places it maybe
> shouldn''t, but how are they supposed to know?
> 
> I''m pretty sure this patch breaks libvirt again.
Regarding compatibility:

This might not break too much stuff as we kept the original backend
path(s) at their location. Most obvious fix for other clients is
changing the reading of the backend location from the frontend directory,
but the old behaviour still works.

However, some parts (the console tty, location) have changed and
require attention.
> If it''s a security fix (and I see the issue), it needs to be much
more
> public than this patch was, and of course backported to at least 3.2
> ASAP.
It might well be a security fix, even if this sounds like a moderate
issue yet.

I agree this requires a quick update, but we need to discuss it here
before publicizing ?

-- 
\o/   Pascal Bouchareine - Gandi 
 g    0170393757           15, place de la Nation - 75011 Paris      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser writes ("Re: [Xen-devel] [PATCH] [Xend] Move some backend
configuration"):
> If libvirt is really going in at this private state, perhaps we could patch
> xend so that it writes to the new locations *in addition to* the old
> locations. It then has its own guaranteed-private and -consistent state,
> while libvirt can still read from old locations.
There are other reasons besides libvirt why we might want to write to
the old locations for a while too:  it will reduce the problems of
version skew between various components - for example, tools, and
hypervisor.

Does qemu-dm need to interact with this at all ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 04:09:49PM +0100, Keir Fraser
wrote:
> On 30/9/08 15:58, "John Levon" <levon@movementarian.org>
wrote:
> 
> >> Which guaranteed API would that be? These paths are private to the
toolstack
> >> implementation. Perhaps the only exception is the
> > 
> > Precisely the problem, there''s absolutely no idea or
indication what is
> > and isn''t private. Thus you get libvirt looking in places it
maybe
> > shouldn''t, but how are they supposed to know?
> > 
> > I''m pretty sure this patch breaks libvirt again.
> 
> I don''t really see why it would. Beyond the
console-client-to-daemon
> interface change (which we can make not depend on the /vm_path stuff) the
> rest is changing things which I believe are internal to xend.
> 
> If libvirt is really going in at this private state, perhaps we could patch
> xend so that it writes to the new locations *in addition to* the old
> locations. It then has its own guaranteed-private and -consistent state,
> while libvirt can still read from old locations.
I''ve done a quick check of what libvirt accesses in xenstore:

General VM metadata

 /local/domain/%d/vm 
 /local/domain/%d/cpu
 /local/domain/%d/name
 /local/domain/%d/running
 /local/domain/%d/memory/target
 /local/domain/%d/cpu_time

Console data

 /local/domain/%d/console/vnc-port
 /local/domain/%d/console/tty

For fetching disk/net statistics

 /local/domain/0/backend/vbd/%d/%d/state
 /local/domain/0/backend/vif/%d
 /local/domain/0/backend/vbd/%d
 /local/domain/0/backend/tap/%d


The first group is not being changed, so that''s not a problem. Likewise
the latter is not impacted. The only problem I see is with the console
TTY paths and VNC port.

While I would prefer it not to change, or have backwards compatability
data written in existing fields, we have the ability to check multiple
different data sources. So if the TTY info and VNC port is available
via the ''xm list --long'' output we could make libvirt check
there if it
fails to find it in xenstore. We only historically used xenstored for
the few occassions when the ''xm list --long'' output was
incomplete.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/9/08 16:30, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
> Console data
> 
>  /local/domain/%d/console/vnc-port
>  /local/domain/%d/console/tty
Duplicating this pair of nodes sounds fine to me, *but* then libvirt is
simply remaining vulnerable to the kind of attack we''re are looking to
avoid? Can any good really come from keeping the old locations?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:09:21PM +0100, Keir Fraser wrote:
> > Console data
> > 
> >  /local/domain/%d/console/vnc-port
> >  /local/domain/%d/console/tty
> 
> Duplicating this pair of nodes sounds fine to me, *but* then libvirt is
> simply remaining vulnerable to the kind of attack we''re are
looking to
> avoid? Can any good really come from keeping the old locations?
Why isn''t xenstored refusing writes/deletes from domid != 0 for these ?
Isn''t this a much better fix?

It''s ugly, but the mistake was made a long time ago, and it seems like
it should be lived with.

BTW, the ability to change the name or whatever also seems suspect,
though most likely less serious.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:09:21PM +0100, Keir Fraser
wrote:
> On 30/9/08 16:30, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> 
> > Console data
> > 
> >  /local/domain/%d/console/vnc-port
> >  /local/domain/%d/console/tty
> 
> Duplicating this pair of nodes sounds fine to me, *but* then libvirt is
> simply remaining vulnerable to the kind of attack we''re are
looking to
> avoid? Can any good really come from keeping the old locations?
Given that this is security sensitive, I have no objection to updating
libvirt to read from the new locations. The only thing I need to work 
out is a reliable way to choose when to use the new location, vs the 
looking at old location (for compat with existing deployments). 

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:35:52PM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 30, 2008 at 05:09:21PM +0100, Keir Fraser wrote:
> > On 30/9/08 16:30, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> > 
> > > Console data
> > > 
> > >  /local/domain/%d/console/vnc-port
> > >  /local/domain/%d/console/tty
> > 
> > Duplicating this pair of nodes sounds fine to me, *but* then libvirt
is
> > simply remaining vulnerable to the kind of attack we''re are
looking to
> > avoid? Can any good really come from keeping the old locations?
> 
> Given that this is security sensitive, I have no objection to updating
> libvirt to read from the new locations. The only thing I need to work 
> out is a reliable way to choose when to use the new location, vs the 
> looking at old location (for compat with existing deployments). 
I think the existence of /vm_path would do that, but we need to move
*all* this stuff, surely. /local/domain/X/ should be effectively
write-only from dom0 since none of it is trustworthy.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/9/08 17:35, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
>> Duplicating this pair of nodes sounds fine to me, *but* then libvirt is
>> simply remaining vulnerable to the kind of attack we''re are
looking to
>> avoid? Can any good really come from keeping the old locations?
> 
> Given that this is security sensitive, I have no objection to updating
> libvirt to read from the new locations. The only thing I need to work
> out is a reliable way to choose when to use the new location, vs the
> looking at old location (for compat with existing deployments).
That''s an interesting question. Obviously you don''t want to
race their
creation and go down the unsafe path unnecessarily.

We could add a node to xenstore, or append version/feature info to the pid
file? Do you have a preference?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:46:04PM +0100, Keir Fraser
wrote:
> On 30/9/08 17:35, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> 
> >> Duplicating this pair of nodes sounds fine to me, *but* then
libvirt is
> >> simply remaining vulnerable to the kind of attack we''re
are looking to
> >> avoid? Can any good really come from keeping the old locations?
> > 
> > Given that this is security sensitive, I have no objection to updating
> > libvirt to read from the new locations. The only thing I need to work
> > out is a reliable way to choose when to use the new location, vs the
> > looking at old location (for compat with existing deployments).
> 
> That''s an interesting question. Obviously you don''t want
to race their
> creation and go down the unsafe path unnecessarily.
> 
> We could add a node to xenstore, or append version/feature info to the pid
> file? Do you have a preference?
I think its probably best to have explicit "feature" info written into
somewhere in xenstore to indicate that the new layout is in use -
"version"
info would get too confusing when we inevitably have to backport this stuff.

To avoid a race condition we''d not want it in the per-VM areas.
It''d want
to be a global feature flag we can probe once when libvirt connects, 
rather than probing  per guest.

I notice there''s a  /tool area that''s unused

  # xenstore-ls /tool
  xenstored = ""

Could put a little feature flag node there perhaps ?


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:35:52PM +0100, Daniel P. Berrange
wrote:
> libvirt to read from the new locations. The only thing I need to work 
> out is a reliable way to choose when to use the new location, vs the 
> looking at old location (for compat with existing deployments). 
I think /vm_path existence indicates to look through /vm/, as for
the race I''m not sure how to handle this, however /vm and /vm_path
are updated before device creation - this should be equivalent to
looking at /local/domain.

-- 
\o/   Pascal Bouchareine - Gandi 
 g    0170393757           15, place de la Nation - 75011 Paris      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 30, 2008 at 05:35:37PM +0100, John Levon
wrote:
> Why isn''t xenstored refusing writes/deletes from domid != 0 for
these ?
> Isn''t this a much better fix?
We have to manage races and such, and prevent deletion up to the
parent nodes, too - Was not sure this was wanted/easy to do, or
clean as you mention
> BTW, the ability to change the name or whatever also seems suspect,
> though most likely less serious.
Untrusted user input coming into dom0 surely leads to bad things. 
"name" is stored into /vm too, I guess this one is used by tools ?

Most sensitive information in xend can be moved replacing calls to
read/storeDom with calls to read/storeVm.

-- 
\o/   Pascal Bouchareine - Gandi 
 g    0170393757           15, place de la Nation - 75011 Paris      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser writes ("Re: [Xen-devel] [PATCH] [Xend] Move some backend
configuration"):
> On 30/9/08 16:30, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> > Console data
> >  /local/domain/%d/console/vnc-port
> >  /local/domain/%d/console/tty
> 
> Duplicating this pair of nodes sounds fine to me, *but* then libvirt is
> simply remaining vulnerable to the kind of attack we''re are
looking to
> avoid? Can any good really come from keeping the old locations?
Once again we have this tradeoff: in an old installation which has not
been properly patched or updated, should we
  (a) continue to let the system `work'' but be vulnerable
  (b) make the system report an error so that the administrator
      knows that it needs to be fixed.

At least in this case I suppose we can expect old installations to be
patched _eventually_ ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 10:34, "Ian Jackson" <Ian.Jackson@eu.citrix.com>
wrote:
> Once again we have this tradeoff: in an old installation which has not
> been properly patched or updated, should we
>   (a) continue to let the system `work'' but be vulnerable
>   (b) make the system report an error so that the administrator
>       knows that it needs to be fixed.
> 
> At least in this case I suppose we can expect old installations to be
> patched _eventually_ ...
An update on this: I solved this issue by fiddling permissions in xenstore
after all! /local/domain/<domid> is now read-only to the guest, and
specific
subdirs only are writable (currently device, error and control).

This fixes the console vulnerability with no annoying movement of entries,
and also gets rid of the new /vm_path entries in xenstore since
/l/d/<domid>/vm can be trusted now.

I''ve compacted the changesets together and backported to 3.3 for 3.3.1.
It''ll also be an obvious candidate for 3.2 branch if that branch gets
an
ongoing maintainer.

Of course the one downside is that this slightly changes the guest-visible
interface since it can''t scribble at will in /l/d/<domid> any
more. I hope
noone was relying on that! If we need to open up some more specific subdirs
for write access, I will consider that.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 02, 2008 at 10:49:34AM +0100, Keir Fraser
wrote:
> An update on this: I solved this issue by fiddling permissions in xenstore
> after all! /local/domain/<domid> is now read-only to the guest, and
specific
> subdirs only are writable (currently device, error and control).
writing into device allows the guest to rewrite it''s backend
location, this should be protected too i guess ?

the patch stored backend paths into /vm for this reason

-- 
\o/   Pascal Bouchareine - Gandi 
 g    0170393757           15, place de la Nation - 75011 Paris      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 11:16, "Pascal Bouchareine" <pascal@gandi.net> wrote:
> On Thu, Oct 02, 2008 at 10:49:34AM +0100, Keir Fraser wrote:
>> An update on this: I solved this issue by fiddling permissions in
xenstore
>> after all! /local/domain/<domid> is now read-only to the guest,
and specific
>> subdirs only are writable (currently device, error and control).
> 
> writing into device allows the guest to rewrite it''s backend
> location, this should be protected too i guess ?
> 
> the patch stored backend paths into /vm for this reason
I kept that part of your patch as indeed the guest can still modify its
backend reference.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pascal Bouchareine writes ("Re: [Xen-devel] [PATCH] [Xend] Move some
backend configuration"):
> On Thu, Oct 02, 2008 at 10:49:34AM +0100, Keir Fraser wrote:
> > An update on this: I solved this issue by fiddling permissions in
xenstore
> > after all! /local/domain/<domid> is now read-only to the guest,
and specific
> > subdirs only are writable (currently device, error and control).
> 
> writing into device allows the guest to rewrite it''s backend
> location, this should be protected too i guess ?
We will arrange for the backend location not to be trusted by anything
important.  In fact, it is entirely formulaic: if you know which
domain the backend is supposed to be in, you can simply shuffle the
path components.  And you can double check against the backend''s
frontend path.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 11:21, "Ian Jackson" <Ian.Jackson@eu.citrix.com>
wrote:
>> writing into device allows the guest to rewrite it''s backend
>> location, this should be protected too i guess ?
> 
> We will arrange for the backend location not to be trusted by anything
> important.  In fact, it is entirely formulaic: if you know which
> domain the backend is supposed to be in, you can simply shuffle the
> path components.  And you can double check against the backend''s
> frontend path.
If you know the backend domid this works great. You don''t need to check
anything in this case. If you try to validate the frontend''s backend
reference then that''s hard: strictly speaking you can only trust the
/local/domain/0 path prefix since otherwise two domains could collude to
redirect you to a backend directory under their control (or a domain could
point you at a ''backend directory'' under its own path prefix,
for example).
So this approach really only works for backends known to be in dom0 (which
of course is true for the vast majority of Xen installations). Hence xend is
storing the backend path under /vm where it''s safe. Equally it could
store
only the backend-id and construct the backend path from that.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser writes ("Re: [Xen-devel] [PATCH] [Xend] Move some backend
configuration"):
> If you know the backend domid this works great. You don''t need to
check
> anything in this case.
Right.  qemu (non-stubdom, which is the relevant case) knows its own
domid and that is the relevant one - because qemu is providing a
parallel path to the pv frontend/backend arrangements, the relevant
backend it is supposed to be the one that qemu is running in.

If it isn''t then there is something wrong, so it should check it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 02, 2008 at 10:49:34AM +0100, Keir Fraser wrote:
> Of course the one downside is that this slightly changes the guest-visible
> interface since it can''t scribble at will in /l/d/<domid>
any more. I hope
> noone was relying on that! If we need to open up some more specific subdirs
> for write access, I will consider that.
We''re writing to the following paths that aren''t standard:

device-misc/vif/default-link
hvmpv/{xpv,xdf,xpvd,xnf}/version

Can they be opened up? (Ideally we''d use the guest/ suggestion below,
and we will, but there''s already stuff out there assuming it can do
this.)

Also, I''d like to see an explicit /l/d/domid/guest directory. The guest
can write anything there, but there''s a clear indicator that
it''s not to
be trusted (we could even document this stuff by expanding xenstore.txt
?)

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 14:45, "John Levon" <levon@movementarian.org> wrote:
> We''re writing to the following paths that aren''t
standard:
> 
> device-misc/vif/default-link
> hvmpv/{xpv,xdf,xpvd,xnf}/version
> 
> Can they be opened up? (Ideally we''d use the guest/ suggestion
below,
> and we will, but there''s already stuff out there assuming it can
do
> this.)
What happens if you try to write them, and fail? What are they actually used
for (e.g., communication with your own xvm tool stack?).
> Also, I''d like to see an explicit /l/d/domid/guest directory. The
guest
> can write anything there, but there''s a clear indicator that
it''s not to
> be trusted (we could even document this stuff by expanding xenstore.txt
> ?)
Probably a good idea.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 15:04, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
>> Also, I''d like to see an explicit /l/d/domid/guest directory.
The guest
>> can write anything there, but there''s a clear indicator that
it''s not to
>> be trusted (we could even document this stuff by expanding xenstore.txt
>> ?)
> 
> Probably a good idea.
On the other hand, should we be encouraging guests to squirrel
guest-specific stuff away in xenstore? Really it''s for communication
with
backends (via device/ subdir) and with toolstacks (which can open up access
to other subdirs if they wish, since presumably they run in dom0). It''s
not
supposed to be a handy storage area (and indeed it doesn''t persist
across
save/restore).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

John Levon writes ("Re: [Xen-devel] [PATCH] [Xend] Move some backend
configuration"):
> On Thu, Oct 02, 2008 at 10:49:34AM +0100, Keir Fraser wrote:
> > Of course the one downside is that this slightly changes the
guest-visible
> > interface since it can''t scribble at will in
/l/d/<domid> any more. I hope
> > noone was relying on that! If we need to open up some more specific
subdirs
> > for write access, I will consider that.
> 
> We''re writing to the following paths that aren''t
standard:
> 
> device-misc/vif/default-link
> hvmpv/{xpv,xdf,xpvd,xnf}/version
What are these and how are they used ?
>  (we could even document this stuff by expanding xenstore.txt ?)
xenstore.txt currently has only the xenstored<->domains protocol, and
doesn''t specify the structure or meaning of the xenstore tree.

interface.tex is supposed to do the latter but it''s hopelessly out of
date and of course no-one really wants to edit TeX when they update
anything.

If some kind soul were to make a stab at extracting the relevant
(true!) parts of interface.tex into a new .txt file that would be very
nice :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 02, 2008 at 03:04:48PM +0100, Keir Fraser wrote:
> > We''re writing to the following paths that aren''t
standard:
> > 
> > device-misc/vif/default-link
> > hvmpv/{xpv,xdf,xpvd,xnf}/version
> > 
> > Can they be opened up? (Ideally we''d use the guest/
suggestion below,
> > and we will, but there''s already stuff out there assuming it
can do
> > this.)
> 
> What happens if you try to write them, and fail? What are they actually
used
> for (e.g., communication with your own xvm tool stack?).
They''re both tool stack values, so in the sense that we can permanently
patch xenstored, you don''t need the change, you''re right.
Although, we''re already
carrying way way too much customizations.

The former contains the "main" IP address of the domU. The latter
contain driver versions, to allow for the tool stack to determine a need
for updates. Note that neither are general enough to try and merge up as
a standard thing IMO, perhaps you disagree.

Regarding guest/ - xenstore is by far the simplest and easiest way to
communicate with the tool stack. I strongly doubt that we''re the only
vendor to have done, or want to do, something like the above. Of course
there are caveats, but compared to the alternative (guest additions -
blech), it''s pretty low cost.

I don''t see it going away, so in my mind explicitly saying now that you
should only use guest/$(VENDOR) will avoid a lot of trouble down the
line.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/10/08 16:09, "John Levon" <levon@movementarian.org> wrote:
>> What happens if you try to write them, and fail? What are they actually
used
>> for (e.g., communication with your own xvm tool stack?).
> 
> They''re both tool stack values, so in the sense that we can
permanently
> patch xenstored, you don''t need the change, you''re right.
Although, we''re
> already
> carrying way way too much customizations.
Well, you don''t need to patch xenstored. Your customised toolstack --
the
one that consumes these extra nodes -- can also open them up, right? The
only reason to open them in xend is if that is the difference between them
working and not working running against the default open-source toolstack.

I will allow these through if there is a net win for compatibility with the
default open-source toolstack. But I don''t particularly want to do so
just
to save you a one-line patch to your xend or equivalent.
> I don''t see it going away, so in my mind explicitly saying now
that you
> should only use guest/$(VENDOR) will avoid a lot of trouble down the
> line.
Mmm... I suppose I can see logic here. Vendor daemons running alongside
open-source xend for example.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 02, 2008 at 04:25:39PM +0100, Keir Fraser wrote:
> > They''re both tool stack values, so in the sense that we can
permanently
> > patch xenstored, you don''t need the change, you''re
right. Although, we''re
> > already
> > carrying way way too much customizations.
> 
> Well, you don''t need to patch xenstored. Your customised toolstack
-- the
> one that consumes these extra nodes -- can also open them up, right? The
> only reason to open them in xend is if that is the difference between them
> working and not working running against the default open-source toolstack.
> 
> I will allow these through if there is a net win for compatibility with the
> default open-source toolstack. But I don''t particularly want to do
so just
> to save you a one-line patch to your xend or equivalent.
I should have read your fix. We will probably do that one-liner to xend
too (the toolstack lives at least two levels above xend, so it''s not
the
best place). 

thanks,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel