linux-kernel - Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4

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: <20191004081951.GD2819@lahna.fi.intel.com>
Date:   Fri, 4 Oct 2019 11:19:51 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Yehezkel Bernat <yehezkelshb@...il.com>
Cc:     Mario Limonciello <Mario.Limonciello@...l.com>,
        linux-usb@...r.kernel.org,
        Andreas Noever <andreas.noever@...il.com>,
        Michael Jamet <michael.jamet@...el.com>,
        Rajmohan Mani <rajmohan.mani@...el.com>,
        nicholas.johnson-opensource@...look.com.au,
        Lukas Wunner <lukas@...ner.de>, gregkh@...uxfoundation.org,
        stern@...land.harvard.edu,
        Anthony Wong <anthony.wong@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4

On Fri, Oct 04, 2019 at 11:07:34AM +0300, Yehezkel Bernat wrote:
> > Also if you can get the hw_vendor_id and hw_product_id from the kernel
> > does that mean you don't need to do the two reads or you still need
> > those?
> 
> Are those the chip vendor or the OEM, in case they are different?

Those are the actual USB4 hardware maker values, directly from
ROUTER_CS_0 (p. 287 in the USB4 spec). This almost certainly differ from
the OEM values from DROM we currently expose.

> Thinking about it again, I'd guess it shouldn't matter much, if the chip is from
> Intel, the FW supports NVM upgrade, isn't it?

So the bottom line is that if the kernel thinks the router supports NVM
upgrade it exposes the nvm_active/nvm_non_active files etc. I think
fwupd uses this information to display user whether the device can be
upgraded or not (for example ICL cannot as the NVM is part of BIOS).

Exposing hw_vendor_id and hw_product_id may speed up fwupd because it
does not need to go over the active NVM to figure out whether the new
image is for the correct controller.