linux-kernel - Re: Power Management with rootfs on SDMMC.

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: <alpine.LFD.2.00.0901031306150.3179@localhost.localdomain>
Date:	Sat, 3 Jan 2009 13:16:35 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Pavel Machek <pavel@...e.cz>, Andreas Mohr <andi@...as.de>,
	Sriram V <vshrirama@...il.com>,
	Pierre Ossman <drzeus-list@...eus.cx>,
	linux-kernel@...r.kernel.org
Subject: Re: Power Management with rootfs on SDMMC.

On Sat, 3 Jan 2009, Alan Cox wrote:

> > [Now, olympus uses VFAT and probably will not write to the filesystem
> > unless you take a picture... with mp3 player, I'd expect mtime to be
> > updated on the playlist files...]
> 
> Some of the MP3/OGG players (especially the bigger disk based ones) use
> the file system to store their own metadata so yes it makes a nasty mess.

Well, it goes both ways. You can make a nasty mess right now by suspending 
and simply not having a working computer when it comes back - all your 
work being lost.

At least with cameras and mp3 players you _can_ choose to just unmount 
them before suspending (and most distros would hopefully mount them with 
something like automount anyway?). In contrast, if your root (or /home) 
directory is on a SD card, and that card is over USB rather than some IDE 
controller, you're basically screwed.

Yes, distros can set the /sys/bus/usb/devices/.../power/persist thing for 
important filesystems automatically, and I'm sure there are magic udev 
rules that could be written (and perhaps even exist). The likelihood that 
they actually get things right is pretty low, though. So I suspect we'd be 
much better off having sane defaults in the kernel instead.

And yes, the "sane defaults" may well be that FATFS does _not_ make the 
media be persistent. 

Think "door lock" commands (aka "prevent/allow medium removal"). This is 
really not that very different. Some filesystems are so important that the 
user messing with them is deadly anyway - so we should "lock" them and 
consider them persistent - and if the user does something bad, there was 
really never any good solution for it. Other filesystems we're better off 
just letting the user rip out, because we can be reasonably expected to 
handle it gracefully.

So it boils down to the fact that if you have something like / or /home 
mounted, we really _cannot_ do any better than "assume the user doesn't 
screw us up".

A per-filesystem callback to re-verify at resume might be a good idea, but 
a lot of filesystems cannot reasonably do a lot of verification.

			Linus
--
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/