WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Prevent unnatural use of ioctl in /proc/xen/xenb

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Prevent unnatural use of ioctl in /proc/xen/xenbus_dev
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Sat, 10 Sep 2005 22:19:42 +1000
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Sat, 10 Sep 2005 12:17:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b1fe41ca3440376e52de9d09b696c6d8@xxxxxxxxxxxx>
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: <1126265347.5623.18.camel@xxxxxxxxxxxxxxxxxxxxx> <b1fe41ca3440376e52de9d09b696c6d8@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2005-09-09 at 13:48 +0100, Keir Fraser wrote:
> On 9 Sep 2005, at 12:29, Rusty Russell wrote:
> 
> > xenbus_dev's use of ioctl for read/write is a crime against nature.
> > Make it a read-write interface, but check boundaries so we can recover 
> > if userspace dies.  This also simplifies libxenstore.
> 
> How can you cleanly express the request/reponse nature of interacting 
> with xenstore, and grouping of accesses into transactions, via 
> read/write?

Err... the same way we do when tools interact with the store over a
pipe?  Which is the same protocol we use in shared memory.

>  I would imagine you lose valuable framing information that 
> you end up having to reconstruct.

The only painful part is that userspace is now hijacking the kernel's
xenstore comms channel.  While we clearly trust userspace somewhat,
since they're using our ID for operations, we want to ensure that we
have a usable channel if they die unexpectedly.  Otherwise it would be
entirely trivial...

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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

<Prev in Thread] Current Thread [Next in Thread>