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]
Date:   Thu, 26 Aug 2021 13:55:54 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mathias Nyman <mathias.nyman@...el.com>,
        Moritz Fischer <mdf@...nel.org>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: renesas-xhci: Prefer firmware loading on unknown ROM state

On Thu, 26 Aug 2021 13:50:13 +0200,
Greg Kroah-Hartman wrote:
> 
> On Thu, Aug 19, 2021 at 01:34:27PM +0200, Takashi Iwai wrote:
> > The recent attempt to handle an unknown ROM state in the commit
> > d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state")
> > resulted in a regression and reverted later by the commit 44cf53602f5a
> > ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"").
> > The problem of the former fix was that it treated the failure of
> > firmware loading as a fatal error.  Since the firmware files aren't
> > included in the standard linux-firmware tree, most users don't have
> > them, hence they got the non-working system after that.  The revert
> > fixed the regression, but also it didn't make the firmware loading
> > triggered even on the devices that do need it.  So we need still a fix
> > for them.
> > 
> > This is another attempt to handle the unknown ROM state.  Like the
> > previous fix, this also tries to load the firmware when ROM shows
> > unknown state.  In this patch, however, the failure of a firmware
> > loading (such as a missing firmware file) isn't handled as a fatal
> > error any longer when ROM has been already detected, but it falls back
> > to the ROM mode like before.  The error is returned only when no ROM
> > is detected and the firmware loading failed.
> > 
> > Along with it, for simplifying the code flow, the detection and the
> > check of ROM is factored out from renesas_fw_check_running() and done
> > in the caller side, renesas_xhci_check_request_fw().  It avoids the
> > redundant ROM checks.
> > 
> > The patch was tested on Lenovo Thinkpad T14 gen (BIOS 1.34).  Also it
> > was confirmed that no regression is seen on another Thinkpad T14
> > machine that has worked without the patch, too.
> > 
> > Fixes: 44cf53602f5a ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"")
> > BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1189207
> > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > ---
> >  drivers/usb/host/xhci-pci-renesas.c | 35 +++++++++++++++++++----------
> >  1 file changed, 23 insertions(+), 12 deletions(-)
> 
> This does not apply to my usb-linus branch, are you sure it is still
> needed in Linus's tree right now?

I guess we can postpone for 5.15.  The patch was written for the code
on linux-next, and I see there have been a few code clean up there.

But the patch itself could be applied to Linus tree with a slight
fuzz, so the stable backport should be fine.

If it's still not cleanly applicable, let me know.  I'll refresh the
patch for whatever preferred branch.


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ