From owner-freebsd-arch@FreeBSD.ORG Mon Jun 16 14:54:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FD5F37B401; Mon, 16 Jun 2003 14:54:46 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCEA43FB1; Mon, 16 Jun 2003 14:54:43 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h5GLsW810554; Mon, 16 Jun 2003 14:54:32 -0700 Received: from freebsd.org (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id OAA07414; Mon, 16 Jun 2003 14:54:41 -0700 (PDT) Message-ID: <3EEE3BF2.3020809@freebsd.org> Date: Mon, 16 Jun 2003 15:51:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <20030616074122.GF73854@funkthat.com> <20030616194935.GR73854@funkthat.com> <3EEE2B31.4020406@freebsd.org> <20030616213312.GV73854@funkthat.com> In-Reply-To: <20030616213312.GV73854@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Robert Watson Subject: Re: make /dev/pci really readable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2003 21:54:46 -0000 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