linux-kernel - Re: Root filesystem read access for firmware load during hibernation image writing

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: <fac3f1f0-f76e-45bd-902c-60c395afcc16@maciej.szmigiero.name>
Date: Sun, 6 Oct 2024 16:02:45 +0200
From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To: Pavel Machek <pavel@....cz>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>,
 linux-pm <linux-pm@...r.kernel.org>, linux-kernel@...r.kernel.org,
 Ping-Ke Shih <pkshih@...ltek.com>,
 linux-wireless <linux-wireless@...r.kernel.org>,
 Marcel Holtmann <marcel@...tmann.org>,
 Luiz Augusto von Dentz <luiz.dentz@...il.com>,
 linux-bluetooth@...r.kernel.org
Subject: Re: Root filesystem read access for firmware load during hibernation
 image writing

On 5.10.2024 19:40, Pavel Machek wrote:
> Hi!
> 
>> In my case, a USB device (RTL8821CU) gets reset at that stage due to
>> commit 04b8c8143d46 ("btusb: fix Realtek suspend/resume") and so it tries
>> to request_firmware() from the root filesystem after that thaw/reset,
>> when the hibernation image is being written.
>>
>> It usually succeeds, however often it deadlocks somewhere in Btrfs code
>> resulting in the system failing to power off after writing the hibernate
>> image:
>> power_off() calls dpm_suspend_start(), which calls dpm_prepare(), which
>> waits for device probe to finish.
>>
>> And device probe is stuck forever trying to load that USB stick firmware
>> from the filesystem - so in the end the system never powers off during
>> (after) hibernation.
>>
>> That's why I wonder whether this firmware load is supposed to work correctly
>> during that hibernation state and so the system may be hitting some kind of
>> a swsusp/btrfs/block layer race condition.
>>
>> Or, alternatively, maybe  reading files is not supported at this point and
>> so this is really a btrtl/rtw88 bug?
> 
> I'd say not supported at this point. Reading file may still read to
> atime update, etc, and we can't really can't support that easily.

Thanks for this clarification.

I've dropped btrfs folks from the CC list since this isn't a btrfs issue
after all and added rtw88/btrtl maintainers instead.

> Suggestion is to keep firmware cached in memory, or at least cache it
> in memory when hibernation begins.

Since a WiFi/BT NIC is hardly useful for hibernation snapshot writing
operation it seems that an easier option would be to simply return
something like -EPROBE_DEFER from both rtw88 and btrtl probe callbacks
during PMSG_THAW hibernation stage.
That -EPROBE_DEFER will hopefully handle the unlikely case that the
hibernation snapshot writing fails or someone is running a
HIBERNATION_TEST_RESUME.

In turn, the easiest trigger for this would be the "in_suspend"
variable being set, however this would require EXPORTing it - it looks
like system_entering_hibernation() only covers the case when the
system is hibernating using platform hibernation support.

I will see whether this workaround works for me, if someone wants
to implement the "firmware caching" approach instead then feel
free to do so.

By the way, I don't see any reason why other USB devices that load
firmware at their probe time can't be affected too since that
lock_device_hotplug() call in hibernate() seems to only prevent
CPU/RAM/ACPI hotplug, not USB hotplug.

So if such USB device happens to get reset during hibernation time
(for example from hub EMI) it would suffer the same issue.

> BR,
> 										Pavel
> 										

Thanks,
Maciej