Date: Mon, 25 Oct 2010 21:22:12 +0000 From: Alexander Best <arundel@freebsd.org> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 Message-ID: <20101025212212.GB18193@freebsd.org> In-Reply-To: <AANLkTimbmoX%2BN8eNWJ4VtVerKTkVPuJgTAttsZsKL8tE@mail.gmail.com> References: <20101024002248.GA73346@freebsd.org> <AANLkTinzn1r3qn3d7MoVhZPNOo6OHDfF-0KVrLN%2BC516@mail.gmail.com> <20101024115712.GA61342@freebsd.org> <AANLkTimbmoX%2BN8eNWJ4VtVerKTkVPuJgTAttsZsKL8tE@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun Oct 24 10, Garrett Cooper wrote: > On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best <arundel@freebsd.org> wrote: > > On Sat Oct 23 10, Garrett Cooper wrote: > >> On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best <arundel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101025212212.GB18193>