linux-kernel - Re: [PATCH 1/2] lib: add fast lzo decompressor

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: <1238624827.15230.58.camel@andreas-desktop>
Date:	Thu, 02 Apr 2009 00:27:07 +0200
From:	Andreas Robinson <andr345@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alain Knaff <alain@...ff.lu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib: add fast lzo decompressor

On Wed, 2009-04-01 at 13:55 -0700, H. Peter Anvin wrote:
> Andreas Robinson wrote:
> > 
> > Perhaps the system can default to the safe decompressor for normal use
> > and choose the fast one if STATIC is defined or when system_state ==
> > SYSTEM_BOOTING?
> > 
> 
> Do we really need two pieces of code?

To get the higher speed offered by the fast function, yes.

Merging the two with some macro magic and then compile twice with
different macro definitions could work though. That might hurt the
readability of the code a bit. Or help. :-) I'll look into it.

Anyway, I assume it is maintainability rather than size you're concerned
about here?

The duplicate function adds just 1.7 KB to the kernel and you throw it
out once the kernel has finished booting.

OTOH, the safe version is far from useless. 

I estimate (but haven't tested yet) that you would lose about 40 ms in
the Eee test case. That is, the boot-time savings are reduced from 123
to perhaps 85 ms which is still acceptable. It is certainly much less
complicated than the alternatives, so if that's what you would prefer I
can go that way.

>   What if we have memory corruption 
> during early boot - it seems we'd want to at least try to catch that 
> with an error message rather than just crashing.

This is very easy to do, so consider it done.

The decompressor is essentially a glorified memcpy that can copy the
same data to several locations. You only have to check whether the write
pointer has passed the end of the output buffer to see if something went
wrong.

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