Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Jun 2003 11:42:04 -0700
From:      John-Mark Gurney <gurney_j@efn.org>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        arch@freebsd.org
Subject:   Re: make /dev/pci really readable
Message-ID:  <20030616184204.GL73854@funkthat.com>
In-Reply-To: <Pine.NEB.3.96L.1030616135002.8726B-100000@fledge.watson.org>
References:  <20030616074122.GF73854@funkthat.com> <Pine.NEB.3.96L.1030616135002.8726B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote this message on Mon, Jun 16, 2003 at 13:54 -0400:
> 
> On Mon, 16 Jun 2003, John-Mark Gurney wrote:
> 
> > Does anyone have an objection to making /dev/pci really honor the
> > permissions, and giving normal users (or just group wheel) premission to
> > run pciconf -l.  Right now the code requires the write bit set for any
> > operation. 
> 
> I seem to recall that there was a problem wherein user processes could
> cause cause unaligned accesses using /dev/pci.  There's also some rather

again, I just proposed -l, not -r to become user readable. I know that -r
has problems.  I've crashed the sparc box a number of times by specifing
pciconf -r pci1:5:0 0x0:0xf.

> odd use of useracc(), printf(), etc, in the ioctl code.  I suspect this

well, do you mean odd use of printf as in providing diagnostics to catch
mismatched userland/kernel?

for useracc, it checks to make sure that various pointers passed to it
are either readable or writable.  I don't see this as odd.  Or is there
another better method of checking user data when accessing user space
buffers?

other than a minor bug that could hit if there was more pci_devinfo's in
the list than pci_numdevs (which should never happen, but will prevent a
NULL deref), I didn't see anything wrong with -l.

> code needs some fairly thorough review and cleanup before we should reduce
> the level of privilege required to use the device (note that we make it
> world readable by default, so changes in the semantics of read permissions

> will affect all users in the system).  Could you do that cleanup in the
> first pass, then revisit the permissions change?

sure, no problem.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030616184204.GL73854>