linux-ext4 - Re: [PATCH] uninitialized groups ported

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:	Tue, 5 Jun 2007 15:20:05 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Avantika Mathur <mathur@...ux.vnet.ibm.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] uninitialized groups ported - kernel

On Jun 05, 2007  13:48 -0500, Eric Sandeen wrote:
> Avantika Mathur wrote:
> >I have ported your uninitialized block group kernel patch to mainline
> >2.6.22-rc3, included below.
> >I will also be posting the ported e2fsprogs patches. I had trouble
> >testing the patches because of inconsistency in the block_group
> >structure in e2fsprogs - which is only using ext2_block_group, and not
> >ext4_block_group.
> 
> >+#if !defined(CONFIG_CRC16) && !defined(CONFIG_CRC16_MODULE)
> >+/** CRC table for the CRC-16. The poly is 0x8005 (x16 + x15 + x2 + 1) */
> >+__u16 const crc16_table[256] = {
> >+	0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241,
> >+	0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440,
> 
> 
> Apologies if this has already been discussed & I missed it, but why 
> replicate all this?  why not just require CONFIG_CRC16?

For CFS we need this in our patches because crc16() is not available in
older kernels.  For 2.6.2x it is available, so there is not really any
need to included it unless you are building ext4 against an existing
kernel which does not have crc16() configured (it is not on by default).
I don't think it is harmful, but I don't care whether it is kept or not.

FYI, the other thing I noticed about the e2fsprogs part of this feature is
that PPC seems to break crc16(__u16 crc) and treat crc as a signed int.
This causes e.g. crc16(~0, buf, len) to calculate "crc >> 8" to be 0xffffff
and the resulting checksum is wrong.

I ended up working around the problem by passing unsigned int instead
of __u16 as a parameter, and masking the intermediate results in a
WORDS_BIGENDIAN environment, though I'm not sure if it is big-endian
that is at fault or only the PPC code.  Attached is an updated e2fsprogs
patch for this, which includes crc16() regression tests that pass on PPC,
in addition to the ext2fs_group_desc_csum() tests which previously failed.

Thanks to Oregon State University (and IBM) for having public-access PPC
machines to test this on (http://powerdev.osuosl.org/).

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

View attachment "e2fsprogs-uninit.patch" of type "text/plain" (86521 bytes)