linux-kernel - Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070206031744.GA11018@thunk.org>
Date:	Mon, 5 Feb 2007 22:17:44 -0500
From:	Theodore Tso <tytso@....edu>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	Christoph Hellwig <hch@....de>, akpm@...l.org, haveblue@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)

On Mon, Feb 05, 2007 at 09:40:08PM +0100, Jan Engelhardt wrote:
> 
> On Feb 5 2007 18:32, Christoph Hellwig wrote:
> >
> >in two recent discussions (file_list_lock scalability and remount r/o
> >on suspend) I stumbled over this emergency remount feature.  It's not
> >actually useful because it tries a potentially dangerous remount
> >despite writers still beeing in progress, which we can't get rid.
> 
> The current way is to remount things, and return -EROFS to any process
> that attempts to write(). Unless we want to kill processes to get rid of
> them [most likely we possibly won't], I am fine with how things are atm.
> So, what's the "dangerous" part, actually?

The dangerous part is that we change f->f_mode for all open files
without regard for whether there might be any writes underway at the
time.  This isn't *serious* although the results might be a little
strange and it might result in a confused return from write(2).  More
seriously, mark_files_ro() in super.c *only* changes f->f_mode and
doesn't deal with the possibility that the file might be mapped
read-write.  For filesystems that do delayed allocation, I'm not at
all convinced that an emergency read-only will result in the
filesystem doing anything at all sane, depending on what else the
filesystem might do when the filesystem is forced into read-only state.

> sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes
> go to disk \).

I agree it is useful, but if we're going to do it we really should do
it right.  We should have real revoke() functionality on file
descriptors, which revokes all of the mmap()'s (any attempt to write
into a previously read/write mmap will cause a SEGV) as well as
changing f_mode, and then use that to implement emergency read-only
remount.

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