make /dev/pci really readable

John-Mark Gurney gurney_j at efn.org
Mon Jun 16 14:32:41 PDT 2003


Scott Long wrote this message on Mon, Jun 16, 2003 at 14:40 -0600:
> You should not always assume that reading PCI registers has no
> side-effects.  It is certainly legal and possible for a PCI device to
> detect the read request and alter the contents of the register (or some
> other register) as a side effect, or change an internal state machine.
> 'Fixing' the various bits to allow unpriviledged access to 'pciconf -r'
> is dangerous since you would have to teach the system about every pci
> device in existance and how to trap on registers that have side-effects.

hmmm.  are you sure about this?  wouldn't it mean that by simply probing
for a device you could end up locking up the system? 

> I see little reason why unpriviledged users should be given
> register-level access to anything.  We don't let them read /dev/mem, do
> we?  Fixing 'pciconf -l' is fine, but it really doesn't need to extend
> beyond that.  I would consider 'pciconf -r' to be a security risk and
> would treat it as such when it comes time for a release.

My only idea was for developers working on pci drivers.  It was
invaluable to be able to read the registers when debuging the sparc64
pci stuff and writing my zoran driver, but I didn't want to have to
become root every time I wanted to look at this.  The only problem is
that this requires three levels of permission, list, read, and write..
changing it to support three is too much against (like overriding write
to mean read, etc) POLA, so I abandonded it.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


More information about the freebsd-arch mailing list