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] protecting xen startup

To: Luke Kenneth Casson Leighton <lkcl@xxxxxxxx>
Subject: Re: [Xen-devel] protecting xen startup
From: Mark Williamson <maw48@xxxxxxxxxxxxxxxx>
Date: Wed, 24 Nov 2004 11:55:26 +0000 (GMT)
Cc: "Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 24 Nov 2004 12:01:48 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <20041124105300.GN5146@xxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <39CC97884CA19A4D8D6296FE94357BCBF5C747@swsmsx404> <20041124105300.GN5146@xxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
are you hinting at the allocation of device drivers across domains?

e.g. having one domain do the hardware side and securely
proxy-forwarding the access to that device over to another domain?

Well, this is really already done. e.g. net and block devices are securely shared. Domain 0 runs the real physical device driver and the unprivileged domain uses a virtual device driver to communicate its requests to dom0. These are requests are validated before being accepted.

Setting up these "device channels" is reasonably involved. A protocol using the control message framework is used to communicate to the "backend" (runs in dom0 and co-ordinates sharing) and "frontend" (runs in guest and provides virtual devices to the guest) about what virtual devices exist. The protocol is then used to establish a shared-memory connection between the two.

One problem here is that domain 0's control interface (used to communicate with the backend drivers) can only have one writer. Hence it's necessary to ensure mutual exclusion - we let Xend control writing requests to this interface.

As well as keeping track of various forms of state, you also need to ensure that the control interface is dealt with correctly, which could be quite a bit of work.

... but i have to point out that i'm more concerned about leveraging
what is available - right now - than i am about future versions.

Sure thing. We're planning to add mandatory access control features at some stage but that's still on the drawing board at the moment. In the meantime, there should be plenty of other fun to be had...

Cheers,
Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

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