From owner-freebsd-arch@FreeBSD.ORG Mon Jun 16 14:32:41 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 0648F37B401; Mon, 16 Jun 2003 14:32:41 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1313843FB1; Mon, 16 Jun 2003 14:32:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5GLwHMo012012; Mon, 16 Jun 2003 17:58:17 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5GLXCCO014173; Mon, 16 Jun 2003 14:33:12 -0700 (PDT) (envelope-from jmg) Date: Mon, 16 Jun 2003 14:33:12 -0700 From: John-Mark Gurney To: Scott Long Message-ID: <20030616213312.GV73854@funkthat.com> Mail-Followup-To: Scott Long , arch@freebsd.org, Robert Watson References: <20030616074122.GF73854@funkthat.com> <20030616194935.GR73854@funkthat.com> <3EEE2B31.4020406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EEE2B31.4020406@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html 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 Reply-To: John-Mark Gurney 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:32:41 -0000 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."