linux-kernel - The bzip2/lzma patches

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-next>] [day] [month] [year] [list]

Message-ID: <495ADD46.7080601@zytor.com>
Date:	Tue, 30 Dec 2008 18:47:34 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alain Knaff <alain@...ff.lu>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: The bzip2/lzma patches

Hi Alain,

I finally got the tree with your latest bzip2/LZMA code unburied.  My
apologies for having sat on it for so long (you know why.)

Anyway, I did run into a few things that I'd really like to get fixed.

First of all, there are more than just the x86 and ARM tree which is
using the old API, I count at least four more architectures.  I can't
apply the ARM tree anyway, and we clearly need a saner migration way.

Second, the ugly if...goto hacks in init/initramfs.c could be much
cleaner handled by iterating down a list of function pointers -- except
that gunzip() seems to have a different return value (in init/than the
others?!

Third, you're using the construct if (!foo() < 0 && message == NULL)

... which is wrong on three(!) accounts, one technical (! has higher
precedence than <) and two stylistic (write >= instead of !(.. < ..) and
write !message instead of message == NULL).

I think the solution to all of this is to introduce a new function
instead of gunzip(), and have the old gunzip() be a wrapper using the
old ABI.  That is much cleaner than relying on #ifdef NEW_CODE.

Finally, I know I suggested it, but I don't think the
<linux/decompress/*.h> header file are justified given that they only
contain a single function header.  Might as well put them all in a
single <linux/decompress.h> header.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/