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: <35ff02c7-8a76-730e-ddb9-f91634f5098b@tuxforce.de>
Date:   Wed, 21 Apr 2021 22:42:36 +0200
From:   Lukas Middendorf <kernel@...force.de>
To:     Luis Chamberlain <mcgrof@...nel.org>, rafael@...nel.org,
        gregkh@...uxfoundation.org, viro@...iv.linux.org.uk, jack@...e.cz,
        bvanassche@....org, jeyu@...nel.org, ebiederm@...ssion.com
Cc:     mchehab@...nel.org, keescook@...omium.org,
        linux-fsdevel@...r.kernel.org, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Lukas Middendorf <kernel@...force.de>
Subject: Re: [PATCH 2/2] fs/kernel_read_file: use
 usermodehelper_read_trylock() as a stop gap


On 17/04/2021 01:58, Luis Chamberlain wrote:
> The VFS lacks support to do automatic freeze / thaw of filesystems
> on the suspend / resume cycle. This can cause some issues, namely
> stalls when we have reads/writes during the suspend / resume cycle.
> 
> Although for module loading / kexec the probability of this happening
> is extremely low, maybe even impossible, its a known real issue with
> the request_firmare() API which it does direct fs read. For this reason
> only be chatty about the issue on the call used by the firmware API.
> 
> Lukas Middendorf has reported an easy situation to reproduce, which can
> be caused by questionably buggy drivers which call the request_firmware()
> API on resume.
> 
[snip]
> 
> The VFS fs freeze work fixes this issue, however it requires a bit
> more work, which may take a while to land upstream, and so for now
> this provides a simple stop-gap solution.
> 
> We can remove this stop-gap solution once the kernel gets VFS
> fs freeze / thaw support.
> 
> Reported-by: Lukas Middendorf <kernel@...force.de>
> Signed-off-by: Luis Chamberlain <mcgrof@...nel.org>

Tested-by: Lukas Middendorf <kernel@...force.de>


Works as advertised.

This prevents stalls on resume with buggy drivers (e.g. si2168) by 
totally blocking uncached request_firmware() on resume. Uncached 
request_firmware() will fail reliably (also in situations where it by 
accident worked previously without stalling).
If firmware caching has been set up properly before suspend (either 
through firmware_request_cache() or through request_firmware() outside 
of a suspend/resume situation), the call to request_firmware() will 
still work as expected on resume. This should not break properly 
behaving drivers.

A failing firmware load is definitely preferable (and easier to debug 
and fix in the respective drivers) compared to a stall on resume.

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ