linux-ext4 - Re: [BUG] e2fsprogs: e2fsck -b outputs checksum warnings

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, 31 Jan 2012 15:56:57 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Akira Fujita <a-fujita@...jp.nec.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [BUG] e2fsprogs: e2fsck -b outputs checksum warnings

On Tue, Jan 31, 2012 at 02:43:41PM -0600, Eric Sandeen wrote:
>         /*
>          * If recovery is from backup superblock, Clear _UNININT flags &
>          * reset bg_itable_unused to zero
>          */
> 
> This makes the group look like it is initialized and that all inodes
> are used.
> 
> Can someone remind me why we want to do this?

It's because the kernel don't update the backup block group
descriptors.  So there may very well be bitmaps that have since been
initialized and in use, and there may very well be inodes that have
been allocated that are not represented by the value of
bg_itable_unused in the backup bg descriptors.  And the inode iterator
functions will simply skip inodes that are marked as not in use;
indeed, that's one of the ways we speed up fsck times; by skipping
portions of the inode table that are not in use.  The problem is that
if the primary superblock and block group descriptors are corrupt, we
don't know which portions of the inode table are in use and which are
not.

This is also why the lazy itable init code is so important; if we're
going to skip zero'ing the inode table, then until the inode table
gets initialized, we are at risk of finding old inodes from previous
file systems that had been on the storage device in the case where we
are using backup bg descriptors and/or the checksums are incorrect.
This doesn't happen that often, but it's still important that the
inode table get appropriately initialized, which is why it may be ok
for a distro installer to disable the lazy itable init to speed up the
install process, but you still want to let the lazy itable process
finish up as soon as possible.

> > One or more block group descriptor checksums are invalid.  Fix<y>? yes
> > 
> > Group descriptor 0 checksum is invalid.  FIXED.
> > Group descriptor 1 checksum is invalid.  FIXED.
> > Group descriptor 2 checksum is invalid.  FIXED.
> > Group descriptor 3 checksum is invalid.  FIXED.

This is certainly scary, though.  In the case where we do need to use
the backup block group descriptors, it would be better to reset the
checksum to the correct value so we don't get all of this extra
output, which isn't useful to the user and is just going to alarm them
unnecessarily.

						- 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