ports/188278: libpciaccess is broken for non-x86 architectures

[Julio Merino]

>Number:         188278
>Category:       ports
>Synopsis:       libpciaccess is broken for non-x86 architectures
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 05 03:30:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator:     Julio Merino
>Release:        FreeBSD 11.0-CURRENT powerpc
>Organization:
>Environment:
System: FreeBSD mastodon.meroh.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264032: Thu Apr 3 01:32:06 EDT 2014 jmmv at mastodon.meroh.net:/usr/obj/home/jmmv/os/freebsd/base/head/sys/GENERIC64 powerpc


	
>Description:
	In:

	    http://lists.freebsd.org/pipermail/freebsd-ppc/2014-April/006924.html

	I described a problem by which X.org cannot start on my PowerMac G5
	using an NVIDIA card.

	At first sight, the xf86-video-nv seems to be broken under powerpc64.
	However, after a bit more digging, things appear way more broken
	than that because libpciaccess has an undefined behavior on all
	non-x86 platforms.  This is why I'm filing this under ports and not
	under powerpc.

	Take a look at this stacktrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 51006400 (LWP 100425)]
0x00000000506557e4 in pci_io_read8 (handle=0x0, reg=10) at common_io.c:181
181         if (reg + 1 > handle->size)
(gdb) bt
#0  0x00000000506557e4 in pci_io_read8 (handle=0x0, reg=10) at common_io.c:181
#1  0x00000000516286a8 in stdReadST01 (hwp=0x510f2000) at vgaHW.c:212
#2  0x000000005162c61c in vgaHWSaveColormap (scrninfp=0x510e1400, save=0x510f2048) at vgaHW.c:1124
#3  0x000000005162c708 in vgaHWSave (scrninfp=0x510e1400, save=0x510f2048, flags=5) at vgaHW.c:1155
#4  0x00000000515bd734 in NVDACSave (pScrn=0x510e1400, vgaReg=0x510f2048, nvReg=0x510f1800, saveFonts=0) at nv_dac.c:311
#5  0x00000000515c4bdc in NVSave (pScrn=0x510e1400) at nv_driver.c:2662
#6  0x00000000515c4164 in NVScreenInit (scrnIndex=0, pScreen=0x510c7f00, argc=1, argv=0xffffffffffffdc18) at nv_driver.c:2430
#7  0x0000000010044b5c in AddScreen (pfnInit=@0x5160f778: 0x515c3f8c <NVScreenInit>, argc=1, argv=0xffffffffffffdc18) at dispatch.c:3797
#8  0x00000000100bfdf8 in InitOutput (pScreenInfo=0x10332b78 <screenInfo>, argc=1, argv=0xffffffffffffdc18) at xf86Init.c:834
#9  0x0000000010021be8 in main (argc=1, argv=0xffffffffffffdc18, envp=0xffffffffffffdc28) at main.c:203

	which obviously tells us why the X.org server is crashing: we are
	dereferencing a null pointer, and that null handle comes from the
	libpciaccess library.  The library is called on driver initialization
	to get a pointer to the PCI memory (open_legacy_io) and that call
	fails because of a missing implementation.  The code later happily
	stores a null pointer and uses it without care.  (First problem:
	nowhere in the code, the call to the open_legacy_io function below is
	checked for success.)

	The libpciaccess library has this gem:

static struct pci_io_handle *
pci_device_freebsd_open_legacy_io(struct pci_io_handle *ret,
    struct pci_device *dev, pciaddr_t base, pciaddr_t size)
{
#if defined(__i386__) || defined(__amd64__)
        ret->fd = open("/dev/io", O_RDWR | O_CLOEXEC);

        if (ret->fd < 0)
                return NULL;

        ret->base = base;
        ret->size = size;
        return ret;
#elif defined(PCI_MAGIC_IO_RANGE)
        ret->memory = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED,
            aperturefd, PCI_MAGIC_IO_RANGE + base);
        if (ret->memory == MAP_FAILED)
                return NULL;

        ret->base = base;
        ret->size = size;
        return ret;
#else
        return NULL;
#endif
}

	Which, as far as I can tell, is *completely* wrong because FreeBSD
	does not define PCI_MAGIC_IO_RANGE (can't find mentions of it neither
	in current nor stable/10) and thus the fallback for non-x86 platforms
	cannot ever work (not to mention that aperturefd is not handled at all
	in the freebsd_pci.c file).

	As it turns out, the offending function was modified in:

	    https://bugs.freedesktop.org/show_bug.cgi?id=63583

	to apparently support non-x86 platforms.  Yeah, right...

>How-To-Repeat:
	Attempt to start X on a non-x86 machine with the xf86-video-nv driver
	(or possibly any other driver).  See the server crash.

	I'm unsure why this is failing now given that I think this used to
	work fine a few months ago only.  Don't know what has changed.  Maybe
	the new Xorg is triggering this, but no idea.

>Fix:

	
>Release-Note:
>Audit-Trail:
>Unformatted: