| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] PCI delegation works, access to the delegated NIC doesn'
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
|
|
|
| |
|
Home