linux-kernel - 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: <EF1F2330-D8C4-427A-ABB9-D1E607D91A3D@gmail.com>
Date:	Wed, 27 Jul 2011 03:16:12 -0600
From:	Andreas Dilger <aedilger@...il.com>
To:	"djwong@...ibm.com" <djwong@...ibm.com>
Cc:	Mingming Cao <cmm@...ibm.com>, 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 2011-07-27, at 2:27 AM, "Darrick J. Wong" <djwong@...ibm.com> wrote:
> On Fri, Apr 08, 2011 at 12:27:48PM -0700, Mingming Cao wrote:
>> 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

We use eh_generation in Lustre to detect if the extent tree is being changed while it is unlocked.

In the past, the discussion about adding checksums to the index and extent blocks was about using an ext4_extent_tail that contained not only the checksum of the block, but also a back-pointer to the inode/generation of the inode using this block.

That would allow e2fsck to verify that it is using the correct index/extent blocks and not pointing to a stale block that belonged to some other inode.

Since the header and index/extent entries are always 3 *__u32 in size, the extent tail can always be 4 * __u32 in size yet only consume a single slot in the block. There of course is no reason to put an extent tail inside the inode itself.

Cheers, Andreas--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/