linux-ext4 - Re: [PATCH][7/28] e2fsprogs-extents.patch

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:	Mon, 18 Feb 2008 11:56:53 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andreas Dilger <adilger@....com>
CC:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH][7/28] e2fsprogs-extents.patch

Andreas Dilger wrote:
> Support for checking 32-bit extents format inodes and the INCOMPAT_EXTENTS
> feature.
> 
> Clear the high 16 bits of extents and index entries, since the
> extents patches did not do this explicitly.  Some parts of this
> code need fixing for checking > 32-bit block filesystems (when
> INCOMPAT_64BIT support is added), marked "FIXME: 48-bit support".
> 
> Verify extent headers in blocks, logical ordering of extents,
> logical ordering of indexes.
> 
> Add explicit checking of {d,t,}indirect and index blocks to detect
> corruption instead of implicitly doing this by checking the referred
> blocks and only block-at-a-time correctness.  This avoids incorrectly
> invoking the very lengthy duplicate blocks pass for bad indirect/index
> blocks.  We may want to tune the "threshold" for how many errors make
> a "bad" indirect/index block.
> 
> Add ability to split or remove extents in order to allow extent
> reallocation during the duplicate blocks pass.
> 
...


> @@ -904,21 +910,75 @@ void e2fsck_pass1(e2fsck_t ctx)
>  			ctx->fs_sockets_count++;
>  		} else
>  			mark_inode_bad(ctx, ino);
> -		if (inode->i_block[EXT2_IND_BLOCK])
> -			ctx->fs_ind_count++;
> -		if (inode->i_block[EXT2_DIND_BLOCK])
> -			ctx->fs_dind_count++;
> -		if (inode->i_block[EXT2_TIND_BLOCK])
> -			ctx->fs_tind_count++;
> -		if (inode->i_block[EXT2_IND_BLOCK] ||
> -		    inode->i_block[EXT2_DIND_BLOCK] ||
> -		    inode->i_block[EXT2_TIND_BLOCK] ||
> -		    inode->i_file_acl) {
> -			inodes_to_process[process_inode_count].ino = ino;
> -			inodes_to_process[process_inode_count].inode = *inode;
> -			process_inode_count++;
> -		} else
> -			check_blocks(ctx, &pctx, block_buf);
> +
> +		eh = (struct ext3_extent_header *)inode->i_block;
> +		if ((inode->i_flags & EXT4_EXTENTS_FL)) {
> +			if ((LINUX_S_ISREG(inode->i_mode) ||
> +			     LINUX_S_ISDIR(inode->i_mode)) &&

So this trips up on things like sockets, fifos, and block & char nodes.

Also this is unhappy:

> @@ -137,7 +141,7 @@ int e2fsck_pass1_check_device_inode(ext2
>  	 * If the index flag is set, then this is a bogus
>  	 * device/fifo/socket
>  	 */
> -	if (inode->i_flags & EXT2_INDEX_FL)
> +	if (inode->i_flags & (EXT2_INDEX_FL | EXT4_EXTENTS_FL))
>  		return 0;

Do we really care if these have the extents flag set?  IOW should we
make sure the kernel doesn't set the flag, or should we make e2fsck not
care...

There are enough checks in e2fsck to show the intent was that these
files should not have the extents flag set, but I'm not sure why it
matters enough that the kernel needs to run around being sure to clear
it....

Or... (rambling on now) it seems odd to me that zero-length files have
the extents flag set at all; should we only set extents when we actually
get a block allocated to the file?  That would also take care of this
from the kernel side I think.

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