linux-kernel - Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

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: <20150922122117.GA11522@gondor.apana.org.au>
Date:	Tue, 22 Sep 2015 20:21:17 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Dan Streetman <ddstreet@...e.org>
Cc:	Haren Myneni <haren@...ux.vnet.ibm.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Haren Myneni <hbabu@...ibm.com>
Subject: Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for
 nx842

On Mon, Sep 21, 2015 at 11:21:14AM -0400, Dan Streetman wrote:
> 
> As far as the hw and sw drivers producing the exact same output, I
> don't think that's possible with the current hw and sw drivers,
> because the hw driver may have to add a header to the actual byte
> stream that the hw creates, depending on buffer alignment and size
> (the hw has specific restrictions).  Currently, the sw driver doesn't
> understand that header that the 842 hw driver creates, although that
> could be added to the sw driver.  And, the hw driver skips adding the
> header if the buffers are correctly aligned/sized, which would result
> in a test vector failure if it doesn't align the buffer the same way
> each time.

I guess they don't have to be exactly the same.  As long as each
can take the output of the other and compress/decompress them it
should be fine.

> Also, it might be a good time to add what we talked about a while ago,
> to push the alignment/size restrictions into the crypto compression
> layer, by adding cra_alignmask and cra_blocksize support to
> crypto/compress.c.  Since the 842 hw has requirements not only for
> specific alignment and min/max sizes, but also a requirement for
> specific length multiple (i.e. must be !(len % 8)) it might be
> worthwhile to also add a cra_sizemodulo or something like that.
> However, if the common crypto alignment/size handling code allows any
> alignment/size buffers (instead of just returning error for mis-sized
> buffers), I think a common crypto header would need to be added in
> cases of mis-sizing, which may not be appropriate for common code.
> Alternately, the common crypto code could just return error for
> mis-sized buffers; users of the crypto comp api would just have to
> check crypto_tfm_alg_blocksize() before calling.

I'd like to see another hardware implementation before we start
moving this into the API.

> In case I haven't said it before, I really hate how the 842 hw
> requires specific alignment and sizing.  How hard is it to add support
> for any alignment/size in the hw?!?

Another option is to use a software fallback for the cases that
the hardware can't handle.

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/