Re: [PATCH] crypto: arm/aes-ce: assign err return conditionally
On Wed, Feb 08, 2017 at 02:36:19PM +0100, Nicholas Mc Guire wrote: > As the err value is not used unless there was an error it can be assigned > conditionally here. > > Signed-off-by: Nicholas Mc Guire This patch just adds noise to the commit history. So I'm not going to apply it. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm/aes-ce: assign err return conditionally
On Sat, Feb 11, 2017 at 05:39:46PM +0800, Herbert Xu wrote: > On Wed, Feb 08, 2017 at 02:36:19PM +0100, Nicholas Mc Guire wrote: > > As the err value is not used unless there was an error it can be assigned > > conditionally here. > > > > Signed-off-by: Nicholas Mc Guire > > This patch just adds noise to the commit history. So I'm not going > to apply it. ok - I was not sure about how sensible this sort of changes are either - will drop those code-to-object refactoring experiments then again. thx! hofrat
Re: [PATCH v3 0/3] crypto: time invariant AES for CCM (and CMAC/XCBC)
On 11 February 2017 at 10:53, Herbert Xu wrote: > On Fri, Feb 03, 2017 at 02:49:34PM +, Ard Biesheuvel wrote: >> This series is primarily directed at improving the performance and security >> of CCM on the Rasperry Pi 3. This involves splitting the MAC handling of >> CCM into a separate driver so that we can efficiently replace it by something >> else using the ordinary algo resolution machinery. >> >> Patch #1 adds some testcases for cbcmac(aes), which will be introduced later. >> >> Patch #2 replaces the open coded CBC MAC hashing routines in the CCM driver >> with calls to a cbcmac() hash, and implements a template for producing such >> cbcmac transforms. This eliminates all the fuzzy scatterwalk code as well. >> >> Patch #3 implements cbcmac(aes) using NEON on arm64, and CMAC/XCBC at the >> same time, since it is trivially implemented reusing the same core transform > > All applied. Please send any fixups on top of these patches. Thanks Herbert. I do have a fixup for #2, which currently does not correctly take the alignmask of the MAC's subordinate cipher into account. I will send a fix for that shortly.
Re: [PATCH] crypto: improve gcc optimization flags for serpent and wp512
On Fri, Feb 03, 2017 at 11:33:23PM +0100, Arnd Bergmann wrote: > An ancient gcc bug (first reported in 2003) has apparently resurfaced > on MIPS, where kernelci.org reports an overly large stack frame in the > whirlpool hash algorithm: > > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than > 1024 bytes [-Wframe-larger-than=] Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 0/3] Add Support for Cavium Cryptographic Acceleration Unit
On Tue, Feb 07, 2017 at 02:51:12PM +, George Cherian wrote: > This series adds the support for Cavium Cryptographic Accelerarion Unit (CPT) > CPT is available in Cavium's Octeon-Tx SoC series. > > The series was tested with ecryptfs and dm-crypt for in kernel cryptographic > offload operations. This driver needs a firmware to work, I will be sending > the > firmware to linux-firmware once the driver is accepted. > > Cahnges v5 -> v6 > -- Addressed Sasha Levin's comments. > - Remove open coding of hlist_for_each_entry_safe, instead use > the same. > - Remove the direct access of hlist members > - Remove unwanted argument checks. All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] hwrng: cavium: Use per device name to allow for multiple devices.
On Mon, Feb 06, 2017 at 02:28:46PM -0800, David Daney wrote: > Systems containing the Cavium HW RNG may have one device per NUMA > node. A typical configuration is a 2-node NUMA system, which results > in 2 RNG devices. The hwrng subsystem refuses (and rightly so) to > register more than one device with he same name, so we get failure > messages on these systems. > > Make the hwrng name unique by including the underlying device name. > Also remove spaces from the name to make it possible to switch devices > via the sysfs knobs. > > Signed-off-by: David Daney Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2
On Wed, Feb 01, 2017 at 10:45:02AM -0800, Tim Chen wrote: > > One theory that Mehga and I have is that perhaps the flusher > and regular computaion updates are stepping on each other. > Can you try this patch and see if it helps? Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/3] crypto: time invariant AES for CCM (and CMAC/XCBC)
On Fri, Feb 03, 2017 at 02:49:34PM +, Ard Biesheuvel wrote: > This series is primarily directed at improving the performance and security > of CCM on the Rasperry Pi 3. This involves splitting the MAC handling of > CCM into a separate driver so that we can efficiently replace it by something > else using the ordinary algo resolution machinery. > > Patch #1 adds some testcases for cbcmac(aes), which will be introduced later. > > Patch #2 replaces the open coded CBC MAC hashing routines in the CCM driver > with calls to a cbcmac() hash, and implements a template for producing such > cbcmac transforms. This eliminates all the fuzzy scatterwalk code as well. > > Patch #3 implements cbcmac(aes) using NEON on arm64, and CMAC/XCBC at the > same time, since it is trivially implemented reusing the same core transform All applied. Please send any fixups on top of these patches. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic
On Sun, Feb 05, 2017 at 10:06:12AM +, Ard Biesheuvel wrote: > Instead of unconditionally forcing 4 byte alignment for all generic > chaining modes that rely on crypto_xor() or crypto_inc() (which may > result in unnecessary copying of data when the underlying hardware > can perform unaligned accesses efficiently), make those functions > deal with unaligned input explicitly, but only if the Kconfig symbol > HAVE_EFFICIENT_UNALIGNED_ACCESS is set. This will allow us to drop > the alignmasks from the CBC, CMAC, CTR, CTS, PCBC and SEQIV drivers. > > For crypto_inc(), this simply involves making the 4-byte stride > conditional on HAVE_EFFICIENT_UNALIGNED_ACCESS being set, given that > it typically operates on 16 byte buffers. > > For crypto_xor(), an algorithm is implemented that simply runs through > the input using the largest strides possible if unaligned accesses are > allowed. If they are not, an optimal sequence of memory accesses is > emitted that takes the relative alignment of the input buffers into > account, e.g., if the relative misalignment of dst and src is 4 bytes, > the entire xor operation will be completed using 4 byte loads and stores > (modulo unaligned bits at the start and end). Note that all expressions > involving misalign are simply eliminated by the compiler when > HAVE_EFFICIENT_UNALIGNED_ACCESS is defined. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] crypto: aes - add generic time invariant AES cipher
On Thu, Feb 02, 2017 at 04:37:40PM +, Ard Biesheuvel wrote: > Lookup table based AES is sensitive to timing attacks, which is due to > the fact that such table lookups are data dependent, and the fact that > 8 KB worth of tables covers a significant number of cachelines on any > architecture, resulting in an exploitable correlation between the key > and the processing time for known plaintexts. > > For network facing algorithms such as CTR, CCM or GCM, this presents a > security risk, which is why arch specific AES ports are typically time > invariant, either through the use of special instructions, or by using > SIMD algorithms that don't rely on table lookups. > > For generic code, this is difficult to achieve without losing too much > performance, but we can improve the situation significantly by switching > to an implementation that only needs 256 bytes of table data (the actual > S-box itself), which can be prefetched at the start of each block to > eliminate data dependent latencies. > > This code encrypts at ~25 cycles per byte on ARM Cortex-A57 (while the > ordinary generic AES driver manages 18 cycles per byte on this > hardware). Decryption is substantially slower. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 0/3] Add Broadcom SPU Crypto Driver
On Fri, Feb 03, 2017 at 12:55:31PM -0500, Rob Rice wrote: > Changes in v4: > - Added Rob Herring's Acked-by to patch 1/3 for bindings doc > - In response to Herbert's comment, in ahash_export() and > ahash_import(), only copy the hash state, not state params > related to cipher or aead algos. > - Noticed that hmac_offset in iproc_reqctx_s and spu_hash_params > wasn't really used. So removed. Patches 1-2 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/crc32 - merge CRC32 and PMULL instruction based drivers
On Wed, Feb 01, 2017 at 03:35:40PM +, Ard Biesheuvel wrote: > The PMULL based CRC32 implementation already contains code based on the > separate, optional CRC32 instructions to fallback to when operating on > small quantities of data. We can expose these routines directly on systems > that lack the 64x64 PMULL instructions but do implement the CRC32 ones, > which makes the driver that is based solely on those CRC32 instructions > redundant. So remove it. > > Note that this aligns arm64 with ARM, whose accelerated CRC32 driver > also combines the CRC32 extension based and the PMULL based versions. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: generic/aes - drop alignment requirement
On Thu, Feb 02, 2017 at 03:58:57PM +, Ard Biesheuvel wrote: > The generic AES code exposes a 32-bit align mask, which forces all > users of the code to use temporary buffers or take other measures to > ensure the alignment requirement is adhered to, even on architectures > that don't care about alignment for software algorithms such as this > one. > > So drop the align mask, and fix the code to use get_unaligned_le32() > where appropriate, which will resolve to whatever is optimal for the > architecture. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: linux-next: build warnings after merge of the crypto tree
On Fri, Feb 10, 2017 at 02:12:51PM +1100, Stephen Rothwell wrote: > > I am still getting these warnings ... I have seen no updates to the > crypot tree since Feb 2. Sorry Stephen. I have now applied Arnd's fixes for this problem and it should be pushed out. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: atmel - refine Kconfig dependencies
On Mon, Feb 06, 2017 at 01:32:15PM +0100, Arnd Bergmann wrote:
> With the new authenc support, we get a harmless Kconfig warning:
>
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has
> unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
>
> The problem is that each of the options has slightly different dependencies,
> although they all seem to want the same thing: allow building for real AT91
> targets that actually have the hardware, and possibly for compile testing.
>
> This makes all four options consistent: instead of depending on a particular
> dmaengine implementation, we depend on the ARM platform, CONFIG_COMPILE_TEST
> as an alternative when that is turned off. This makes the 'select' statements
> work correctly.
>
> Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to
> authenc(hmac(shaX), Y(aes)) modes")
> Signed-off-by: Arnd Bergmann
Both patches applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH 1/2] crypto: ccm - honour alignmask of subordinate MAC cipher
The CCM driver was recently updated to defer the MAC part of the algorithm
to a dedicated crypto transform, and a template for instantiating such
transforms was added at the same time.
However, this new cbcmac template fails to take the alignmask of the
encapsulated cipher into account, which may result in buffer addresses
being passed down that are not sufficiently aligned.
So update the code to ensure that the digest buffer in the desc ctx
appears at a sufficiently aligned offset, and tweak the code so that all
calls to crypto_cipher_encrypt_one() operate on this buffer exclusively.
Signed-off-by: Ard Biesheuvel
---
crypto/ccm.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 52e307807ff6..24c26ab052ca 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -58,7 +58,6 @@ struct cbcmac_tfm_ctx {
struct cbcmac_desc_ctx {
unsigned int len;
- u8 dg[];
};
static inline struct crypto_ccm_req_priv_ctx *crypto_ccm_reqctx(
@@ -868,9 +867,10 @@ static int crypto_cbcmac_digest_init(struct shash_desc
*pdesc)
{
struct cbcmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
int bs = crypto_shash_digestsize(pdesc->tfm);
+ u8 *dg = (u8 *)ctx + crypto_shash_descsize(pdesc->tfm) - bs;
ctx->len = 0;
- memset(ctx->dg, 0, bs);
+ memset(dg, 0, bs);
return 0;
}
@@ -883,17 +883,18 @@ static int crypto_cbcmac_digest_update(struct shash_desc
*pdesc, const u8 *p,
struct cbcmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
struct crypto_cipher *tfm = tctx->child;
int bs = crypto_shash_digestsize(parent);
+ u8 *dg = (u8 *)ctx + crypto_shash_descsize(parent) - bs;
while (len > 0) {
unsigned int l = min(len, bs - ctx->len);
- crypto_xor(ctx->dg + ctx->len, p, l);
+ crypto_xor(dg + ctx->len, p, l);
ctx->len +=l;
len -= l;
p += l;
if (ctx->len == bs) {
- crypto_cipher_encrypt_one(tfm, ctx->dg, ctx->dg);
+ crypto_cipher_encrypt_one(tfm, dg, dg);
ctx->len = 0;
}
}
@@ -908,12 +909,12 @@ static int crypto_cbcmac_digest_final(struct shash_desc
*pdesc, u8 *out)
struct cbcmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
struct crypto_cipher *tfm = tctx->child;
int bs = crypto_shash_digestsize(parent);
+ u8 *dg = (u8 *)ctx + crypto_shash_descsize(parent) - bs;
if (ctx->len)
- crypto_cipher_encrypt_one(tfm, out, ctx->dg);
- else
- memcpy(out, ctx->dg, bs);
+ crypto_cipher_encrypt_one(tfm, dg, dg);
+ memcpy(out, dg, bs);
return 0;
}
@@ -969,7 +970,8 @@ static int cbcmac_create(struct crypto_template *tmpl,
struct rtattr **tb)
inst->alg.base.cra_blocksize = 1;
inst->alg.digestsize = alg->cra_blocksize;
- inst->alg.descsize = sizeof(struct cbcmac_desc_ctx) +
+ inst->alg.descsize = ALIGN(sizeof(struct cbcmac_desc_ctx),
+ alg->cra_alignmask + 1) +
alg->cra_blocksize;
inst->alg.base.cra_ctxsize = sizeof(struct cbcmac_tfm_ctx);
--
2.7.4
[PATCH 2/2] crypto: ccm - drop unnecessary minimum 32-bit alignment
The CCM driver forces 32-bit alignment even if the underlying ciphers don't care about alignment. This is because crypto_xor() used to require this, but since this is no longer the case, drop the hardcoded minimum of 32 bits. Signed-off-by: Ard Biesheuvel --- crypto/ccm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/crypto/ccm.c b/crypto/ccm.c index 24c26ab052ca..442848807a52 100644 --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -525,8 +525,7 @@ static int crypto_ccm_create_common(struct crypto_template *tmpl, ctr->base.cra_priority) / 2; inst->alg.base.cra_blocksize = 1; inst->alg.base.cra_alignmask = mac->base.cra_alignmask | - ctr->base.cra_alignmask | - (__alignof__(u32) - 1); + ctr->base.cra_alignmask; inst->alg.ivsize = 16; inst->alg.chunksize = crypto_skcipher_alg_chunksize(ctr); inst->alg.maxauthsize = 16; -- 2.7.4
