linux-ext4 - Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.

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:	Thu, 13 Dec 2007 20:36:11 -0600
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.

On Thu, 13 Dec 2007 15:58:57 -0700
Andreas Dilger <adilger@....com> wrote:

> On Dec 13, 2007  09:51 -0600, Jose R. Santos wrote:
> > Now, storing the bits only guaranties that the flexbg size is always a
> > power-of-two and does not guarantee that the super block flexbg size
> > represents the actual meta-data grouping on disk.  For this we need to
> > verify that the bitmap offsets match what the super block reports.  It
> > may be an unlikely scenario, but it may be worth it to check this as
> > well at mount time.
> 
> I'm not sure what you mean...  Isn't the flexbg size just a count of
> the number of block groups?  If it is always a power of two, and the
> groups per metabg is always a power of two (it is) then they will
> always be even multiples.

What I mean is that if the value in the super block is corrupted and
does not represent the actual flexbg size, the inode allocation will
behave in weird unexpected ways.  Just as we check that the bitmaps are
within the block group range (when not using flexbg), we should
probably sanity check the size of the flexbg as reported in the super
block.

Or do you believe the check is unnecessary?

> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, 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