linux-kernel - Re: [PATCH] crypto: compress

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:	Thu, 15 Jan 2009 11:54:53 +0100 (CET)
From:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: compress - Add pcomp interface

	Hi Herbert,

On Thu, 15 Jan 2009, Herbert Xu wrote:
> On Wed, Jan 14, 2009 at 04:01:34PM +0100, Geert Uytterhoeven wrote:
> > It's used by the pr_*() macros in <linux/kernel.h>.
> > 
> > Since commit d091c2f58ba32029495a933b721e8e02fbd12caa ("Add 'pr_fmt()' format
> > modifier to pr_xyz macros."), this is the new way to have a common prefix in
> > all printed output.
> 
> But you don't actually print anything out in the module :)

But there are pr_debug()s ;-)

> > For compatibility with crypto_comp, we also need an alloc function for both
> > compress and decompress, so that makes 3 alloc functions.
> 
> Couldn't crypto_comp just call both alloc functions? I don't see
> why we need a third function.
> 
> > > 1) We know what the user wants to do without every algorithm
> > > reinventing their own signalling for it;
> > 
> > I guess you want to use the flags to indicate compress/decompress/both?
> > Unfortunately I'm still struggling to fully understand the type/mask handling,
> > so I would appreciate it if you could give me a hint how to handle that.
> 
> No, I mean that whether you want compression or decompression
> is signified by the which function you're calling.  If you want
> to do both then you call both.

By "both alloc function", do you mean the .setup_comp() and .setup_decomp()
functions? If yes, then I understand.

(Yesterday, I thought you meant to have separate alloc functions instead of the
one crypto_alloc_pcomp())

> > I assume "length" is the size of the passed params, so the algorithms can
> > return -EINVAL if they're passed the wrong size?
> 
> Well with the netlink parameters these can have variable lengths
> depending on how many parameters the user supplies.

IC.

> > > > +static inline struct crypto_pcomp *crypto_alloc_pcomp(const char *alg_name,
> > > > +						      u32 type, u32 mask)
> > > > +{
> > > > +	type &= ~CRYPTO_ALG_TYPE_MASK;
> > > > +	type |= CRYPTO_ALG_TYPE_PCOMPRESS;
> > > > +	mask |= CRYPTO_ALG_TYPE_MASK;
> > > > +
> > > > +	return __crypto_pcomp_cast(crypto_alloc_base(alg_name, type, mask));
> > > > +}
> > > 
> > > That's the old way to allocate tfm's which won't work since pcomp
> > > is using the new type API.  You should do it the way that shash
> > > does it.
> > 
> > I tried to do this, but stumbled across a dependency problem: as
> > crypto_alloc_tfm() needs a pointer to crypto_pcomp_type(), crypto_alloc_pcomp()
> > can no longer be static inline, and must be moved to crypto/pcompress.c.
> 
> Ah yes because crypto_comp is one of the original types that's
> still built-in.  Because there are so few compression users and
> algorithms (exactly 3 if you include null compression), I think
> we can dispense with the compatibility stuff altogether since
> we'll likely rip out fairly soon anyway.
> 
> So just create the new type, readd deflate using the new type
> alongside the existing deflate algorithm.  The system is capable
> of supporting two algorithms of the same name with different types.
> 
> Then once the other algorithm (lzo) is taken care of and all the
> users are converted I'll just kill the old type and algorithms.

I doubt whether it's a good idea to drop the compatibility soon, as the
underlying LZO library in the kernel doesn't support partial (de)compression,
and needs significant rework to do so.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@...ycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
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/