linux-ext4 - simple block bitmap sanity checking

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

Date:	Fri, 6 Jul 2007 12:48:56 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	linux-ext4@...r.kernel.org
Subject: simple block bitmap sanity checking

During a discussion at OLS, I came up with a very simple way of validating
the ext2/3/4 block bitmaps at read time.  Until such a time when we have
checksums for the bitmaps we can have a simple but quite robust mechanism
that is useful for ext2/3/4.

When a new block bitmap is read from disk in read_block_bitmap() there are a
few bits that should ALWAYS be set.  In particular, the blocks given by
desc->bg_block_bitmap, desc->bg_inode_bitmap, and the inode table in
[desc->bg_inode_table, +sbi->s_itb_per_group].  If those bits (shifted to be
relative to the current group, of course) are not set then the on-disk group
descriptor is corrupt, or there is some problem reading it from disk, and
this needs to generate an extN_error() call[*] to make the fs read-only.

A similar check can be done with the inode bitmap - it should have the
bits at the end of each bitmap set, for bits higher than s_inodes_per_group.

What I'm wondering is if anyone has time to implement this idea?  I'm
estimating it wouldn't be about 30 lines of simple code in total.

[*] This reminds me - we should make the default ext4 error behaviour be
    the safer "remount-ro" instead of the dangerous "continue".

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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