linux-kernel - Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

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: <20150922124346.GA11658@gondor.apana.org.au>
Date:	Tue, 22 Sep 2015 20:43:46 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Joonsoo Kim <js1304@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan@...nel.org>,
	Nitin Gupta <ngupta@...are.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Stephan Mueller <smueller@...onox.de>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH v3 1/9] crypto: introduce decompression API that can be
 called via sharable tfm object

On Fri, Sep 18, 2015 at 02:19:16PM +0900, Joonsoo Kim wrote:
> Until now, tfm object embeds (de)compression context in it and
> (de)compression in crypto API requires tfm object to use
> this context. But, there are some algorithms that doesn't need
> such context to operate. Therefore, this patch introduce new crypto
> decompression API that calls decompression function via sharable tfm
> object. Concurrent calls to decompress_noctx function through sharable
> tfm object will be okay because caller don't need any context in tfm and
> tfm is only used for fetching function pointer to decompress_noctx
> function. This can reduce overhead of maintaining multiple tfm
> if decompression doesn't require any context to operate.
> 
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@....com>

Have you looked into include/crypto/compress.h?

The compress type itself is obsolete and should be replaced with
the pcomp interface.

However, we made some mistakes with the pcomp interface.  First
of all it doesn't have a non-partial interface like the digest
function for crypto_shash.

But the biggest problem is that it should be completely stateless
but is not.  IOW we should not store anything in the tfm that
is per-request.  That should all go into the request structure.

Fortunately it seems that pcomp doesn't actually have any users
so we can just rip it out and start from scratch and redo it
properly.

So to recap, please abandon any efforts on the crypto_compress
interface as it is old and obsolete.  Instead reshape crypto_pcomp
into a proper stateless interface which should then give you what
you want.

When you do so, just keep in mind that we need to find a way to
support IPComp.  That means the ability to allocate requests in
thread context and then use them to compress/decompress in IRQ
context.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/