|
xen-devel
Re: [Xen-devel] PCI delegation works, access to the delegated NIC doesn'
On Wed, 2006-03-08 at 16:26 +0000, Keir Fraser wrote:
> 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.
That is true. However, it seems to me that most people don't put the
driver alone in the driver domain. Rather, they put the device in a domU
they wish to run many applications in. If the domain is compromised, an
attacker could cause a *little* bit of havoc on the pci bus (affecting
devices in other domains) by messing with registers like the BARs or
possibly DoS other devices by changing the interrupt pin.
>
> 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
>
I fear that providing an easy way around the security will mean that it
will just get turned off rather than forcing developers to correct the
problem. I think this should be viewed as a workaround and some more
permanent solution be put in place (perhaps the "quirks" method? see the
pci_fixup_device method in Linux). I'm going to try and prepare an
example of what I think is the correct way to fix this issue.
If you need to include a "permissive" mode, instead of allowing
permissive mode blankly for all devices in all driver domains, could we
instead just limit it to a single device or single domain? I think the
current permissive flag opens things up unnecessarily.
Keir, I don't believe your patch is entirely correct. If you write a
double-word and one byte or one word of that double-word gets picked up
in a field in the virtual configuration space overlay but not the other
bytes or word, the handled flag will still get set to true, but the
remaining bytes will never be written to the device. I think correctly
implementing this is non-trivial as you'd need to put some code up above
to track which bytes have been handled and which ones haven't. However,
I think it's unlikely that you'd ever have this condition actually
affect a device given the current virtual configuration space.
Ryan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home