linux-ext4 - Re: [patch] 48bit extents in e2fsprogs

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]

Message-ID: <20060916181643.GI6441@schatzie.adilger.int>
Date:	Sat, 16 Sep 2006 12:16:43 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Alexandre Ratchov <alexandre.ratchov@...l.net>
Cc:	linux-ext4@...r.kernel.org,
	Jean-Pierre Dion <jean-pierre.dion@...l.net>
Subject: Re: [patch] 48bit extents in e2fsprogs

On Sep 15, 2006  20:11 +0200, Alexandre Ratchov wrote:
> On Fri, Sep 15, 2006 at 10:57:43AM -0600, Andreas Dilger wrote:
> > - the check for ee_start_hi and ei_leaf_hi fields (PR_1_EXTENT_HI) needs to
> >   be fixed (I don't see it changed here) so that it considers that an error
> >   only if INCOMPAT_64BIT flag is set and the filesystem is > 2^32 blocks.
> >   That is in e2fsck_ext_block_verify()
> > - (FYI) In my definition of PR_1_EXTENT_HI I recently added the PR_PREEN_NOMSG
> >   flag because users were confused about the "High 16 bits of extent/index
> >   block set" message even though it is harmless for 32-bit filesystems.
> 
> just to be sure to get it right: we allow 32bit file-systems to have extents
> with _hi bits set, right? (and *_hi are ignored)

Well, this is an undesirable side-effect of the old 32-bit extents code.
e2fsck should just clear the _hi fields for 32-bit filesystems.  For
larger filesystems it should assume they are valid.  That means that the
PR_1_EXTENT_HI checks should just be skipped for > 32-bit filesystems.

> so we can't simply assume that extents are always 48bit, in which case it
> would be enough to just check that they are inside the block group (that
> would detect extents with *_hi set as corrupt).

For now I wouldn't change the ext4 code.  The latest CFS e2fsprogs and kernel
code clears the _hi fields correctly, and we can get our users to run an
e2fsck before they ever start using ext4-based code (which likely won't be
for a year or more) if they have a filesystem which still has _hi values set.

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

-
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