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]
Date:	Fri, 29 Sep 2006 17:15:56 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	J�rg Sommer <joerg@...a.gnuu.de>,
	389772@...s.debian.org, paulus@...ibm.com,
	linux-ext4@...r.kernel.org
Subject: Re: Bug#389772: e2fsprogs: e2fsck produces broken htree on ppc

On Fri, Sep 29, 2006 at 11:15:47AM -0600, Andreas Dilger wrote:
> Hmm, except isn't the problem ALREADY that PPC is broken with 8-bit
> chars and htree?  That's what started this problem in the first place.
> Running e2fsck allowed the kernel htree code to find the file, when
> it could not otherwise be looked up...  Need to verify that (my mental
> stack is overflowing).
> 
> IIRC this problem was also reported in the past but no solution was found.
> I think fixing the kernel to specify signed chars for the hash will FIX
> the PPC kernel code.

If the filesystem is empty (or at least no no hashtree directories),
then when the kernel creates new directories and expands to the point
where they become indexed, they will be indexed with the PPC variant
of the hash algorithm.  This will be self consistent, and everything
will work fine --- until the filesystem gets corrupted to the point
where e2fsprogs needs to rebuild one or more hashed directories.  At
that point the directories will be rebuilt using the same conventions
used by all other conventions, but the directories will no longer be
useful on the PPC kernel.

Joerg, can you confirm this?  On a PPC machine, can you create a
smallish ext3 filesystem (say, 4-8 megabytes), create a directory with
enough files in it that it becomes indexed (verify using lsattr), and
show that it works just fine on a PPC.  Now take that image, and
transfer it to an x86 machine; you should find that the kernel can't
look up any of the directories on the x86 machine.  If you then run
e2fsck -fD on that filesystem (running the e2fsck on either x86 or
PPC; it shouldn't make a difference), then the resulting filesystem
should work just fine on the x86, and fail on the PPC.

If I understand this problem correctly, the above experiment should
confirm what I suspect is going on.

						- 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ