linux-ext4 - Re: [PATCH] e2fsprogs: allocate inode table wholly within group

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131001015746.GF5845@thunk.org>
Date:	Mon, 30 Sep 2013 21:57:46 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] e2fsprogs: allocate inode table wholly within group

On Mon, Jul 08, 2013 at 04:27:21PM -0500, Eric Sandeen wrote:
> 
> The actual problem seems to be that the test does successive "-M" minimal resizes, and eventually we resize into the middle of an inode table, leaving the end of the table beyond the fs.
> 
> Point "resize2fs -M" at the attached image once or twice w/ fscks in between and you should see it.

I've been going through my patch backlog, so I finally had a chance to
take a very close look at your test image.  I now understand why
things are failing.

1) The test image (which you said was generated on a ppc e2fsprogs?)
was doing something very weird as far as the location of the
allocation bitmaps and inode table:

Filesystem features:      ext_attr dir_index filetype sparse_super
Inode count:              512
Block count:              1247
   ...

Group 0: (Blocks 1-1024)
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 66 (+65), Inode bitmap at 67 (+66)
  Inode table at 68-99 (+67)

Group 1: (Blocks 1025-1246)
  Backup superblock at 1025, Group descriptors at 1026-1026
  Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
  Inode table at 1092-1123 (+67)

Compare and contrast this with what x86 and Debian's ppc mke2fs creates:

Group 0: (Blocks 1-1024)
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 3 (+2), Inode bitmap at 4 (+3)
  Inode table at 5-14 (+4)

Group 1: (Blocks 1025-1246)
  Backup superblock at 1025, Group descriptors at 1026-1026
  Block bitmap at 1027 (+2), Inode bitmap at 1028 (+3)
  Inode table at 1029-1038 (+4)

So I'm not sure why Fedora's ppc mke2fs is creating file systems in
this way, but that's one of the causes of the bug.

2) The second cause of the bug is that
calculate_minimum_resize_size(), when we calculate the number of
blocks for the last group, the code has an implicit assumption that
the metadata blocks are located at the very beginning of the block
group.   That's an easy fix.

> It seems like the obvious fix would be to move the inode table if
> necessary, as with the following patch.

Your patch is a good one, but at least in the context of resize2fs -M,
we should be fixing calculate_minimum_resize_size() so we can avoid
needing to move the inode table (since even if it can succeed, it's
not worth the danger).

I'll send out some patches to address this.  Thanks for sending the
test image; and my apologies for not having time to get back to this
until now.

					- 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