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: <332849ed8714496587251b6319a11b0b@AUSX13MPC105.AMER.DELL.COM>
Date:   Fri, 4 Oct 2019 14:05:46 +0000
From:   <Mario.Limonciello@...l.com>
To:     <yehezkelshb@...il.com>, <mika.westerberg@...ux.intel.com>
CC:     <linux-usb@...r.kernel.org>, <andreas.noever@...il.com>,
        <michael.jamet@...el.com>, <rajmohan.mani@...el.com>,
        <nicholas.johnson-opensource@...look.com.au>, <lukas@...ner.de>,
        <gregkh@...uxfoundation.org>, <stern@...land.harvard.edu>,
        <anthony.wong@...onical.com>, <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4

> 
> On Fri, Oct 4, 2019 at 11:19 AM Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> >
> > 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.
> 
> Makes sense to me. Userspace can learn the relevant IDs that their NVM format
> is
> known.
> 
> >
> > > 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).
> 
> Yes, fwupd already takes this into account, but the question here is how to
> handle cases that NVM is available but the format isn't known to
> userspace (yet).

Exactly.

> 
> >
> > 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.
> 
> It's not about finding the relevant image for upgrade (which must be searched
> for by looking in the DROM vendor/product values), but about the question if the
> NVM format is known to userspace and skip the parsing work if it's anyway going
> to fail.
> 
> So yes, I think exposing vendor ID (and maybe also product ID) can improve the
> situation.
> 

Currently at probe time everything comes from udev except for the bit indicating
running in "native" mode or not.  Just enough chunks of the NVM are read to determine
that (IE no reading up through DROM or jumping around).

If Christian's patch to export generation is accepted I think that we could move that check
to only read -native if generation < 3.

And if you export the hw_vendor_id and hw_product_id fields then that means USB4 devices
would require no reading from NVM at "probe" since we don't have to read a -native bit.

We would still of course read and analyze the NVM when it comes time to flash a new device
though.