linux-kernel - Re: [RFC] [-mm] Remove 'unsafe' 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: <3D8CC408-75EA-445C-81F9-83EC7703A2AF@cam.ac.uk>
Date:	Thu, 24 May 2007 20:13:14 +0100
From:	Michael-Luke Jones <mlj28@....ac.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Richard Purdie <richard@...nedhand.com>, markus@...rhumer.com
Subject: Re: [RFC] [-mm] Remove 'unsafe' LZO decompressor

On 24 May 2007, at 19:50, Andrew Morton wrote:

> On Thu, 24 May 2007 18:15:17 +0100
> Michael-Luke Jones <mlj28@....ac.uk> wrote:
>
>> Attached is a patch which may be desirable for -mm. It applies
>> directly to 2.6.22-rc2-mm1.
>>
>> The patch removes the 'unsafe' LZO decompression function, lowering
>> the size of the minilzo.c file by nearly 500 out of an original 1727
>> lines. It also removes references to the 'unsafe' decompression
>> function in the public LZO header and the EXPORT_SYMBOL_GPL  
>> declaration.
>>
>> This is intended to provoke some discussion over whether a
>> decompression function able to scribble on arbitrary memory is
>> desirable in the mainline kernel, whatever the performance increases.
>>
>> Over and above the security/stability implications of using this
>> code, it can also be argued to represent an unnecessary duplication
>> of the vast majority of LZO decompression code. This is due to the
>> lack of likely in-kernel uses of the 'unsafe' function.
>>
>> Only a single user for this 'unsafe' code has been suggested, the
>> 'Compressed Caching' project. This code is highly unlikely to move
>> into mainline in the same timeframe as the LZO code. All of the other
>> suggested uses require decompression of untrusted data, such that the
>> 'safe' function should be used.
>>
>> Comments / disagreement all welcome :)
>
> This is obviously a highly desirable thing to do for a number of  
> reasons.
> But have we quantified the performance difference?

The author of LZO may be able to help us out here, so he's CCed as of  
this mail.

Michael-Luke

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