NetBSD Problem Report #16300

Received: (qmail 6425 invoked from network); 11 Apr 2002 14:35:46 -0000
Message-Id: <20020411142901.BC64A4DD5@moose-au-chocolat.dau.reziprozitaet.de>
Date: Thu, 11 Apr 2002 16:29:01 +0200 (CEST)
From: Klaus Klein <kleink@reziprozitaet.de>
Sender: kleink@dau.reziprozitaet.de
To: gnats-bugs@gnats.netbsd.org
Subject: unprivileged PCI config space access considered harmful
X-Send-Pr-Version: 3.95

>Number:         16300
>Category:       kern
>Synopsis:       unprivileged PCI config space access considered harmful
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 11 14:36:00 +0000 2002
>Closed-Date:    Mon Nov 22 23:10:41 +0000 2010
>Last-Modified:  Mon Nov 22 23:10:41 +0000 2010
>Originator:     Klaus Klein
>Release:        2002-04-11
>Organization:
Frobozz Magic Packet Co.
>Environment:
n/a

>Description:
	With the new pci(4) interface, it is possible for any process
	that can open a pci(4) device node for reading to arbitrarily
	read from configuration space.

	This is not necessarily without side effects.

	As set up by MAKEDEV(8), it is possible for any user to do so:
	crw-r--r--  1 root  wheel  83, 0 Nov 30 00:40 /dev/pci0

>How-To-Repeat:

	503 3 we-the-jury:kleink Thu Apr 11 16:15:38 ~
	$ pcictl /dev/pci0 list
	000:11:0: Intel 82378ZB System I/O (SIO) (miscellaneous prehistoric, revision 0x03)
	000:12:0: Symbios Logic 53c810 (miscellaneous prehistoric, revision 0x01)
	000:14:0: Weitek P9100 (VGA display)
	504 4 we-the-jury:kleink Thu Apr 11 16:15:43 ~
	$ pcictl /dev/pci0 dump -d 12 >/dev/null

	Then observe:

	siop0:parity error
	siop0: scsi bus reset
	sd0: async, 8-bit transfers, tagged queueing
	sd0: sync (100.0ns offset 8), 8-bit (10.000MB/s) transfers, tagged queueing

	One can easily imagine more interesting side effects, depending on
	the device in question, but I didn't dare to find out.

>Fix:
	Three options that immediately come to my mind:

	1) Make pci(4) device nodes non-accessible in the standard setup.

	   This is probably a bit too drastic, and defeats one of the
	   interface's purposes.

	2) In pciioctl(), restrict access to registers free of side effects
	   defined in the PCI specification.

	   Ugly, but might do for most users.

	3) Use a device minor number bit as a flag to select a restriction
	   such as outlined in 2), and have an alternate device node, say,
	   /dev/pciuN accessible to all, with access permissions of the
	   /dev/pciN device nodes being restricted.

	   While this is the most flexible solution of the three, I guess
	   some will call it unintuitive...


>Release-Note:
>Audit-Trail:
From: "Jonathan A. Kollasch" <jakllsch@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/16300 CVS commit: src/etc
Date: Sun, 19 Sep 2010 20:52:23 +0000

 Module Name:	src
 Committed By:	jakllsch
 Date:		Sun Sep 19 20:52:23 UTC 2010

 Modified Files:
 	src/etc: MAKEDEV.tmpl

 Log Message:
 Make pci(4) device nodes root:wheel 0640 by default.
 Mortals do not need to be able to generate PCI Configuration Space
 read transactions, which are not entirely without side effect, as
 reported in PR#16300.


 To generate a diff of this commit:
 cvs rdiff -u -r1.135 -r1.136 src/etc/MAKEDEV.tmpl

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: jakllsch@NetBSD.org
State-Changed-When: Sun, 19 Sep 2010 20:57:51 +0000
State-Changed-Why:
Issue may have been addressed by recent commit.


From: Klaus Klein <kleink@reziprozitaet.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, jakllsch@NetBSD.org,
	Klaus Klein <kleink@reziprozitaet.de>
Subject: Re: kern/16300 (unprivileged PCI config space access considered harmful)
Date: Sun, 10 Oct 2010 18:15:26 +0200

 On Sun, Sep 19, 2010 at 08:57:53PM +0000, jakllsch@NetBSD.org wrote:
 > Synopsis: unprivileged PCI config space access considered harmful
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: jakllsch@NetBSD.org
 > State-Changed-When: Sun, 19 Sep 2010 20:57:51 +0000
 > State-Changed-Why:
 > Issue may have been addressed by recent commit.

 Sure, since that's option 1) as suggested in the report.  However,
 I still stand by the reservation I had back then. :-)

 Anyway, if you think this resolves the issue satisfactorily, feel
 free to close.


 Thanks,
 - Klaus

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/16300 (unprivileged PCI config space access considered
 harmful)
Date: Mon, 11 Oct 2010 01:55:15 +0000

 On Sun, Oct 10, 2010 at 04:20:03PM +0000, Klaus Klein wrote:
  >  Sure, since that's option 1) as suggested in the report.  However,
  >  I still stand by the reservation I had back then. :-)
  >  
  >  Anyway, if you think this resolves the issue satisfactorily, feel
  >  free to close.

 What unprivileged processes expect to be able to root around in PCI
 configuration space? The only candidate I can think of offhand is the
 X server, and that's more of a bug/historical weakness than anything
 else...

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 22 Nov 2010 23:10:41 +0000
State-Changed-Why:
I don't think we have a persuasive use case for unprivileged PCI
configuration reads... and from the scuttlebutt I've heard over the
years I rather doubt it's possible to make it safe for all broken
motherboards.


>Unformatted:

Home	PR Database Search