fix pnpinfo on arch=amd64

[Alexander Best]

On Sun Oct 24 10, Garrett Cooper wrote:
> On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best <arundel at freebsd.org> wrote:
> > On Sat Oct 23 10, Garrett Cooper wrote:
> >> On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best <arundel at freebsd.org> wrote:
> >> > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any
> >> > longer on arch=amd64.
> >>
> >> 1. I had to modify the Makefile to get it to work.
> >
> > probably because you built pnpinfo from contrib/pnpinfo and not from
> > usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are
> > according to current practice. maybe the vendor Makefile shouldn't be modified
> > and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but
> > i don't really know.
> 
>     Ah... I was a bit confused as to why there was a copy hanging out
> in contrib, because it seems like it was imported primarily to FreeBSD
> in 2.2 (which contradicts the manpage as it states that it was
> imported in 7.2). I see it's over in DragonFly, but not in the other
> BSDs; it has a BSD license; doesn't denote any kind of proprietary
> info (leverages some of the FreeBSD isa(4) driver structures); doesn't
> have an external website for development; etc.
>     I was also a bit confused why this directory wasn't iterated over
> in usr.sbin, but it appears to be missing from SUBDIR in
> usr.sbin/Makefile (wonder how many others are missing and whether or
> not the tools / apps really have any value, but that's another top for
> another thread).
> 
> > also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not
> > sure is really needed.
> 
>     No, it's not used anymore (I looked over pnpinfo and the
> isa/machine headers).
> 
> >> 2. FWIW, I don't there's really much point in adding a check for only
> >> x86 architectures, if the tool is capable of more than that.
> >
> > yeah you're probably right. to be honest i know nothing about
> > "archs != i386|amd64". ;) so i just added the amd64 option, because i didn't
> > want to break pnpinfo on other platforms.
> 
>     Well, but there are other platforms, other than x86 that could
> benefit from using this tool (arm, mips, etc). There might be some
> bugs lurking in the code dealing with endianness, but that should be
> resolved first by enabling the tool for all platforms and fixing the
> cases one by one (unfortunately I don't have either architecture at my
> disposal, otherwise I'd test this out). I do have a Sparc64 pizza box
> that I could test this out on though later on this week... hmmm.
> 
> >> 3. Might as well close the file descriptor after opening it.
> >
> > right. expecially, because opening /dev/io (even in ro mode) is a huge security
> > issue. so better close it asap.
> >
> > of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to
> > work around the security issue. but since pnpinfo's job is to access hardware
> > directly i think opening /dev/io directly can be consideren ok.
> 
>     Well, right... but there's no reason to leak a filehandle until
> the program is finished :).
> 
> >> SIGBUS occurs because it doesn't have permission to write via outb.
> >> It's a shame that there isn't a more proper way to catch this SIGBUS
> >> fault minus adding a SIGBUS handler (but that might have other
> >> undesired side effects).
> >
> > well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper
> > io permissions.
> 
>     Yeah, and it's x86 specific. Kind of curious why there isn't a
> more generalized name for this API, but it appeared to be geared
> towards x86 (today, not so much according to LEGACY in io(4)).
>     FWIW, it also looks like the manpages are missing for those
> syscalls, even though they're referenced in io(4)...
> 
> $ man i386_get_ioperm
> No manual entry for i386_get_ioperm
> $ man i386_set_ioperm
> No manual entry for i386_set_ioperm

are you running amd64? me too. it appears these manual pages are only being installed
under i386. that's a bug imo. they should also be installed under amd64.

the manuals are in /usr/src/lib/libc/i386/sys/

> 
>     ... and I couldn't find anything in the syscall entry table for
> this syscall. I did a bit more poking and it looks like the Linux
> ioperm syscall is the only really publicly available means of
> accessing this functionality. I could be wrong though.

they are defined in /usr/src/sys/amd64/include/sysarch.h (for amd64) and
/usr/src/sys/i386/include/sysarch.h (for i386).

> Thanks,
> -Garrett

-- 
a13x