linux-kernel - Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

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] [day] [month] [year] [list]

Message-ID: <20170811151359.GP2369@lahna.fi.intel.com>
Date:   Fri, 11 Aug 2017 18:13:59 +0300
From:   "mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>
To:     "Jamet, Michael" <michael.jamet@...el.com>
Cc:     "Mario.Limonciello@...l.com" <Mario.Limonciello@...l.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "andreas.noever@...il.com" <andreas.noever@...il.com>,
        "Bernat, Yehezkel" <yehezkel.bernat@...el.com>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "Levy, Amir (Jer)" <amir.jer.levy@...el.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "Jared.Dominguez@...l.com" <Jared.Dominguez@...l.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware
 upgrade

On Thu, May 25, 2017 at 03:03:07PM +0300, mika.westerberg@...ux.intel.com wrote:
> On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerberg@...ux.intel.com wrote:
> > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerberg@...ux.intel.com wrote:
> > > On Wed, May 24, 2017 at 07:32:45PM +0000, Jamet, Michael wrote:
> > > > I talked to our BIOS expert today. Here is his advice to debugging further:
> > > > 
> > > > It looks like something may have been wrong from system (BIOS, FW, others...) perspective.
> > > > On reboot need to enter EFI shell and check resources of 
> > > > pci 0000:01:00.0: bridge.
> > > > At the EFI shell, this bridge MUST be either configured or absent.
> > > > 
> > > > I would start this way, once we have this info, we may circle back to
> > > > him and look into next debugging step.
> > > 
> > > Thanks, I'll try this today.
> > 
> > 
> > This is the contents dumped directly from EFI shell when a device is
> > connected. It seems that the vendor_id/device_id is 0xffff but the rest
> > of the config seems to be present (although not fully configured):
> > 
> >   PCI Segment 00 Bus 01 Device 00 Func 00 [EFI 0001000000]
> >   00000000: FF FF FF FF 00 00 10 00-00 00 04 06 00 00 01 00  *................*
> >   00000010: 00 00 00 00 00 00 00 00-00 00 00 00 01 01 00 00  *................*
> >   00000020: 00 00 00 00 01 00 01 00-00 00 00 00 00 00 00 00  *................*
> >   00000030: 00 00 00 00 80 00 00 00-00 00 00 00 FF 01 00 00  *................*
> >   00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> >   00000050: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> >   00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> >   00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> >   00000080: 01 88 C3 FF 08 00 00 00-05 AC 80 00 00 00 00 00  *................*
> >   00000090: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> >   000000A0: 00 00 00 00 00 00 00 00-00 00 00 00 0D C0 00 00  *................*
> >   000000B0: 22 22 11 11 00 00 00 00-00 00 00 00 00 00 00 00  *""..............*
> >   000000C0: 10 00 52 00 20 80 E8 07-10 28 10 00 43 5C 45 00  *..R. ....(..C\E.*
> >   000000D0: 00 00 23 10 00 00 00 00-00 00 00 00 00 00 00 00  *..#.............*
> >   000000E0: 00 00 00 00 00 08 00 00-00 00 00 00 0E 00 00 00  *................*
> >   000000F0: 03 00 1E 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
> > 
> > I wonder how Linux manages to find the device if vendor_id/device_id
> > reads 0xffff?
> 
> OK, here's the explanation.
> 
> When Linux initializes ACPI (this happens before PCI initial scan), it
> calls acpi_initialize_objects(). This in turn causes _INI methods of
> devices to be executed. Now, the _SB.PCI0._INI() ends up calling
> \_GPE.TINI() which executes Thunderbolt specific OSUP() method. Purpose
> of this method is to overwrite vendor_id/device_id to the correct values
> with the assumption that the OS has already done the initial PCI scan.
> 
> In case of Linux this is not true and that is the reason the upstream
> port is found half-initialized leading to the failure.

We finally found out what the problem is. In short the above
_SB.PCI0._INI() (and OSUP()) gets called correctly but this is only
part of the story. When OSUP() is called it rewrites the
vendor/deviceid and then signals that certain GPE handler can continue
to trigger the SMI handler which should enumerate all the devices
before PCI scan happens.

In Linux we enable GPEs later, after PCI scan so we only see partially
configured PCI bridges (as the SMI handler has not run yet).

Rafael's patch series here:

https://lkml.org/lkml/2017/8/9/1017

addresses this so that we enable GPEs earlier among other things.