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-next>] [day] [month] [year] [list]
Date:	Sat, 06 Feb 2010 18:55:36 -0600
From:	Dick Hollenbeck <dick@...tplc.com>
To:	linux-kernel@...r.kernel.org
Subject: SquashFS on ARM9


Dear Philip et. al,


I am using 2.6.30.5 on an ARM9 with squashfs.

The squashFS image is built with x86_64 form of

        mksquashfs version 4.1-CVS (2009/09/20)

a 64 bit linux program.

The image mounts into the 64 bit development system OK and I can read a 
particular file.  There are no problems on the development system, only 
the ARM9.

When mounted on ARM9 with said kernel, I get a read error reading that 
same particular file:

dmesg:

SQUASHFS error: zlib_inflate error, data probably corrupt
SQUASHFS error: squashfs_read_data failed to read block 0x50581
SQUASHFS error: Unable to read fragment cache entry [50581]
SQUASHFS error: Unable to read page, block 50581, size b6f3
SQUASHFS error: Unable to read fragment cache entry [50581]
SQUASHFS error: Unable to read page, block 50581, size b6f3
SQUASHFS error: Unable to read fragment cache entry [50581]
SQUASHFS error: Unable to read page, block 50581, size b6f3


That image resides on a CF card mounted with loop on the target ARM9.  
If I unmount the image, I can SSH copy it out off the flash back to the 
development system and do a binary compare on it there against the 
original and it is not corrupted.  Remember that the orginal mounts fine 
on the development system.  I think this means that the CF card is not 
corrupted.

Am I running into an alignment bug on the ARM9 or an endianess issue?  
(ARM9 is lsbyte first as far as I thought, same as the x86_64 Ubuntu 
Karmic development system.)

I checked the squashfs kernel block.c file against the latest mainline 
and they agree.

Please offer help.

Thanks,

Dick

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ