Date: Mon, 16 Jun 2003 15:51:46 -0600 From: Scott Long <scottl@freebsd.org> To: John-Mark Gurney <gurney_j@efn.org> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: make /dev/pci really readable Message-ID: <3EEE3BF2.3020809@freebsd.org> In-Reply-To: <20030616213312.GV73854@funkthat.com> References: <20030616074122.GF73854@funkthat.com> <Pine.NEB.3.96L.1030616135002.8726B-100000@fledge.watson.org> <20030616194935.GR73854@funkthat.com> <3EEE2B31.4020406@freebsd.org> <20030616213312.GV73854@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote: > 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? > The first 64 bytes in the space is likely safe, from bytes 65-255 it is entirely vendor specific. > >>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. > I'll not argue your development practices. However, I don't see it as unreasonable to ask that driver writers who are going to need root access to do their work anyways (modifying files, compiling kernels and/or loading modules) also use root to access the pci registers from userland. I seem to remember Linx having a similar feature a few years ago and naive sysadmins getting into serious trouble by pointing their tape backups at the /proc/pci directory. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EEE3BF2.3020809>