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: <20191004075426.GA2819@lahna.fi.intel.com>
Date:   Fri, 4 Oct 2019 10:54:26 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Mario.Limonciello@...l.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

On Thu, Oct 03, 2019 at 02:41:11PM +0000, Mario.Limonciello@...l.com wrote:
> > -----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

OK, it clearly takes time to read them. I wonder if this includes
powering up the controller?

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?