Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Wes Peters <[EMAIL PROTECTED]> writes: > BSD for the masses. "BSD on every desk and in every home" DES (ducks, runs) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On 2000-12-08 10:02 -0600, Mike Silbersack <[EMAIL PROTECTED]> wrote: > Seriously, though. There must be some way to abuse such direct access to > the pci configuration registers. Just because nobody has figured it out > how yet doesn't mean that enabling the feature is a good idea. Well, what makes you think, that nobody has figured out why read access to the pci config space registers might not be a good idea ? ;-) The reason is simple: There are a number of PCI devices that fail in a number of ways, if certain config space registers are accessed while the device is active. This is counterintuitive at first, but just try to read a config register beyond 0x80 from an NCR SCSI chip while it is executing SCRIPTS code ... The PCI spec made higher numbered config space registers implementation dependent. Some vendors mapped their devices' operational registers into config space, even though the spec never encouraged that (though I'm not sure that such an (ab)use of config registers was declared forbidden in later revisions of the spec.). Since there are a number of devices that could be severely impacted by read accesses to configuration space registers, we can't safely permit any user such read access. Root hopefully knows what he is doing and only accesses such registers that are meant to be accessed while the device is operating ... Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote: > I thought the space staked out by the *BSD gang was approximately > this: > NetBSD - the least amount of platform-specific code possible; run > on most anything > OpenBSD - pro-active security, bullet-proof from attacks > FreeBSD - best performing on the Intel PC platform s/the Intel PC/server/ The Alpha has very good I/O bandwidth and 64-bit address space. Thus it fits our niche. You also mentioned Sparc, but really should have said sparc64(pci based). hopefully embeded soon too. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 01, 2000 at 13:56:13 -0700, Lyndon Nerenberg wrote: > [Observed on 4.2-STABLE, but I've redirected replies to the hackers list.] > > 'pciconf -l' is documented to work for non-priv users, however the > first thing the underlying ioctl code (pci_ioctl) does is bail with EPERM > if the caller does not have /dev/pci open for write. The documentation is wrong, unfortunately. > Is there any reason why the FWRITE test cannot/should not be moved down > into the 'case PCIOCWRITE' part of the switch? This would make both > PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which > seems to me to be saner behaviour). At least with the PCIOCGETCONF, you need write permission, because it copies in patterns to match against. As for PCIOCREAD, it only allows reading of PCI registers, so the question there is whether there are any potential security implications to allowing non-root users to read PCI registers. If reading configuration registers caused performance degredation, for instance. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
