Re: [PATCH] crypto: chacha20 - Fix chacha20_block() keystream alignment (again)
Hi Yann,
On Wed, Sep 12, 2018 at 11:50:00AM +0200, Yann Droneaud wrote:
> Hi,
>
> Le mardi 11 septembre 2018 à 20:05 -0700, Eric Biggers a écrit :
> > From: Eric Biggers
> >
> > In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> > chacha20_block()"), I had missed that chacha20_block() can be called
> > directly on the buffer passed to get_random_bytes(), which can have any
> > alignment. So, while my commit didn't break anything, it didn't fully
> > solve the alignment problems.
> >
> > Revert my solution and just update chacha20_block() to use
> > put_unaligned_le32(), so the output buffer need not be aligned.
> > This is simpler, and on many CPUs it's the same speed.
> >
> > But, I kept the 'tmp' buffers in extract_crng_user() and
> > _get_random_bytes() 4-byte aligned, since that alignment is actually
> > needed for _crng_backtrack_protect() too.
> >
> > Reported-by: Stephan Müller
> > Cc: Theodore Ts'o
> > Signed-off-by: Eric Biggers
> > ---
> > crypto/chacha20_generic.c | 7 ---
> > drivers/char/random.c | 24
> > include/crypto/chacha20.h | 3 +--
> > lib/chacha20.c| 6 +++---
> > 4 files changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/crypto/chacha20_generic.c b/crypto/chacha20_generic.c
> > index e451c3cb6a56..3ae96587caf9 100644
> > --- a/crypto/chacha20_generic.c
> > +++ b/crypto/chacha20_generic.c
> > @@ -18,20 +18,21 @@
> > static void chacha20_docrypt(u32 *state, u8 *dst, const u8 *src,
> > unsigned int bytes)
> > {
> > - u32 stream[CHACHA20_BLOCK_WORDS];
> > + /* aligned to potentially speed up crypto_xor() */
> > + u8 stream[CHACHA20_BLOCK_SIZE] __aligned(sizeof(long));
> >
> > if (dst != src)
> > memcpy(dst, src, bytes);
> >
> > while (bytes >= CHACHA20_BLOCK_SIZE) {
> > chacha20_block(state, stream);
> > - crypto_xor(dst, (const u8 *)stream, CHACHA20_BLOCK_SIZE);
> > + crypto_xor(dst, stream, CHACHA20_BLOCK_SIZE);
> > bytes -= CHACHA20_BLOCK_SIZE;
> > dst += CHACHA20_BLOCK_SIZE;
> > }
> > if (bytes) {
> > chacha20_block(state, stream);
> > - crypto_xor(dst, (const u8 *)stream, bytes);
> > + crypto_xor(dst, stream, bytes);
> > }
> > }
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index bf5f99fc36f1..d22d967c50f0 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1003,7 +1003,7 @@ static void extract_crng(__u32
> > out[CHACHA20_BLOCK_WORDS])
> > * enough) to mutate the CRNG key to provide backtracking protection.
> > */
> > static void _crng_backtrack_protect(struct crng_state *crng,
> > - __u32 tmp[CHACHA20_BLOCK_WORDS], int used)
> > + __u8 tmp[CHACHA20_BLOCK_SIZE], int used)
> > {
> > unsigned long flags;
> > __u32 *s, *d;
> > @@ -1015,14 +1015,14 @@ static void _crng_backtrack_protect(struct
> > crng_state *crng,
> > used = 0;
> > }
> > spin_lock_irqsave(>lock, flags);
> > - s = [used / sizeof(__u32)];
> > + s = (__u32 *) [used];
>
> This introduces a alignment issue: tmp is not aligned for __u32, but is
> dereferenced as such later.
>
> > d = >state[4];
> > for (i=0; i < 8; i++)
> > *d++ ^= *s++;
> > spin_unlock_irqrestore(>lock, flags);
> > }
> >
>
I explained this in the patch; the callers ensure the buffer is aligned.
- Eric
[PATCH] crypto: caam/jr - fix ablkcipher_edesc pointer arithmetic
In some cases the zero-length hw_desc array at the end of
ablkcipher_edesc struct requires for 4B of tail padding.
Due to tail padding and the way pointers to S/G table and IV
are computed:
edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
desc_bytes;
iv = (u8 *)edesc->hw_desc + desc_bytes + sec4_sg_bytes;
first 4 bytes of IV are overwritten by S/G table.
Update computation of pointer to S/G table to rely on offset of hw_desc
member and not on sizeof() operator.
Cc: # 4.13+
Fixes: 115957bb3e59 ("crypto: caam - fix IV DMA mapping and updating")
Signed-off-by: Horia Geantă
---
This is for crypto-2.6 tree / current v4.19 release cycle.
Note that it will create merge conflicts later in v4.20 due to commits
cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation")
5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion")
from cryptodev-2.6 tree.
Should I send a similar fix for skcipher-based caam/jr driver
on cryptodev-2.6 tree, or will this be handled while solving the conflicts?
drivers/crypto/caam/caamalg.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index d67667970f7e..ec40f991e6c6 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1553,8 +1553,8 @@ static struct ablkcipher_edesc
*ablkcipher_edesc_alloc(struct ablkcipher_request
edesc->src_nents = src_nents;
edesc->dst_nents = dst_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
- edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
-desc_bytes;
+ edesc->sec4_sg = (struct sec4_sg_entry *)((u8 *)edesc->hw_desc +
+ desc_bytes);
edesc->iv_dir = DMA_TO_DEVICE;
/* Make sure IV is located in a DMAable area */
@@ -1757,8 +1757,8 @@ static struct ablkcipher_edesc
*ablkcipher_giv_edesc_alloc(
edesc->src_nents = src_nents;
edesc->dst_nents = dst_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
- edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
-desc_bytes;
+ edesc->sec4_sg = (struct sec4_sg_entry *)((u8 *)edesc->hw_desc +
+ desc_bytes);
edesc->iv_dir = DMA_FROM_DEVICE;
/* Make sure IV is located in a DMAable area */
--
2.16.2
Re: [PATCH] gcmaes_crypt_by_sg: don't use GFP_ATOMIC allocation if the request doesn't cross a page
On Wed, Sep 05, 2018 at 09:18:43AM -0400, Mikulas Patocka wrote: > This patch fixes gcmaes_crypt_by_sg so that it won't use memory > allocation if the data doesn't cross a page boundary. > > Authenticated encryption may be used by dm-crypt. If the encryption or > decryption fails, it would result in I/O error and filesystem corruption. > The function gcmaes_crypt_by_sg is using GFP_ATOMIC allocation that can > fail anytime. This patch fixes the logic so that it won't attempt the > failing allocation if the data doesn't cross a page boundary. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org 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: [RFC PATCH cryptodev] crc-t10dif: crc_t10dif_mutex can be static
On Wed, Sep 05, 2018 at 01:52:44AM +0800, kbuild test robot wrote:
>
> Fixes: b76377543b73 ("crc-t10dif: Pick better transform if one becomes
> available")
> Signed-off-by: kbuild test robot
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: x86/aegis,morus - Do not require OSXSAVE for SSE2
On Wed, Sep 05, 2018 at 09:26:41AM +0200, Ondrej Mosnacek wrote:
> It turns out OSXSAVE needs to be checked only for AVX, not for SSE.
> Without this patch the affected modules refuse to load on CPUs with SSE2
> but without AVX support.
>
> Fixes: 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID
> checks")
> Cc: # 4.18
> Reported-by: Zdenek Kaspar
> Signed-off-by: Ondrej Mosnacek
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: padlock-aes: Add ecx to outputs for rep instructions
On Fri, Sep 07, 2018 at 02:57:42AM +0100, Ben Hutchings wrote:
> The current constraints for inline "rep xcrypt*" instructions mark ecx
> as an input only. The compiler can therefore assume wrongly that ecx
> holds the same value afterward, but in reality it will contain 0.
>
> This previously led to data corruption, which was fixed around by
> commit 46d8c4b28652 ("crypto: padlock-aes - Fix Nano workaround data
> corruption"). But a future compiler or different optimisation
> configuration could reintroduce the problem. Update the constraints
> to avoid this.
>
> Fixes: a76c1c23d0c3 ("crypto: padlock-aes - work around Nano CPU ...")
> Fixes: 46d8c4b28652 ("crypto: padlock-aes - Fix Nano workaround data ...")
> Signed-off-by: Ben Hutchings
> ---
> This is totally untested, so don't assume I know what I'm talking
> about. :-)
Could you please test it by combining this patch with a revert
of my fix to confirm that it actually works?
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
