linux-ext4 - Re: [PATCH 3/4][e2fsprogs] Relax group descriptor 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-prev] [day] [month] [year] [list]

Date:	Fri, 3 Aug 2007 15:05:49 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/4][e2fsprogs] Relax group descriptor checking.

On Fri, 3 Aug 2007 12:22:17 -0600
Andreas Dilger <adilger@...sterfs.com> wrote:
> On Aug 02, 2007  23:00 -0500, Jose R. Santos wrote:
> > Eventually, a more thorough check would restrict bitmaps and inode
> > tables to be located at the beginning of a flex block group range.
> > Since the super block does not currently know about the number of
> > groups per flex group, this will do for now.
> 
> As with regular block groups, it would probably be better to limit the
> bitmaps and inode tables to anywhere inside the flexbg instead of the
> start.  That would allow, for example, INCOMPAT_FLEXBG to be enabled
> on an existing filesystem and the metadata could be moved together as
> space becomes available.

This is something that would be simple to do if the ratio of block
groups per flex group known to the filesystem itself.  This implies
adding another field to the super block as reliable way to obtain this
information.  The only thing keeping me from doing so is the uncertainty
of backwards compatibility when changing the super block structure.

I agree though that one of the requirements for this feature is more
robust checking of the location of the bitmaps and inode tables within
the flex group.  Checking of the descriptor in flexbg become a little
more complicated than in regular block groups because:

1. The block and inode bitmaps should be allocated a one big chunk for
each flex group.

2. The block and inode bitmaps should be located in the first block
group and the inode tables with in the first few groups of a flex group.

3. If the full range of bitmaps in not allocated contiguously, this
means that bad blocks caused us to move a particular bitmap out and
thus the bad block list should be checked to ensure that this was the
case.

If the above conditions are not met, this could point to possible
corruption in the block descriptors.

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

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