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: <20241011233953.GJ21877@frogsfrogsfrogs>
Date: Fri, 11 Oct 2024 16:39:53 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	linux-pm <linux-pm@...r.kernel.org>, linux-kernel@...r.kernel.org,
	Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
	Russ Weight <russ.weight@...ux.dev>,
	Danilo Krummrich <dakr@...hat.com>
Subject: Re: Root filesystem read access for firmware load during hibernation
 image writing

On Fri, Oct 11, 2024 at 04:11:49PM -0700, Luis Chamberlain wrote:
> On Sat, Oct 05, 2024 at 03:16:27PM +0200, Maciej S. Szmigiero wrote:
> > The issue below still happens on kernel version 6.11.1.
> > 
> > Created a kernel bugzilla entry for it:
> > https://bugzilla.kernel.org/show_bug.cgi?id=219353
> > 
> > It would be nice to at least know whether the filesystem read access supposed is
> > to be working normally at PMSG_THAW hibernation stage to assign the issue accordingly.
> 
> No, there are races possible if you trigger IO to a fs before a suspend
> is going on. If you have *more* IO ongoing, then you are likely to stall
> suspend and not be able to recover.
> 
> > CC: request_firmware() maintainers
> 
> If IO is ongoing suspend is broken today because of the kthread freezer
> which puts kthreads which should sleep idle, but if IO is ongoing we
> can stall. This is work which we've been working to remove for years and
> after its removal we can gracefully freeze filesystems [0] [1]
> properly on suspend.
> 
> Other than that, obviously upon resume we want firmware to be present,
> and to prevent races on resume we have a firmware cache. So on suspend
> we cache used firmware so its available in cache on resume. See
> device_cache_fw_images().

Reads are generally supposed to succeed on a suspended system but if the
read causes a write (e.g. atime update) they can block just like a write
would.  So in the end you probably have to cache the firmware blobs in a
tmpfs or something like that.

> So.. we just now gotta respin the latest effort. I had stopped because
> I know Darrick had some changes which he needed to get in sooner but

Do you remember what changes those were?  I don't. :(

--D

> since this is low hanging fruit I never got around to it. So someone
> just needs to respin the series.
> 
> [0] https://lwn.net/Articles/752588/
> [1] https://lwn.net/Articles/935602/
> 
>   Luis