linux-ext4 - Re: [PATCH 19/22] jbd2: Checksum revocation blocks

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] [day] [month] [year] [list]

Date:	Mon, 12 Dec 2011 10:39:35 -0500
From:	Ted Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <djwong@...ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 19/22] jbd2: Checksum revocation blocks

On Mon, Nov 28, 2011 at 03:28:29PM -0800, Darrick J. Wong wrote:
> +				/*
> +				 * Ignoring corrupt revoke blocks is safe
> +				 * because at worst it results in unnecessary
> +				 * writes during recovery.
> +				 */

This is *not* true.  The reason why we have revoke blocks is because
we have to handle the case where a metadata block (which is journaled)
is released, and then the block is reused as a data block.  If we then
replay the block, the "unnecessary write" will result the potential
corruption of a data block.

So if we lose a revoke block, it's not possible to safely replay *any*
part of the journal.  E2fsck might be able to do something about it by
saving the old copy of all blocks written during the journal replay if
it detects this case, and then alerting the system administrator that
a particular data file may have gotten corrupted.  But it's going to
be really messy...

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html