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: <06a04bff94494da99c5359a7fb645d19@AUSX13MPC105.AMER.DELL.COM>
Date:   Thu, 3 Oct 2019 14:41:11 +0000
From:   <Mario.Limonciello@...l.com>
To:     <mika.westerberg@...ux.intel.com>
CC:     <yehezkelshb@...il.com>, <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

> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> Sent: Thursday, October 3, 2019 3:00 AM
> To: Limonciello, Mario
> Cc: yehezkelshb@...il.com; 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
> 
> 
> [EXTERNAL EMAIL]
> 
> On Wed, Oct 02, 2019 at 04:00:55PM +0000, Mario.Limonciello@...l.com wrote:
> > > It's not even "same location - another meaning", the vendor ID comes from
> the
> > > DROM section, so it takes a few internal jumps inside the NVM to find the
> > > location. One of the "pointers" or section headers will be broken for sure.
> > >
> > > And after this, we need to find the NVM in LVFS and it has to pass validation
> in
> > > a few other locations. The chances are so low that I'd think it isn't worth
> > > worrying about it.
> >
> > And now I remember why the back of my mind was having this thought of
> wanting
> > sysfs attribute in the first place.  The multiple jumps means that a lot more of
> the
> > NVM has to be dumped to get that data, which slows down fwupd startup
> significantly.
> 
> IIRC currently fwupd does two reads of total 128 bytes from the active
> NVM. Is that really slowing down fwupd startup significantly?

Yeah, I timed it with fwupd.  Here's the averages:

Without doing the reads to jump to this it's 0:00.06 seconds to probe a tree of
Host controller and dock plugged in.

With doing the reads and just host controller:
0:04.40 seconds

With doing the reads and host controller and dock plugged in:
0:10.73 seconds

> 
> > However the kernel has this information handy already from thunderbolt init
> and can
> > easily export an attribute which can then come from udev with no startup
> penalty.
> 
> Indeed kernel has this information but I'm bit hesitant to add new
> attributes if that same information is already available to the
> userspace rather easily. IMHO we can always add this to the driver later
> as we learn new NVM formats that require more parsing from fwupd side
> slowing it down considerably.

I guess we can wait until new NVM formats come and cross the bridge at that point.
If we encounter a new NVM format that kernel recognizes but old fwupd doesn't it
will reject it anyway (just the error won't be super clear why).