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-users

Re: [Xen-users] Running workstation and firewall on the same hardware

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Running workstation and firewall on the same hardware
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 9 Aug 2005 18:06:36 +0100
Cc: Goetz Bock <bock@xxxxxxxxxxx>
Delivery-date: Tue, 09 Aug 2005 17:05:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050808225438.GD8146@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <d3e62a6b0508071107440f8e71@xxxxxxxxxxxxxx> <42F7DEC3.9030201@xxxxxxxx> <20050808225438.GD8146@xxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> > This is interesting. How robust is the isolation between domains and
> > what are the possible risks?
>
> I just skimmed through my mail-backlog today, but there was one post in
> the recent days that summed up to:
>
> "A domain with access to a PCI (bus)master device can abuse this
> abilities to overwrite arbitrtary memmory locations"
>
> So, after you owned the DomU that has controll of the network card, you
> have to twaeke it into loading a new driver for the network card, that
> abuses the PCI busmaster capabilities to overwrite some memory of the
> supervisor to breake out of the DomU.
>
> while this is known to be easy (for complicated values of easy) to do
> with a firewire device/port I don't think you have anything to fear.
>
> If I were to face a hacket that is able to do that (remotely), she has
> much lowerhanging fruits to pick on the rest of my systems ;-)

Absolutely.  You'd need to devise an attack that can abuse the specific 
device's DMA capabilities in some cunning way to capture sensitive 
information or overwrite it.  This would be rather fiddly...  You can also 
impede this by standard measures such as running tripwire over the 
filesystem, a kernel without modules support, etc.

> > From what you wrote it seems that allowing domU access to the hardware
> > is more risky than passing all packets to domU through dom0.
>
> Yes and no. You'd have to studdy the PCI busmaster capabilities of your
> networkcard to know for sure.
>
> moving the hardware access to one domU has the advantage that you can
> reboot the "driver domain" when required. But it's more complicated to
> set up. Personaly I've never tried to do that. handling all hardware
> access in dom0 was fine with me.

It's not *terribly* complicated but it is a bit of a fiddle.  We could do with 
making this a bit friendlier.  A nice hack would be to abuse Linux's PCI 
hotplug support to allow PCI cards to be dynamically reassigned - then we 
could just provide a GUI for "Give domain this device".

Cheers,
Mark

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