linux-ext4 - Re: [PATCH 00/25] e2fsprogs Summer 2014 patchbomb, part 5.2

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, 9 Sep 2014 16:53:16 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 00/25] e2fsprogs Summer 2014 patchbomb, part 5.2

On Sep 8, 2014, at 5:11 PM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
> Patch 1 introduces journal_csum v3 to fix numerous journal block tag
> size handling bugs when metadata_csum+journal_checksum are turned on.
> The test of 64bitness should not rely on guessing the tag size when it
> could simply query the feature flags, since it was guessing
> incorrectly.  Furthermore, the journal_csum v2 structure had memory
> access alignment issues.  Just replace this all with a 16-byte tag
> with everything in it; the overhead for checksums is no more than
> 0.1%.

It's really too bad that we are introducing a new journal checksum
feature, when the current journal checksum implementation is
essentially unusable.  Any minor corruption in one transaction block
that has following un-checkpointed transactions will almost certainly
result in _more_ corruption of the filesystem rather than less, due
to all of the *committed* but uncheckpointed blocks being discarded
from the journal.  This would also result in a silent rollback of
filesystem state and loss of user data if running with data=journal.

As a result, there is no practical value (IMHO) to enabling this
feature at all currently.

We've discussed in the past that having per-block checksums is
necessary in order to fix this, so that only corrupt blocks in the
journal are skipped during replay, and may not result in any visible
filesystem corruption if the blocks are overwritten later during
replay.  Otherwise, this will itself result in yet a new block tag
format and journal checksum feature.

Is there any chance you could take a look at implementing this as
part of journal_checksum_v3 instead of fixing the current bugs only
to have a "correctly working" but not usable feature?

Cheers, Andreas

> NOTE: The test "j_corrupt_journal_block" in patch 21 ensures that
> e2fsck will replay everything but the corrupt block, and then proceeds
> with the fsck to fix up whatever might be broken.  You can decompress
> the image.gz and try to mount it to verify that it's unmountable (and
> hence requires e2fsck to be run).
> 
> Patches 23-25 implement v2 of the e2fsck readahead functionality,
> which promises to reduce fsck runtime by 10-30%.  You might want to
> read the report: http://marc.info/?l=linux-ext4&m=140755433701165&w=2
> ("e2fsck readahead speedup performance report") for all the juicy
> details!
> 
> I've tested these e2fsprogs changes against the -next branch as of
> 8/29.  The patches have been tested against the 'make check' suite and
> some amount of e2fuzz testing.
> 
> Comments and questions are, as always, welcome.
> 
> --D
> --
> 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

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)