Re: [PATCH v6 1/5] lib: Update LZ4 compressor module

[Jonathan Corbet]

On Fri, 27 Jan 2017 23:02:00 +0100
Sven Schmidt <4ssch...@informatik.uni-hamburg.de> wrote:

I have one quick question...

>  /*
> + * LZ4_compress_default()
> + *   Compresses 'sourceSize' bytes from buffer 'source'
> + *   into already allocated 'dest' buffer of size 'maxOutputSize'.
> + *   Compression is guaranteed to succeed if
> + *   'maxOutputSize' >= LZ4_compressBound(inputSize).
> + *   It also runs faster, so it's a recommended setting.
> + *   If the function cannot compress 'source'
> + *   into a more limited 'dest' budget,
> + *   compression stops *immediately*,
> + *   and the function result is zero.
> + *   As a consequence, 'dest' content is not valid.
> + *
> + *   source   : source address of the original data
> + *   dest : output buffer address
> + * of the compressed data
> + *   inputSize: Max supported value is
> + * LZ4_MAX_INPUT_SIZE
> + *   maxOutputSize: full or partial size of buffer 'dest'
> + * (which must be already allocated)
> + *   workmem  : address of the working memory.
> + * This requires 'workmem' of size LZ4_MEM_COMPRESS.
> + *   return   : the number of bytes written into buffer 'dest'
> + *   (necessarily <= maxOutputSize) or 0 if compression fails
> + */
> +int LZ4_compress_default(const char *source, char *dest, int inputSize,
> + int maxOutputSize, void *wrkmem);

Is there any chance you could format these as kerneldoc comments?  You're
not too far from it now, and that would allow the LZ4 interface to be
pulled into the documentation.

Thanks,

jon

Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2

[Tim Chen]

On Tue, 2017-01-31 at 14:16 +0100, Dmitry Vyukov wrote:
> Hello,
> 
> I am getting the following reports with low frequency while running
> syzkaller fuzzer. Unfortunately they are not reproducible and happen
> in a background thread, so it is difficult to extract any context on
> my side. I see only few such crashes per week, so most likely it is
> some hard to trigger data race. The following reports are from mmotm
> tree, commits 00e20cfc2bf04a0cbe1f5405f61c8426f43eee84 and
> fff7e71eac7788904753136f09bcad7471f7799e. Any ideas as to how this can
> happen?

Wonder if there is a race between the flusher thread that flush out
existing jobs if we don't have incoming jobs for a while and computation
via mcryptd.  Maybe the flusher fires at the same time when there is
a new job arriving.

Let Megha and I think a bit about it to come up with a patch to see
if that's the case.

Tim

> 
> BUG: unable to handle kernel NULL pointer dereference at 0060
> IP: [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> PGD 1d2395067 [  220.874864] PUD 1d2860067
> Oops: 0002 [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 516 Comm: kworker/0:1 Not tainted 4.9.0 #4
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Workqueue: crypto mcryptd_queue_worker
> task: 8801d9f346c0 task.stack: 8801d9f08000
> RIP: 0010:[]  []
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:8801d9f0eef8  EFLAGS: 00010202
> RAX:  RBX: 8801d7db1190 RCX: 0006
> RDX: 0001 RSI: 8801d9f34ee8 RDI: 8801d7db1040
> RBP: 8801d9f0f258 R08: 0001 R09: 0001
> R10: 0002 R11: 0003 R12: 8801d9f0f230
> R13: 8801c8bbc4e0 R14: 8801c8bbc530 R15: 8801d9f0ef70
> FS:  () GS:8801dc00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0060 CR3: 0001cc15a000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Stack:
>  8801d7db1040 813fa207 dc00 e8c0f238
>  0002 11003b3e1dea e8c0f218 8801d9f0f190
>  0282 e8c0f140 e8c0f220 41b58ab3
> Call Trace:
>  [] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
>  [] crypto_ahash_update include/crypto/hash.h:512 [inline]
>  [] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
>  [] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
>  [] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
>  [] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
>  [] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
>  [] kthread+0x323/0x3e0 kernel/kthread.c:209
>  [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
> Code: 49 0f 42 d3 48 f7 c2 f0 ff ff ff 0f 85 9a 00 00 00 48 83 e2 0f
> 48 6b da 08 48 8d 9c 1f 48 01 00 00 48 8b 03 48 c7 03 00 00 00 00 
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP  [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
>  RSP 
> CR2: 0060
> ---[ end trace 139fd4cda5dfe2c4 ]---
> 
> BUG: unable to handle kernel NULL pointer dereference at 0060
> IP: [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> PGD 1c68ad067 [  624.973638] PUD 1d485a067
> Oops: 0002 [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 517 Comm: kworker/0:1 Not tainted 4.9.0 #3
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Workqueue: crypto mcryptd_queue_worker
> task: 8801d9e64700 task.stack: 8801d9838000
> RIP: 0010:[]  []
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:8801d983eef8  EFLAGS: 00010202
> RAX:  RBX: 8801d7d96950 RCX: 0006
> RDX: 0001 RSI: 8801d9e64f28 RDI: 8801d7d96800
> RBP: 8801d983f258 R08: 0001 R09: 0001
> R10: 0002 R11: 0003 R12: 8801d983f230
> R13: 8801b67f5720 R14: 8801b67f5770 R15: 8801d983ef70
> FS:  () GS:8801dc00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0060 CR3: 0001cee58000 CR4: 001406f0
> Stack:
>  8801d7d96800 813fa207 dc00 e8c0f238
>  0002 11003b307dea e8c0f218 8801d983f190
>  0282 e8c0f140 e8c0f220 41b58ab3
> Call Trace:

Re: [PATCH v2 0/4] crypto: time invariant AES for CCM (and GCM/CTR)

[Ard Biesheuvel]

On 28 January 2017 at 23:33, 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
> transforms. This eliminates all the fuzzy scatterwalk code as well.
>
> Patch #3 implements cbcmac(aes) using NEON on arm64
>
> Patch #4 is an RFC patch that implements ctr(aes) and cbcmac(aes) in a way
> that is intended to eliminate observeable data dependent latencies in AES
> processing, by replacing the usual 16 KB of lookup tables with a single
> Sbox that is prefetched before processing each block. It is 50% slower than
> generic AES, but this may be acceptable in many cases.
>
> Changes since v1:
> - remove ilen, and add missing flags assignment (#2)
> - deal with zero cryptlen (#2)
> - use correctly sized dg[] array in desc ctx (#3, #4)
> - fix bug in update routine (#3)
> - various other tweaks
>
> Ard Biesheuvel (4):
>   crypto: testmgr - add test cases for cbcmac(aes)
>   crypto: ccm - switch to separate cbcmac driver
>   crypto: arm64/aes - add NEON and Crypto Extension CBC-MAC driver
>   crypto: aes - add generic time invariant AES for CTR/CCM/GCM
>

I have updated versions of these that make use of the alignment
agnostic crypto_xor(). I will respin these once that patch gets
discussed/merged/rejected/etc
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: qat - zero esram only for DH85x devices

[Giovanni Cabiddu]

Hi Herbert,

On Fri, Dec 30, 2016 at 08:20:11PM +0800, Herbert Xu wrote:
> On Thu, Dec 22, 2016 at 03:00:24PM +, Giovanni Cabiddu wrote:
> > Zero embedded ram in DH85x devices. This is not
> > needed for newer generations as it is done by HW.
> > 
> > Signed-off-by: Giovanni Cabiddu 
> 
> Patch applied.  Thanks.
We realized that two patches I submitted in December (and now applied
to cryptodev-2.6) are needed to avoid a null pointer dereference
when loading the qat driver on some specific c62x devices:

841d6d10b38a2508c640ce: crypto: qat - zero esram only for DH85x devices
4f78ce870a4da0cf4db265: crypto: qat - fix bar discovery for c62x

This problem was introduced in 4.5 when we sent the c62x driver and
we recommend it should go to the stable kernels, 4.8.17 and 4.9.6.
Should I re-send these two patches to stable after they are merged
in Linus’ tree?

Thanks,

-- 
Giovanni
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2

[Dmitry Vyukov]

Hello,

I am getting the following reports with low frequency while running
syzkaller fuzzer. Unfortunately they are not reproducible and happen
in a background thread, so it is difficult to extract any context on
my side. I see only few such crashes per week, so most likely it is
some hard to trigger data race. The following reports are from mmotm
tree, commits 00e20cfc2bf04a0cbe1f5405f61c8426f43eee84 and
fff7e71eac7788904753136f09bcad7471f7799e. Any ideas as to how this can
happen?

BUG: unable to handle kernel NULL pointer dereference at 0060
IP: [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
PGD 1d2395067 [  220.874864] PUD 1d2860067
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 516 Comm: kworker/0:1 Not tainted 4.9.0 #4
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: crypto mcryptd_queue_worker
task: 8801d9f346c0 task.stack: 8801d9f08000
RIP: 0010:[]  []
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:8801d9f0eef8  EFLAGS: 00010202
RAX:  RBX: 8801d7db1190 RCX: 0006
RDX: 0001 RSI: 8801d9f34ee8 RDI: 8801d7db1040
RBP: 8801d9f0f258 R08: 0001 R09: 0001
R10: 0002 R11: 0003 R12: 8801d9f0f230
R13: 8801c8bbc4e0 R14: 8801c8bbc530 R15: 8801d9f0ef70
FS:  () GS:8801dc00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0060 CR3: 0001cc15a000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 8801d7db1040 813fa207 dc00 e8c0f238
 0002 11003b3e1dea e8c0f218 8801d9f0f190
 0282 e8c0f140 e8c0f220 41b58ab3
Call Trace:
 [] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
 [] crypto_ahash_update include/crypto/hash.h:512 [inline]
 [] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
 [] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
 [] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
 [] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
 [] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
 [] kthread+0x323/0x3e0 kernel/kthread.c:209
 [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
Code: 49 0f 42 d3 48 f7 c2 f0 ff ff ff 0f 85 9a 00 00 00 48 83 e2 0f
48 6b da 08 48 8d 9c 1f 48 01 00 00 48 8b 03 48 c7 03 00 00 00 00 
40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
RIP  [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
 RSP 
CR2: 0060
---[ end trace 139fd4cda5dfe2c4 ]---

BUG: unable to handle kernel NULL pointer dereference at 0060
IP: [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
PGD 1c68ad067 [  624.973638] PUD 1d485a067
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 517 Comm: kworker/0:1 Not tainted 4.9.0 #3
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: crypto mcryptd_queue_worker
task: 8801d9e64700 task.stack: 8801d9838000
RIP: 0010:[]  []
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:8801d983eef8  EFLAGS: 00010202
RAX:  RBX: 8801d7d96950 RCX: 0006
RDX: 0001 RSI: 8801d9e64f28 RDI: 8801d7d96800
RBP: 8801d983f258 R08: 0001 R09: 0001
R10: 0002 R11: 0003 R12: 8801d983f230
R13: 8801b67f5720 R14: 8801b67f5770 R15: 8801d983ef70
FS:  () GS:8801dc00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0060 CR3: 0001cee58000 CR4: 001406f0
Stack:
 8801d7d96800 813fa207 dc00 e8c0f238
 0002 11003b307dea e8c0f218 8801d983f190
 0282 e8c0f140 e8c0f220 41b58ab3
Call Trace:
 [] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
 [] crypto_ahash_update include/crypto/hash.h:512 [inline]
 [] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
 [] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
 [] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
 [] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
 [] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
 [] kthread+0x323/0x3e0 kernel/kthread.c:209
 [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
Code: 49 0f 42 d3 48 f7 c2 f0 ff ff ff 0f 85 9a