linux-kernel - Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <476AB3B5.9080808@redhat.com>
Date:	Thu, 20 Dec 2007 13:25:57 -0500
From:	Tony Camuso <tcamuso@...hat.com>
To:	Greg KH <gregkh@...e.de>
CC:	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

Greg KH wrote:

> Why haven't we gotten reports about this before if this is a common
> problem?
> 
> And why hasn't the vendor fixed the bios on these to work properly?
>
I can't really answer either of these questions. All I know is the
problem exists, and we need to deal with it.

That's why the unreachable_devices() routine exists in the first place.

But that routine is limited to only the first 16 buses on segment-0.
You would like to think that hardware designers would confine legacy
hardware, or problematic hardware, to that area, but they don't.

As I said before, expanding that routine to cover more buses would
adversely impact mmconfig pci access, since the mmconfig access
code does a lookup of that bitmap for every request. I don't think
we want that bitmap and the accompanying in-line lookup to increase
enough to encompass the pci configuration of some of these larger
systems.

> Do you have a pointer to this blacklist anywhere so that everyone can
> benifit from this knowledge?
>

Appended below is a code snippet embedded in the RHEL version of mmconfig.c,
for both i386 and x86_64. It does not encompass all the systems that have
(or will have) problems with mmconf. Only HP platforms are listed, but I
believe there are others.

The reason the HP platforms got caught is they put these devices beyond
bus 16, where they would have been trapped, and the problem would have
been avoided.

static int __devinit disable_mmconf(struct dmi_system_id *d)
{
         pci_probe &= ~PCI_PROBE_MMCONF;
         printk(KERN_INFO "%s detected: disabling PCI MMCONFIG\n", d->ident);
         return 0;
}


/*
  * Systems which cannot use PCI MMCONFIG at this time...
  */
static struct dmi_system_id __devinitdata nommconf_dmi_table[] = {
         {
                 .callback = disable_mmconf,
                 .ident = "HP xw9300 Workstation",
                 .matches = {
                         DMI_MATCH(DMI_PRODUCT_NAME, "HP xw9300 Workstation"),
                 },
         },
         {
                 .callback = disable_mmconf,
                 .ident = "HP xw9400 Workstation",
                 .matches = {
                         DMI_MATCH(DMI_PRODUCT_NAME, "HP xw9400 Workstation"),
                 },
         },
         {
                 .callback = disable_mmconf,
                 .ident = "ProLiant DL585 G2",
                 .matches = {
                         DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL585 G2"),
                 },
         },
         {
                 .callback = disable_mmconf,
                 .ident = "HP Compaq dc5700 Microtower",
                 .matches = {
                         DMI_MATCH(DMI_PRODUCT_NAME,
                                 "HP Compaq dc5700 Microtower"),
                 },
         },

         {}
};

>> The one device we know about that throws exceptions is the 830M/MG
>> graphics chip. This chip passes the read-compare test, so the code
>> merrily advances to bus sizing. When the bus sizing code writes the
>> BAR at offset 0x18 in this device, the system hangs.
> 
> So it doesn't work at all, with or without this patch?  Does the vendor
> know about this?
> 
> thanks,
> 
> greg k-h

I have talked to intel about this, but they haven't gotten back to me.

All I know at this point is that a mmconf write to the BAR at offset 0x18
of this device hangs the system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/