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]

Date:	Fri, 25 May 2012 10:31:47 -0600
From:	Thavatchai Makphaibulcboke <thavatchai.makpahibulchoke@...com>
To:	Lasse Collin <lasse.collin@...aani.org>
CC:	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"kaloz@...nwrt.org" <kaloz@...nwrt.org>,
	"matt.fleming@...el.com" <matt.fleming@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"schwidefsky@...ibm.com" <schwidefsky@...ibm.com>,
	"heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
	"linux390@...ibm.com" <linux390@...ibm.com>
Subject: Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions

On 05/25/2012 02:34 AM, Lasse Collin wrote:
> 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.
> 

Yes, I agree that having a shared file would be the best solution.
Unfortunately with the current preboot architecture and infra structure,
it would not be a trivial task. I believe defining these functions for
each arch would give a better code modularity compared to including them
in the decompressor file.

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

We could do that.  But according to the comment in the original
implementation, there seems to be a concern regarding its performance
speed. If you believe all archs' memcpy would give comparable
performance to the memmove. then I could do that.

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

For x86, I think I could move memmove to the misc.c file and put an
ifdef XZ_PREBOOT around it.  This way it should not impact other
decompressor.  I could also do this for s390 and sh.  But if we decide
to replace memmove with memcpy this would be necessart.

Thank you very for your comment.  Please let me know what you think.
I'll redo and send out a new patch.  Thanks in advance.

Thanks,
Mak.


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