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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ