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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel