linux-kernel - Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

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:	Wed, 20 Dec 2006 16:22:39 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andrew Morton <akpm@...l.org>
cc:	Martin Michlmayr <tbm@...ius.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Hugh Dickins <hugh@...itas.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrei Popa <andrei.popa@...eo.ro>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Florian Weimer <fw@...eb.enyo.de>,
	Marc Haber <mh+linux-kernel@...schlus.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Arnd Bergmann <arnd.bergmann@...ibm.com>,
	gordonfarquharson@...il.com,
	"Chen, Kenneth W" <kenneth.w.chen@...el.com>
Subject: Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content
 corruption on ext3)

On Wed, 20 Dec 2006, Andrew Morton wrote:
> > 
> > So with my change, afaik, we will just return EIO to the invalidate, and 
> > do the write.
> 
> The write's already been done by this stage.

Ok, but the end result is the same: you MUST NOT just "cancel" a write. It 
needs to be done, or the backing store must be actually de-allocated. You 
can't just say "get rid of it" and think that it can work. Exactly because 
of security issues, and just the simple fact that reading it back gets 
random contents.

So I repeat: clearing a dirty bit really only has two valid cases. Not 
three, like we used to have. And the "cancel" case cannot be conditional: 
either you can cancel it or you cannot. There's no

	if (cancel_dirty_page()) {
			..

sequence that makes sense that I can think of.

> > It really boils down to that same thing: if you remove the dirty bit, 
> > there is NO CONCEIVABLE GOOD THING YOU CAN DO EXCEPT FOR:
> >  - do the damn IO already ("clear_page_dirty_for_io()")
> >  - truncate the page (unmap and destroy it both from page cache AND from 
> >    any user-visible filesystem cases)
> 
> There's also redirty_page_for_writepage().

_dirtying_ a page makes sense in any situation. You can always dirty them. 
I'm just saying that you can't just mark them *clean*.

If your point was that the filesystem had better be able to take care of 
"redirty_page_for_writepage()", then yes, of course. But since it's the 
filesystem itself that does it, it had _better_ be able to take care of 
the situation it puts itself into.

			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/