linux-kernel - Re: [PATCH] Revert "usb: renesas-xhci: Fix handling of unknown ROM state"

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: <YPhRu/DWbs58hgvq@epycbox.lan>
Date:   Wed, 21 Jul 2021 09:56:27 -0700
From:   Moritz Fischer <mdf@...nel.org>
To:     Matthias Schiffer <mschiffer@...verse-factory.net>
Cc:     Moritz Fischer <mdf@...nel.org>, linux-kernel@...r.kernel.org,
        gabriel.kh.huang@...-na.com, moritzf@...gle.com,
        stable@...r.kernel.org, Mathias Nyman <mathias.nyman@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vinod Koul <vkoul@...nel.org>,
        Justin Forbes <jmforbes@...uxtx.org>, linux-usb@...r.kernel.org
Subject: Re: [PATCH] Revert "usb: renesas-xhci: Fix handling of unknown ROM
 state"

On Wed, Jul 21, 2021 at 05:28:21PM +0200, Matthias Schiffer wrote:
> On 7/19/21 9:05 AM, Moritz Fischer wrote:
> > This reverts commit d143825baf15f204dac60acdf95e428182aa3374.
> > 
> > Justin reports some of his systems now fail as result of this commit:
> > 
> >   xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
> >   xhci_hcd 0000:04:00.0: request_firmware failed: -2
> >   xhci_hcd: probe of 0000:04:00.0 failed with error -2
> > 
> > The revert brings back the original issue the commit tried to solve but
> > at least unbreaks existing systems relying on previous behavior.
> > 
> > Cc: stable@...r.kernel.org
> > Cc: Mathias Nyman <mathias.nyman@...el.com>
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: Vinod Koul <vkoul@...nel.org>
> > Cc: Justin Forbes <jmforbes@...uxtx.org>
> > Reported-by: Justin Forbes <jmforbes@...uxtx.org>
> > Signed-off-by: Moritz Fischer <mdf@...nel.org>
> > ---
> > 
> > Justin,
> > 
> > would you be able to help out testing follow up patches to this?
> > 
> > I don't have a machine to test your use-case and mine definitly requires
> > a firmware load on RENESAS_ROM_STATUS_NO_RESULT.
> > 
> > Thanks
> > - Moritz
> 
> 
> Hi Moritz,
> 
> as an additional data point, here's the behaviour of my system, a Thinkpad
> T14 AMD with:

Thanks!
> 
> 06:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0
> Host Controller [1912:0015] (rev 02)
> 
> - On Kernel 5.13.1, no firmware: USB controller resets in an endless loop
> when the system is running from battery
> - On Kernel 5.13.4, no firmware: USB controller probe fails with the
> mentioned firmware load error
> - On Kernel 5.13.4, with renesas_usb_fw.mem: everything is working fine, the
> reset issue is gone
> 
> So it seems to me that requiring a firmware is generally the correct driver
> behaviour for this hardware. The firmware I found in the Arch User
> Repository [1] unfortunately has a very restrictive license...

Yeah, the chip definitely needs the firmware. It can either initialize
from external ROM or runtime loaded firmware.

I think the problem really lies in how the current (and reverted) code
detects the need for firmware loading.

The current code looks at two indicators:
- Is there an external ROM and if so, did somebody try to program the
  external ROM and succeed? (renesas_check_rom_state)
- Did somebody try to runtime-load firmware, and if so did they succeed?
  (renesas_fw_check_running, after the early return)

The first one (and resulting early return) does *not* tell you whether
the controller actually has firwmare. That's what breaks my systems.

The second one is only really useful *if* we also check that FW_DOWNLOAD
was locked.

Neither of the above captures the case where you actually have an
external ROM that is programmed with proper firmware and caused the chip
to be loaded with said firmware.

Now before the patch that was reverted, since nobody tried to program
the ROM, it feel through to the "do nothing" in this case -- which
worked since it configured itself from external ROM.

Now how do we properly determine we do or don't need firwmare?

Looking at the datasheet I see two options.
- The version register? I need to investigate what that resets to with
  an unprogrammed/corrupted ROM. If that reliably gives a detectable value
  this could be used as an indicator.
  
- The USBSTS register according to the datasheet will report an error
  through the HCE bit:
  "If both uDP720201 and uDP720202 detect no correct firmware in Serial
  ROM, this flag will be set"

I'll put up an RFC in the next couple of days ...

- Moritz