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]

Date:	Fri, 25 May 2007 12:05:26 +0530
From:	"Nitin Gupta" <nitingupta910@...il.com>
To:	"Markus F.X.J. Oberhumer" <markus@...rhumer.com>
Cc:	"Richard Purdie" <richard@...nedhand.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Michael-Luke Jones" <mlj28@....ac.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	"Satyam Sharma" <satyam.sharma@...il.com>
Subject: Re: [RFC] [-mm] Remove 'unsafe' LZO decompressor

Hi Markus,

On 5/25/07, Markus F.X.J. Oberhumer <markus@...rhumer.com> wrote:
> Please do _not_ rewrite the LZO implementation just for coding style principles.
>
> The current miniLZO implementation is _extrememly_ well tested, pretty
> optimized and quite portable.
>
> I agree that the implementation may look confusing, but you should be able to
> make it look much better by removing all the unused #defines and #ifdef code
> paths - LZO supports exotic things like 16-bit DOS and CRAY PVP memory models
> which obviously are not needed in the kernel and account for quite a number of
> abstractions (which are implemented through the preprocessor).
>
> Finally the current version has been tested with a lot of compilers and
> contains accumulated knowledge about some hairy things - see
> http://gcc.gnu.org/PR25196 for an example, as well as some not-yet identified
> aliasing issue.
>
> ~Markus

I did not rewrite any part of your code except replacing COPY4() macro
and some open-coded byte-by-byte copying with memcpy(). But this has
resulted in very significant perf. loss (as suggested by results from
Richard's tests) - so will rollback these changes.

Additionally following was done to _greatly_ reduce no. of LOC I had
to retain. These should not affect code correctness and performance:
- Used standard/kernel defined data types equivalent of lzo_* types.
This resulted in removal of huge chunks of #ifdefs:
    lzo_byptep -> unsigned char *
    lzo_uint -> size_t
    lzo_xint -> size_t
    lzo_uintptr_t -> unsigned long
    lzo_uint32p -> uint32_t *
- Removed everything #ifdefed under COPY_DICT  -- from minilzo code I
see that this is not #defined for LZO1X (safe/unsafe) (though I could
not understand meaning behind COPY_DICT).
- Removed everthing #ifdef'ed for LZO1Y, LZO1Z, other variants.


Thanks,
Nitin
-
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/