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


[Xen-devel] possible pciback security issue

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] possible pciback security issue
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 04 May 2006 14:57:34 +0200
Delivery-date: Thu, 04 May 2006 05:56:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Having looked more closely into what would be needed to enable MSI support I 
stumbled across a simple question: If a
domU is granted access to an MSI-capable device, it could maliciously or 
erroneously enable MSI on that device and
program an arbitrary vector to be delivered, or even force the message address 
and/or value to something that might make
the system misbehave/crash.
It would seem to me that filtering only a few header fields is insufficient 
from a security point of view, not only
from the perspective of MSI. While this may severely limit functionality, I 
think by default only read access must be
granted to any fields/bits of unknown meaning (namely everything outside the 


Xen-devel mailing list

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