Re: [PATCH v6 1/5] lib: Update LZ4 compressor module
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
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)
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
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
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