linux-kernel - Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions

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]

Message-ID: <20120525113432.3beea6ed@tukaani.org>
Date:	Fri, 25 May 2012 11:34:32 +0300
From:	Lasse Collin <lasse.collin@...aani.org>
To:	T Makphaibulchoke <tmac@...com>
Cc:	lethal@...ux-sh.org, hpa@...or.com, tglx@...utronix.de,
	mingo@...hat.com, x86@...nel.org, kaloz@...nwrt.org,
	matt.fleming@...el.com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-sh@...r.kernel.org, linux@....linux.org.uk,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
	linux390@...ibm.com
Subject: Re: [PATCH] lib/decompress_unxz.c: removing all memory helper
 functions

On 2012-05-24 T Makphaibulchoke wrote:
> The patch cleans up the file lib/decompress_unxz.c by removing all
> memory helper functions, e.g., memmove.  By doing so, any
> architecture's preboot environment supporting the XZ decompression
> needs to define its own copy of any of the missing memory helper
> functions.

Is it best to copy these functions to each arch, or would it be better
to have a shared file from which these functions could be pulled for
multiple archs? I wasn't sure when I wrote decompress_unxz.c, which is
why I put the extra functions there as a temporary solution.

> Adding both the missing memmove and memcmp functions, required by the
> XZ decompressor, to the sh preboot environment.
> 
> Adding the missing memmove function, required by XZ decompressor, to
> the x86 preboot environment.

These already have memcpy. It can save a few bytes if one reused
memmove as memcpy when using XZ compression. I got a difference of 48
bytes on x86_64.

Adding memmove to string.c on x86 means that memmove is included in the
kernel image even when memmove isn't needed. With gzip compression I
got 128 bytes bigger image on x86_64 after adding the unneeded memmove
to string.c.

I don't know if those size increases matter in practice.

> + * To support XZ-decompressed file in preboot environment, the

s/XZ-decompressed/XZ-compressed/ :-)

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode
--
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/