linux-ext4 - Re: How were some of the lustre e2fsprogs test cases generated?

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: <20080219122925.GW25098@mit.edu>
Date:	Tue, 19 Feb 2008 07:29:25 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: How were some of the lustre e2fsprogs test cases generated?

On Tue, Feb 19, 2008 at 04:40:32AM -0700, Andreas Dilger wrote:
> 
> No, it hasn't always been true that we cleared the _hi fields in the
> kernel code.  But, it has been a year or more since we found this bug,
> and all CFS e2fsprogs releases since then have cleared the _hi fields,
> and there has not been any other e2fsprogs that supports extents, so
> we expect that there are no filesystems left in the field with this
> issue, and even then the current code will prefer to clear the _hi
> bits instead of considering the whole extent corrupt.
> 

I checked again, and it looks like the interim code is indeed clearing
the _hi bits.  I managed to confuse myself into thinking it didn't for
index nodes, but I checked again and it seems to be doing the right
thing.

The reason why I asked is that the extents code in the 'next' branch
of e2fsprogs *does* consider the whole extent to be corrupt, since in
the long run once we start 64-bit block number extent blocks, if the
physical block number (including the high 16 bits) is greater than
s_blocks_count, simply masking off the high 16 bits of the 48 bit
extent block is probably not the right way of dealing with the
problem.

I think that's probably a safe thing to do since all of your customers
who might have had a filesystem with non-zero _hi fields have almost
certainly run e2fsck to clear the _hi bits at least once; do you
concur that is a safe assumption?  Or would you prefer that I add some
code that tries to clear just the _hi bits, perhaps controlled by a
configuration flag in e2fsck.conf?

Regards,

						- 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