Re: pciconf -lv - /dev/pci error

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 12/31/03

  • Next message: Dimitry Andric: "Re: pciconf -lv - /dev/pci error" 
    Date: Wed, 31 Dec 2003 14:02:04 -0500 (EST)
To: Robert Watson <rwatson@freebsd.org>

    On 31-Dec-2003 Robert Watson wrote:
    >
    > On Wed, 31 Dec 2003, William Michael Grim wrote:
    >
    >> I have 5.1-RELEASE installed on my system, and I've never needed to do a
    >> "pciconf -lv" to probe the system before. However, I tried doing it
    >> earlier today after logging in through SSH and doing "su -" to become
    >> superuser. I received this error:
    >>
    >> [root@snow 09:12:42 root]# pciconf -lv
    >> pciconf: /dev/pci: Operation not permitted
    >>
    >> [root@snow 09:15:41 root]# ls -l /dev/pci
    >> crw-r--r-- 1 root wheel 251, 0 Nov 2 05:09 /dev/pci
    >>
    >> So, as you can see, the permissions are correct. Perhaps I don't have
    >> something compiled into my kernel? I can attach a dmesg and kernel
    >> config if it's necessary.
    >
    > pciconf -lv appears to cause pciconf to open /dev/pci writable:
    >
    > 731 pciconf CALL open(0x8049a55,0x2,0)
    > 731 pciconf NAMI "/dev/pci"
    > 731 pciconf RET open -1 errno 13 Permission denied
    >
    > And, of course, it's not writable by non-root. The attached patch causes
    > pciconf to open /dev/pci read-only when listing devices (apply to
    > usr.sbin/pciconf/pciconf.c):
    >
    > Index: pciconf.c
    > ===================================================================
    > RCS file: /home/ncvs/src/usr.sbin/pciconf/pciconf.c,v
    > retrieving revision 1.19
    > diff -u -r1.19 pciconf.c
    > --- pciconf.c 20 Jun 2003 23:59:25 -0000 1.19
    > +++ pciconf.c 31 Dec 2003 17:58:45 -0000
    > @@ -165,7 +165,7 @@
    > if (verbose)
    > load_vendors();
    >
    > - fd = open(_PATH_DEVPCI, O_RDWR, 0);
    > + fd = open(_PATH_DEVPCI, O_RDONLY, 0);
    > if (fd < 0)
    > err(1, "%s", _PATH_DEVPCI);
    >
    >
    >
    > The pci_user.c code in the kernel requires that the caller hold a writable
    > file descriptor for most of the ioctls; the exception is PCIOCGETCONF,
    > which is the only ioctl pciconf's list_devs() uses. We can probably just
    > go ahead and commit this patch, I think. The reason a check was added to
    > the kernel pci ioctl code is that unaligned writes to /dev/pci can cause
    > faults, I believe...

    History is in PR 32677. I do think your patch might be ok if it
    only applies to the -l case. If so, then it should probably be committed
    and MFC'd (along with the kernel pci_user.c change) so the PR can be
    closed. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Dimitry Andric: "Re: pciconf -lv - /dev/pci error"

    Relevant Pages

    • Re: RT patch acceptance
      ... judge the complexity of a design for that type of system. ... claim that you cannot judge the complexity of a kernel modification. ... Since the patch in question doesn't actually need that information to ... nanokernel's API up to date with additions to Linux's API that RT people ...
      (Linux-Kernel)
    • [RFC] Making percpu module variables have their own memory.
      ... Someone using the -rt patch found that one of the tracing options caused ... 64K for every CPU to cover all the per_cpu variables used in the kernel ... static void wakeup_softirqd_prio ...
      (Linux-Kernel)
    • Re: This is [Re:] How to improve the quality of the kernel[?].
      ... The -mm kernel already implements what your proposed PTS would do. ... If patch have no TS ID, ... Thus i can apply for example lguest patches and implement and test new ... How many open source projects use Bugzilla and how many use the Debian BTS? ...
      (Linux-Kernel)
    • Re: Documentation - how to apply patches for various trees
      ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +and what new version the patch will change the source tree into. ...
      (Linux-Kernel)
    • [Full-Disclosure] Re: Buffer overflow prevention
      ... >> that may need executable stack). ... >> need to be compiled into anything but the kernel. ... the GRsec patch is a single option in the kernel ... way grsecurity gets a little to restrictive with things like restericting ...
      (Full-Disclosure)