linux-kernel - Re: [PATCH 1/1] suspend: delete sys

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:	Tue, 7 Jul 2015 11:03:20 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oneukum@...e.de>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Dave Chinner <david@...morbit.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Len Brown <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()

On Tue, 7 Jul 2015, Oliver Neukum wrote:

> > he (or she) pulls the storage device out of the system, moves it to another
> > system, makes changes (say removes the file written to by the process above,
> > so the blocks previously occupied by that file are now used for some metadata)
> > and moves the storage back to the suspended system.  The system is resumed
> > and the writing process continues writing possibly to the wrong blocks and
> > corrupts the filesystem.
> 
> That is a tough nut. But that's not a reason to make it worse.
> I'd say there's no reason not to use a secondary interface to
> suspend without syncing or to extend or introduce such an interface
> if the API is deficient.

Indeed, the problem Rafael outlined always exists whether or not the
kernel does a sync.  Even if no I/O is in progress when the system goes
to sleep, if the user moves a portable storage device with a mounted
filesystem to another computer and updates it before waking the system
up, corruption is highly likely.

In principle this could be solved by adding suspend/resume callbacks to
filesystems.  For example, the resume callback could verify that the
superblock had not been changed since the suspend occurred.  Or there 
could be some other simple way of determining that the filesystem had 
not been remounted and changed.

Either way, this is irrelevant to the question of whether the kernel 
should issue a sync when suspending.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/