linux-ext4 - Re: Exciting :-( adventures in metadata checksumming

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:	Fri, 3 Aug 2012 19:49:02 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Exciting :-( adventures in metadata checksumming

On Fri, Aug 03, 2012 at 03:55:08PM -0400, George Spelvin wrote:
> A considerable amount of time trying to run "debuild -b -us -uc" and
> "debian/rules binary" elapses.  I am unable to build a .deb.  Damn.
> And debian/rules files are a complete maze of layers of helper
> utilities that I have no idea how to debug. :-(

This is what I normally do when I build debian packages.  I normally
will create a tarball using the gen-tarball script in the util
directory (which is a generated file, so that means you need to run
"configure ; sh -vx util/gen-tarball" if you are using a freshly
checked out git tree.  In theory you should be able to do a debian
build out of the git tree, but it's not what I normally do....

So normally, I do something like this:

cp build/util/e2fsprogs-1.42.5.tar.gz /u1/debian-bld/e2fsprogs_1.42.5.orig.tar.gz
#
# optional "schroot -c sid" if you're building for unstable in a debian chroot
# goes here
#
cd /u1/debian-bld
tar xvfz e2fsprogs_1.42.5.orig.tar.gz
cd e2fsprogs-1.42.5
./debian/rules
dpkg-buildpackage -rfakeroot

The "./debian/rules" line generates various files in debian based on
your build environment.  It's there so that the build tree can work on
older verisions of Debian/Ubuntu LTS as well as the very latest
versions of debian.  (i.e., it figures out whether or not we need to
build the uuid and blkid libraries, or whether we are on a system
where the responsibility of those libraries have been moved to
util-linux-ng.  It figures out whether you are on a new enough version
of Debian/Ubuntu to require the new multi-arch support.)

> Eek!  Doubleplusungood.  Repeating the e2fsck, the errors seem to be
> consistent.  For the record I did *nothing* to the file system between
> the two runs except used debugfs in read-only mode to ncheck the inodes
> that generated complaints.

Hmm... I can't replicate the problem using a cleanly created file
system, copying a huge number of files to it, and then enabling
metadata_csum using tune2fs, and then running e2fsck -f on the device
again.

The fact that you are were seeing multiple cases of file system
corruption before you started using metadata_csum makes me very
suspicious, though.  I'm not sure whether you have a hardware problem,
or a bug in the md layer, or something else but the fact you were
seeing what looks like metadata corruption problems even before
turning on metadata_csum doesn't make it surprising that you might be
having the checksum failures reported!

							- 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