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]

Message-ID: <4cefeab80705240729w6cf0f84fvb6cd86e19256b2b@mail.gmail.com>
Date:	Thu, 24 May 2007 19:59:01 +0530
From:	"Nitin Gupta" <nitingupta910@...il.com>
To:	"Satyam Sharma" <satyam.sharma@...il.com>
Cc:	"Richard Purdie" <richard@...nedhand.com>,
	linux-kernel@...r.kernel.org, linux-mm-cc@...top.org
Subject: Re: [RFC] LZO de/compression support - take 3

On 5/24/07, Satyam Sharma <satyam.sharma@...il.com> wrote:
> Hmm. The wrappers would clearly be inline, but if we want a common
> low-level decompress function, we'd also need to introduce the "if (safe &&)"
> kind of tests for those differently-defined macros which could impact
> performance (for the _unsafe variant only, isn't it). By how much is the
> question, and whether we really care to avoid duplicating 50 lines of code
> to take that hit on the unsafe function (or vice versa).

All this just to avoid that symlink? What is so wrong with that? Yes,
the ugliest thing is some additions to top-level Makefile but I think
this the reason those prepare{1,2,3....} targets were meant for.

> > All I will add is that after the amendment I made, the ugliness in my
> > patchset is confined to one file now and I still think its the better
> > approach to take.
> >
> > My main concerns with this patch are that:
> > * from the security point of view its not tried and tested code
> > * I'm not 100% confident in what Nitin has done with the code from a
> >   buffer overflow/security PoV
> > * its not tested on many architectures
> > * the performance implications of the rewrite are unknown
>
> Right, it needs testing (for correctness and robustness). But that
> shouldn't be too difficult -- Nitin, you could just write up a simple test
> module that others can use with your patch to do testing on their
> arch's ... the more this gets tested, the better chances it's got.
>

Mailed 'compressed-test' module along with usage to Bret (CC'ed to
you, Richard, linux-kernel). This makes it very easy to test this LZO
code.


Thanks for comments.

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