linux-kernel - Re: [RFC] LZO de/compression support

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 2007 12:55:21 -0400
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Richard Purdie <richard@...nedhand.com>
Cc:	Satyam Sharma <satyam.sharma@...il.com>,
	Nitin Gupta <nitingupta910@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm-cc@...top.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Panin <pazke@...pac.ru>, Bret Towe <magnade@...il.com>,
	Michael-Luke Jones <mlj28@....ac.uk>
Subject: Re: [RFC] LZO de/compression support - take 4

On Friday 25 May 2007 09:38:24 Richard Purdie wrote:
<snip>
> > > I am however still strongly of the opinion that we should just use the
> > > version in -mm (which is my latest version).
> >
> > Right, if the difference is anything >10%, code cleanup does lose
> > its attractiveness.
>
> Agreed, and I still have the security and maintainability concerns. Add
> them all together and its more unattractive.

I can understand the security concerns, but since none of the bounds checking 
has been removed there shouldn't be any difference from a security  
viewpoint. I have maintained the code to a MUD server at one point - I can 
guarantee that it had a lot more code than the LZO code - and it was so 
highly customized that no patches to the core code from anywhere *outside* 
that games "coders" would apply. This means that every one of those patches 
had to be done manually - sure, it was a massive PITA - but it was worth it.

In other words - yes, it will make maintaining the code harder, but the fact 
that the code matches the kernels style and is "lightweight" compared to the 
original userspace code *and* Richards "miniLZO" should mitigate this.

As to the performance - I can see absolutely no reason why the minimal version 
shouldn't perform the same (or better). The kernel codes memset and memcpy 
routines have been heavily tested *and* optimized over the years and moving 
from macro's to inline functions shouldn't have impacted performance at all. 
I will be testing the two code bases myself in a little bit - I'm more than a 
little paranoid and don't like the idea of trusting anyone with a "competing 
project" for all testing.

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