fix pnpinfo on arch=amd64

[Garrett Cooper]

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

    ... 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.
Thanks,
-Garrett