linux-ext4 - Re: [PATCH 0/2] Add inode checksum support to ext4

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]

Message-ID: <20110727082730.GG20655@tux1.beaverton.ibm.com>
Date:	Wed, 27 Jul 2011 01:27:30 -0700
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Add inode checksum support to ext4

On Fri, Apr 08, 2011 at 12:27:48PM -0700, Mingming Cao wrote:
> On Wed, 2011-04-06 at 15:44 -0700, Darrick J. Wong wrote:
> > Hi all,
> > 
> > I spent last week analyzing a client's corrupted ext3 image to see if I could
> > determine what had gone wrong and caused the filesystem to blow apart.  As best
> > as I could tell, a data block got miswritten into a different sector ... which
> > happened to be an indirect block.  Some time later the indirect block, which
> > now pointed at one of the inode tables (among other things that shouldn't ever
> > become file data) was loaded as part of a file write, which caused that inode
> > table to be blown to smithereens.  Just for fun I tried reading from one of
> > these busted-inode files and ... failed to encounter any errors.  Somehow, they
> > didn't find it funny that ext3 would read block numbers from a table with the
> > contents "ibm.com" with a straight face.  Fortunately there were backups. :)
> > 
> > The client at this point asked if ext4 would do a better job of sanity
> > checking, which got me to wonder why ext4 checksums block groups but not
> > inodes.  It's on Ted's todo list, but apparently nobody wrote any patch, so I
> > did.  The following two patches are a first draft of adding inode checksum
> > support to both the kernel driver and to the various e2fsprogs.
> > 
> 
> We had some discussion about this week at SF (at the ext4 bof at the
> linux colloboration summit). Beyond checksumming the inode itself, it
> would be more useful to checksum the extent indexing blocks, as the ext3
> corruption actually happen at the indirect block.  
> 
> The idea is to reduce the eh_max (the max # of extents stored in this
> block) to save some space to store the checksums in the block, 
> 
> /*
>  * Each block (leaves and indexes), even inode-stored has header.
>  */
> struct ext4_extent_header {
>         __le16  eh_magic;       /* probably will support different
> formats */
>         __le16  eh_entries;     /* number of valid entries */
>         __le16  eh_max;         /* capacity of store in entries */
>         __le16  eh_depth;       /* has tree real underlying blocks? */
>         __le32  eh_generation;  /* generation of the tree */

Does anyone use eh_generation?  Linux 3.0 shows no users and it didn't look like
the snapshot patches do either.  If nobody intends to start using this field,
(part of) it could become eh_checksum.

--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