linux-kernel - Re: [PATCH 10/10] drivers/crypto/nx: add hardware 842 crypto comp alg

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, 7 May 2015 11:06:06 -0400
From:	Dan Streetman <ddstreet@...e.org>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Michael Ellerman <mpe@...erman.id.au>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Seth Jennings <sjennings@...iantweb.net>,
	Robert Jennings <rob@...hix.net>, linux-crypto@...r.kernel.org,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 10/10] drivers/crypto/nx: add hardware 842 crypto comp alg

On Wed, May 6, 2015 at 11:12 PM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Wed, May 06, 2015 at 12:51:06PM -0400, Dan Streetman wrote:
>> Add crypto compression alg for 842 hardware compression and decompression.
>>
>> This crypto compression alg is named "nx842" to indicate it uses hardware
>> to perform the compression and decompression, while the software 842
>> compression alg is named "sw842".  However, since before this split there
>> was only one 842 compression alg named "842" which only used hardware,
>> this is also aliased "842" for backwards compatibility.
>
> This should still be called 842.  You can set the driver name to
> nx842 or 842-nx.

ah, ok, will do.

So, I'm wondering about the common NX 842 frontend driver, for the
pSeries and PowerNV platform drivers.  The current setup is:

[ crypto "842-nx" driver ]
           v
[ nx-842 main driver ]
          v
[ nx-842 pSeries driver | nx-842 PowerNV driver ]

The main reason for that is that the HW has specific constraints,
specifically each input and output buffer passed to it for comp or
decomp has to:
-be located at a specific alignment
-have a length of a specific multiple
-have a length between a specific minimum and maximum

The crypto 842-nx has (significant) code in it to handle any alignment
and length input buffers, to match them to what the driver requires.
Would it be better to move that into the crypto code, so that any
crypto compression hw driver can request buffers be specifically
aligned/sized?  I did have to use a header on each compressed buffer
that needed re-alignment or re-sizing, so maybe it's not appropriate
for common crypto compression code.

Since there doesn't seem to be any other hw compression drivers (yet),
maybe it should stay in the 842-nx code, at least for now.  Hopefully
any future compression hw won't have alignment or length multiple
restrictions...

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