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

Message-ID: <e8face149c224715ab7f6ea15191f181@ausx13mpc120.AMER.DELL.COM>
Date:   Mon, 22 May 2017 20:07:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <mika.westerberg@...ux.intel.com>
Cc:     <gregkh@...uxfoundation.org>, <andreas.noever@...il.com>,
        <michael.jamet@...el.com>, <yehezkel.bernat@...el.com>,
        <lukas@...ner.de>, <amir.jer.levy@...el.com>, <luto@...nel.org>,
        <Jared.Dominguez@...l.com>, <andriy.shevchenko@...ux.intel.com>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware
 upgrade

> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@...ux.intel.com]
> Sent: Monday, May 22, 2017 6:37 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: gregkh@...uxfoundation.org; andreas.noever@...il.com;
> michael.jamet@...el.com; yehezkel.bernat@...el.com; lukas@...ner.de;
> amir.jer.levy@...el.com; luto@...nel.org; Dominguez, Jared
> <Jared_Dominguez@...L.com>; andriy.shevchenko@...ux.intel.com; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade
> 
> On Sat, May 20, 2017 at 11:24:12AM +0300, Mika Westerberg wrote:
> > On Fri, May 19, 2017 at 05:54:37PM +0000, Mario.Limonciello@...l.com wrote:
> > > >
> > > > It happens occasionally when you reboot the machine when a device is
> > > > connected but seems to be dependent on the BIOS version. Since it is the
> > > > BIOS who is supposed to enumerated these devices, I suspect that it is
> > > > either problem in BIOS or our PCI enumeration code does something wrong.
> > > >
> > >
> > > I'm fairly certain it's an issue somewhere with Linux PCI enumeration.  I took
> > > the exact same HW and switched it out the SSD to one w/ Win10 1607.
> > > I set the dock and cable to "always allow" in TBT settings applet.
> > >
> > > I don't reproduce any problems with enumeration with the dock plugged in
> > > on cold boot.  All the devices hanging off the bridge show up properly.
> >
> > You mean in Windows you don't reproduce the problem, right? Even when
> > you reboot the machine with devices connected.
> >
> > I tried on Intel Skull Canyon NUC so that I disabled the thunderbolt
> > driver and after reboot (warm) I can see the PCI scan error about bus
> > being partially hidden behind a bridge.
> >
> > When this happens PCIe ports of the thunderbolt device/host seem to be
> > unconfigured and Linux then decides to reconfigure them which leads to
> > the problem. When it works we get ACPI hotplug event to the PCIe root
> > port and the PCIe upstream/downstream ports are properly configured by
> > the BIOS.
> >
> > I guess Windows does something differently here than what we do when PCI
> > devices are enumerated.
> 
> We discussed this with our BIOS/firmware people and there was a firmware
> bug that caused many issues around hotplug and reboot flows. Is is
> possible for you to try with the latest BIOS and see if the issue
> reproduces (or are you already running the latest)?

I was 1 version behind, but I double checked with the latest version (1.1.15)
and the same behavior exists on Linux (still works properly on Win10).

If you have some more details about what the FW guys changed, I can check
with my Dell FW team if they've picked up the same fix.  I'm guessing it's not
the same problem though considering it works properly on Win10?