Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Dag-Erling Smorgrav wrote: > > Wes Peters <[EMAIL PROTECTED]> writes: > > BSD for the masses. > > "BSD on every desk and in every home" > > DES (ducks, runs) You can run, but wherever you go, there'll be a BSD system waiting for you. At least that's MY goal. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
"Daniel C. Sobral" wrote: > > Warner Losh wrote: > > > > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: > > : ported to every hardware platform under sun, and we do not go out of our > > : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on > > > > What? I don't see how you can say that about security... > > We don't go *out* of our way. And just because OpenBSD has an *edge*, > that doesn't mean said edge is all that big. FreeBSD balances security concerns with usability, whereas OpenBSD goes for the "security" choice every time. This makes one of the systems more secure without user tuning, the other more functional without user tuning. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
"Daniel C. Sobral" wrote: > > David O'Brien wrote: > > > > 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. > > Yep, "server" is much more to the point. And not simply best performing, > but we also strive to be user-friendly. > > The bottomline is that we, of the BSDs, do *not* have a focus. We want > to support good servers and good desktops and good notebooks, we want to > provide performance and user friendlyness. We do not care about being > ported to every hardware platform under sun, and we do not go out of our > way to provide security. Thus, NetBSD and OpenBSD have the edge on us on > these respects, but we gain by providing a better overall enviroment on > the platforms we support. The problem is that you can't one-line that. BSD for the masses. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: > : ported to every hardware platform under sun, and we do not go out of our > : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on > > What? I don't see how you can say that about security... We don't go *out* of our way. And just because OpenBSD has an *edge*, that doesn't mean said edge is all that big. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: : ported to every hardware platform under sun, and we do not go out of our : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on What? I don't see how you can say that about security... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
David O'Brien wrote: > > 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. Yep, "server" is much more to the point. And not simply best performing, but we also strive to be user-friendly. The bottomline is that we, of the BSDs, do *not* have a focus. We want to support good servers and good desktops and good notebooks, we want to provide performance and user friendlyness. We do not care about being ported to every hardware platform under sun, and we do not go out of our way to provide security. Thus, NetBSD and OpenBSD have the edge on us on these respects, but we gain by providing a better overall enviroment on the platforms we support. The problem is that you can't one-line that. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" 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-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, 8 Dec 2000, Chad R. Larson wrote: > I'm not trying to foster a war here. There seems to be enough of > that anyway. But unless this PCI register reading thingie is an > issue for i386 boxen (and I don't think it is) we shouldn't cripple > functionality on the i386 for the Alpha. Allowing programs direct access to hardware is Windows 95's thing, though. We don't want to tread on its turf. 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. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message <[EMAIL PROTECTED]> "Chad R. Larson" writes: : Has the core group ever weighed in on this? Does the BSDi merger : change any of the FreeBSD focus with regard to other hardware : architectures? Core, per se, hasn't. There's a very strong history in this project that if a port is supported, breaking it is unacceptible. FreeBSD has moved beyond intel only, and we need to deal with that, even if there are things we can get away with on i386 and can't on other platforms. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
As I recall, Matthew Jacob wrote: > > Agreed. Thanks for spotting this, Andrew. > > No, we should not let users read PCI registers in such a fashion that > will cauase the system to crash. Ok, I guess just because it's the holiday season, I feel like opening a can of worms. 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 If that's accurate (and it may not be), then how concerned should we be about the Alpha port? Isn't Alpha (and SPARC, etc) the space stake out by the NetBSD gang? I'm not trying to foster a war here. There seems to be enough of that anyway. But unless this PCI register reading thingie is an issue for i386 boxen (and I don't think it is) we shouldn't cripple functionality on the i386 for the Alpha. Has the core group ever weighed in on this? Does the BSDi merger change any of the FreeBSD focus with regard to other hardware architectures? -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Sat, Dec 02, 2000 at 21:38:19 -0700, Lyndon Nerenberg wrote: > > "Kenneth" == Kenneth D Merry <[EMAIL PROTECTED]> writes: > > >> 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). > > Kenneth> At least with the PCIOCGETCONF, you need write > Kenneth> permission, because it copies in patterns to match > Kenneth> against. > > Does that have to equate with write access? Since you aren't changing > anything (device-wise) it seems this should be a read-only thing (even > though you're actually writing into the kernel memory arena). >From your comments below, you apparantly don't have to have write access to do a copyin. I would like to have pciconf -l available for normal users, but my only hesitation is that there could be security implications. If we can get someone (i.e. a security type person) to check the PCIOCGETCONF code carefully for any potential problems, then we can enable it for normal users. The code wasn't written with security in mind, so I don't want to open it up to regular users without a security evaluation. If we can get that, then I don't see a problem with allowing read only access for that ioctl. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message <[EMAIL PROTECTED]> Andrew Gallatin writes: : I'd vote for leaving the access permissions as is. I'd agree with that. We don't know that all PCI hardware will not cause problems when arbitrary locations in config space are read. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Andrew Gallatin wrote: > > Kenneth D. Merry writes: > > 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. > > I think that you might be able to crash an alpha with an unaligned > access trap by reading an int or short an from an unaligned offset in > config space. At least this used to be true.. I'd vote for leaving > the access permissions as is. I've accidently toasted boxes with this before. We really should fix it some time Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
> "Kenneth" == Kenneth D Merry <[EMAIL PROTECTED]> writes: >> 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). Kenneth> At least with the PCIOCGETCONF, you need write Kenneth> permission, because it copies in patterns to match Kenneth> against. Does that have to equate with write access? Since you aren't changing anything (device-wise) it seems this should be a read-only thing (even though you're actually writing into the kernel memory arena). Kenneth> As for PCIOCREAD, it only allows reading of PCI Kenneth> registers, so the question there is whether there are any Kenneth> potential security implications to allowing non-root Kenneth> users to read PCI registers. If reading configuration Kenneth> registers caused performance degredation, for instance. Yup, this dawned on me later. Meanwhile, though, I've been running with the read-only PCIOCGETCONF patch I suggested and I haven't seen any problems with it after close to a week of use. I've submitted that version as a pair of pr's (one for the kernel, and one for pciconf). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Agreed. Thanks for spotting this, Andrew. No, we should not let users read PCI registers in such a fashion that will cauase the system to crash. > > Kenneth D. Merry writes: > > 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. > > I think that you might be able to crash an alpha with an unaligned > access trap by reading an int or short an from an unaligned offset in > config space. At least this used to be true.. I'd vote for leaving > the access permissions as is. > > Drew > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Kenneth D. Merry writes: > 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. I think that you might be able to crash an alpha with an unaligned access trap by reading an int or short an from an unaligned offset in config space. At least this used to be true.. I'd vote for leaving the access permissions as is. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" in the body of the message
PCIOCGETCONF/PCIOCREAD requires write permission?
[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. 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). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
