[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PCI delegation works, access to the delegated NIC doesn't

On 8 Mar 2006, at 15:25, Ryan wrote:

I've suspected that such cards exist (that use device-specific registers
in the configuration space), but have not yet seen one in practice. If
this is indeed the problem, one solution would be to detect the card in
the PCI backend and modify its virtual configuration space to allow
writes to those specific registers (a pciback "quirks" capability
similar to the quirks capability for PCI devices in Linux). This
wouldn't be difficult, but it could get out-of-control if we have to do
that for a lot of cards. Another possibility is to add some kind of flag
that allows all writes to work that are not specifically blocked. I
don't like that idea at all (default permit is not a good security
posture), but would allow people with devices like this one to get them
working (albeit with less protection). Any other suggestions?

It depends what the threat model is. In most scenarios device drivers will only be installed by administrators or main users of a system, and it is reasonable to assume they are not actively malicious. The main aim of driver domains is to protect against stupid driver bugs not smart malicious drivers.

Being as restrictive as possible by default does make sense, but we need an easy way to make things more permissive so that people can get drivers working while still get some (in fact, probably most) of the benefit of driver domains (that being restartability when a driver shoots itself in the foot).

To this end I've checked in a 'permissive' module flag which allows PCI config writes to succeed by default. Enabled by specifying 'pciback.permissive' as a boot parameter or:
 echo Y >/sys/modules/pciback/permissive

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.