* Re: [PATCH v3 1/3] crypto: brcm: DT documentation for Broadcom SPU hardware
From: Rob Herring @ 2017-01-30 20:18 UTC (permalink / raw)
To: Rob Rice
Cc: Herbert Xu, David S. Miller, Mark Rutland, linux-crypto,
devicetree, linux-kernel, bcm-kernel-feedback-list,
Catalin Marinas, Will Deacon, linux-arm-kernel, Steve Lin
In-Reply-To: <1485362689-11294-2-git-send-email-rob.rice@broadcom.com>
On Wed, Jan 25, 2017 at 11:44:47AM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto hardware.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
> ---
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/3] Add Broadcom SPU Crypto Driver
From: Florian Fainelli @ 2017-01-30 23:35 UTC (permalink / raw)
To: Rob Rice, Herbert Xu, David S. Miller, Rob Herring, Mark Rutland,
linux-crypto, devicetree, linux-kernel, bcm-kernel-feedback-list,
Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <1485362689-11294-1-git-send-email-rob.rice@broadcom.com>
On 01/25/2017 08:44 AM, Rob Rice wrote:
> Changes in v3:
> - rebase to 4.10-rc3 in cryptodev-2.6 tree
> - in bindings doc, list all valid compatibility strings
> - rename DT nodes "crypto" rather than "spu-crypto"
> - include a separate DT node for each SPU hardware block. Previously,
> there was a single SPU node listing a register range for each
> hw block.
> - select hash algos in Kconfig. Driver HMAC implementation uses hash
> sw algos for inner and outer hashes.
> - Fix crash for AES CCM decrypt when AAD and data are both empty
>
> Change in v2:
> - select CRYPTO_DES in Kconfig
>
> The Broadcom SPU crypto driver provides access to SPU hardware
> for symmetric crypto offload. The driver supports ablkcipher,
> ahash, and aead operations. The driver supports several
> Broadcom SoCs with different revisions of the SPU hardware.
> The driver supports SPU-M and SPU2 hardware revisions, and
> a couple versions of each hw revision, each version with minor
> differences.
Herbert, can you take patches 1-2, and I will take patch 3 through my
arm64-soc git pull requests? Thanks!!
>
> Rob Rice (3):
> crypto: brcm: DT documentation for Broadcom SPU hardware
> crypto: brcm: Add Broadcom SPU driver
> arm64: dts: ns2: Add Broadcom SPU driver DT entry.
>
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 22 +
> arch/arm64/boot/dts/broadcom/ns2.dtsi | 24 +
> drivers/crypto/Kconfig | 15 +
> drivers/crypto/Makefile | 2 +
> drivers/crypto/bcm/Makefile | 15 +
> drivers/crypto/bcm/cipher.c | 4955 ++++++++++++++++++++
> drivers/crypto/bcm/cipher.h | 475 ++
> drivers/crypto/bcm/spu.c | 1252 +++++
> drivers/crypto/bcm/spu.h | 288 ++
> drivers/crypto/bcm/spu2.c | 1402 ++++++
> drivers/crypto/bcm/spu2.h | 228 +
> drivers/crypto/bcm/spum.h | 174 +
> drivers/crypto/bcm/util.c | 581 +++
> drivers/crypto/bcm/util.h | 116 +
> 14 files changed, 9549 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> create mode 100644 drivers/crypto/bcm/Makefile
> create mode 100644 drivers/crypto/bcm/cipher.c
> create mode 100644 drivers/crypto/bcm/cipher.h
> create mode 100644 drivers/crypto/bcm/spu.c
> create mode 100644 drivers/crypto/bcm/spu.h
> create mode 100644 drivers/crypto/bcm/spu2.c
> create mode 100644 drivers/crypto/bcm/spu2.h
> create mode 100644 drivers/crypto/bcm/spum.h
> create mode 100644 drivers/crypto/bcm/util.c
> create mode 100644 drivers/crypto/bcm/util.h
>
--
Florian
^ permalink raw reply
* crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2
From: Dmitry Vyukov @ 2017-01-31 13:16 UTC (permalink / raw)
To: Herbert Xu, David Miller, linux-crypto, LKML, megha.dey,
fenghua.yu, tim.c.chen
Cc: syzkaller
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 0000000000000060
IP: [<ffffffff813fc09e>] 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: ffff8801d9f346c0 task.stack: ffff8801d9f08000
RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:ffff8801d9f0eef8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8801d7db1190 RCX: 0000000000000006
RDX: 0000000000000001 RSI: ffff8801d9f34ee8 RDI: ffff8801d7db1040
RBP: ffff8801d9f0f258 R08: 0000000100000000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801d9f0f230
R13: ffff8801c8bbc4e0 R14: ffff8801c8bbc530 R15: ffff8801d9f0ef70
FS: 0000000000000000(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 00000001cc15a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffff8801d7db1040 ffffffff813fa207 dffffc0000000000 ffffe8ffffc0f238
0000000000000002 1ffff1003b3e1dea ffffe8ffffc0f218 ffff8801d9f0f190
0000000000000282 ffffe8ffffc0f140 ffffe8ffffc0f220 0000000041b58ab3
Call Trace:
[<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
[<ffffffff8219d4ad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
[<ffffffff8219d4ad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
[<ffffffff8219d4ad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
[<ffffffff8219c99f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
[<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
[<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
[<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff8436fbaa>] 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 <c7>
40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP <ffff8801d9f0eef8>
CR2: 0000000000000060
---[ end trace 139fd4cda5dfe2c4 ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
IP: [<ffffffff813fc09e>] 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: ffff8801d9e64700 task.stack: ffff8801d9838000
RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:ffff8801d983eef8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8801d7d96950 RCX: 0000000000000006
RDX: 0000000000000001 RSI: ffff8801d9e64f28 RDI: ffff8801d7d96800
RBP: ffff8801d983f258 R08: 0000000100000000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801d983f230
R13: ffff8801b67f5720 R14: ffff8801b67f5770 R15: ffff8801d983ef70
FS: 0000000000000000(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 00000001cee58000 CR4: 00000000001406f0
Stack:
ffff8801d7d96800 ffffffff813fa207 dffffc0000000000 ffffe8ffffc0f238
0000000000000002 1ffff1003b307dea ffffe8ffffc0f218 ffff8801d983f190
0000000000000282 ffffe8ffffc0f140 ffffe8ffffc0f220 0000000041b58ab3
Call Trace:
[<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
[<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
[<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
[<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
[<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
[<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
[<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
[<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff8436fbea>] 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 <c7>
40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP <ffff8801d983eef8>
CR2: 0000000000000060
---[ end trace 76403e033556dcb7 ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
IP: [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
PGD 1d6242067 [ 226.248182] PUD 1d2093067
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 1788 Comm: kworker/1:2 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: ffff8801cc3ee100 task.stack: ffff8801cd068000
RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:ffff8801cd06eef8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8801d7dc3c10 RCX: 0000000000000006
RDX: 0000000000000001 RSI: ffff8801cc3ee928 RDI: ffff8801d7dc3ac0
RBP: ffff8801cd06f258 R08: 0000000100000000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801cd06f230
R13: ffff8801c6eb9aa0 R14: ffff8801c6eb9af0 R15: ffff8801cd06ef70
FS: 0000000000000000(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 00000001d6201000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffff8801d7dc3ac0 ffffffff813fa207 dffffc0000000000 ffffe8ffffd0f238
0000000000000002 1ffff10039a0ddea ffffe8ffffd0f218 ffff8801cd06f190
0000000000000282 ffffe8ffffd0f140 ffffe8ffffd0f220 0000000041b58ab3
Call Trace:
[<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
[<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
[<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
[<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
[<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
[<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
[<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
[<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff8436fbea>] 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 <c7>
40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP <ffff8801cd06eef8>
CR2: 0000000000000060
---[ end trace 47d3302a6c62cfbc ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
IP: [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
PGD 1ccad4067 [ 32.785777] PUD 1cb96c067
Oops: 0002 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 3231 Comm: kworker/1:2 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: ffff8801cf472700 task.stack: ffff8801ce848000
RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP: 0018:ffff8801ce84eef8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8801d7c82950 RCX: 0000000000000006
RDX: 0000000000000001 RSI: ffff8801cf472f28 RDI: ffff8801d7c82800
RBP: ffff8801ce84f258 R08: 0000000100000000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801ce84f230
R13: ffff8801c970e760 R14: ffff8801c970e7b0 R15: ffff8801ce84ef70
FS: 0000000000000000(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 00000001ca654000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffff8801d7c82800 ffffffff813fa207 dffffc0000000000 ffffe8ffffd0f238
0000000000000002 1ffff10039d09dea ffffe8ffffd0f218 ffff8801ce84f190
0000000000000282 ffffe8ffffd0f140 ffffe8ffffd0f220 0000000041b58ab3
Call Trace:
[<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
arch/x86/crypto/sha512-mb/sha512_mb.c:588
[<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
[<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
[<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
[<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
[<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
[<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
[<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff8436fbea>] 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 <c7>
40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
RSP <ffff8801ce84eef8>
CR2: 0000000000000060
---[ end trace 3af8184eabd21203 ]---
^ permalink raw reply
* Re: [PATCH] crypto: qat - zero esram only for DH85x devices
From: Giovanni Cabiddu @ 2017-01-31 13:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, giovanni.cabiddu
In-Reply-To: <20161230122011.GE15832@gondor.apana.org.au>
Hi Herbert,
On Fri, Dec 30, 2016 at 08:20:11PM +0800, Herbert Xu wrote:
> On Thu, Dec 22, 2016 at 03:00:24PM +0000, 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 <giovanni.cabiddu@intel.com>
>
> 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
^ permalink raw reply
* Re: [PATCH v2 0/4] crypto: time invariant AES for CCM (and GCM/CTR)
From: Ard Biesheuvel @ 2017-01-31 18:30 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, Herbert Xu, Ard Biesheuvel
In-Reply-To: <1485646413-17491-1-git-send-email-ard.biesheuvel@linaro.org>
On 28 January 2017 at 23:33, Ard Biesheuvel <ard.biesheuvel@linaro.org> 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
^ permalink raw reply
* Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2
From: Tim Chen @ 2017-01-31 18:51 UTC (permalink / raw)
To: Dmitry Vyukov, Herbert Xu, David Miller, linux-crypto, LKML,
megha.dey, fenghua.yu
Cc: syzkaller
In-Reply-To: <CACT4Y+Z6_x2smshuSgQx0wA+g0H+5dJsF23UqYb9Z_WkDUvwcw@mail.gmail.com>
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 0000000000000060
> IP: [<ffffffff813fc09e>] 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: ffff8801d9f346c0 task.stack: ffff8801d9f08000
> RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:ffff8801d9f0eef8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8801d7db1190 RCX: 0000000000000006
> RDX: 0000000000000001 RSI: ffff8801d9f34ee8 RDI: ffff8801d7db1040
> RBP: ffff8801d9f0f258 R08: 0000000100000000 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801d9f0f230
> R13: ffff8801c8bbc4e0 R14: ffff8801c8bbc530 R15: ffff8801d9f0ef70
> FS: 0000000000000000(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 00000001cc15a000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Stack:
> ffff8801d7db1040 ffffffff813fa207 dffffc0000000000 ffffe8ffffc0f238
> 0000000000000002 1ffff1003b3e1dea ffffe8ffffc0f218 ffff8801d9f0f190
> 0000000000000282 ffffe8ffffc0f140 ffffe8ffffc0f220 0000000041b58ab3
> Call Trace:
> [<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
> [<ffffffff8219d4ad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
> [<ffffffff8219d4ad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
> [<ffffffff8219d4ad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
> [<ffffffff8219c99f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
> [<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
> [<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
> [<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff8436fbaa>] 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 <c7>
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP <ffff8801d9f0eef8>
> CR2: 0000000000000060
> ---[ end trace 139fd4cda5dfe2c4 ]---
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
> IP: [<ffffffff813fc09e>] 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: ffff8801d9e64700 task.stack: ffff8801d9838000
> RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:ffff8801d983eef8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8801d7d96950 RCX: 0000000000000006
> RDX: 0000000000000001 RSI: ffff8801d9e64f28 RDI: ffff8801d7d96800
> RBP: ffff8801d983f258 R08: 0000000100000000 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801d983f230
> R13: ffff8801b67f5720 R14: ffff8801b67f5770 R15: ffff8801d983ef70
> FS: 0000000000000000(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 00000001cee58000 CR4: 00000000001406f0
> Stack:
> ffff8801d7d96800 ffffffff813fa207 dffffc0000000000 ffffe8ffffc0f238
> 0000000000000002 1ffff1003b307dea ffffe8ffffc0f218 ffff8801d983f190
> 0000000000000282 ffffe8ffffc0f140 ffffe8ffffc0f220 0000000041b58ab3
> Call Trace:
> [<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
> [<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
> [<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
> [<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
> [<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
> [<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
> [<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
> [<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff8436fbea>] 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 <c7>
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP <ffff8801d983eef8>
> CR2: 0000000000000060
> ---[ end trace 76403e033556dcb7 ]---
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
> IP: [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> PGD 1d6242067 [ 226.248182] PUD 1d2093067
> Oops: 0002 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 1788 Comm: kworker/1:2 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: ffff8801cc3ee100 task.stack: ffff8801cd068000
> RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:ffff8801cd06eef8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8801d7dc3c10 RCX: 0000000000000006
> RDX: 0000000000000001 RSI: ffff8801cc3ee928 RDI: ffff8801d7dc3ac0
> RBP: ffff8801cd06f258 R08: 0000000100000000 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801cd06f230
> R13: ffff8801c6eb9aa0 R14: ffff8801c6eb9af0 R15: ffff8801cd06ef70
> FS: 0000000000000000(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 00000001d6201000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Stack:
> ffff8801d7dc3ac0 ffffffff813fa207 dffffc0000000000 ffffe8ffffd0f238
> 0000000000000002 1ffff10039a0ddea ffffe8ffffd0f218 ffff8801cd06f190
> 0000000000000282 ffffe8ffffd0f140 ffffe8ffffd0f220 0000000041b58ab3
> Call Trace:
> [<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
> [<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
> [<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
> [<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
> [<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
> [<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
> [<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
> [<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff8436fbea>] 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 <c7>
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP <ffff8801cd06eef8>
> CR2: 0000000000000060
> ---[ end trace 47d3302a6c62cfbc ]---
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
> IP: [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> PGD 1ccad4067 [ 32.785777] PUD 1cb96c067
> Oops: 0002 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3231 Comm: kworker/1:2 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: ffff8801cf472700 task.stack: ffff8801ce848000
> RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:ffff8801ce84eef8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8801d7c82950 RCX: 0000000000000006
> RDX: 0000000000000001 RSI: ffff8801cf472f28 RDI: ffff8801d7c82800
> RBP: ffff8801ce84f258 R08: 0000000100000000 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801ce84f230
> R13: ffff8801c970e760 R14: ffff8801c970e7b0 R15: ffff8801ce84ef70
> FS: 0000000000000000(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 00000001ca654000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Stack:
> ffff8801d7c82800 ffffffff813fa207 dffffc0000000000 ffffe8ffffd0f238
> 0000000000000002 1ffff10039d09dea ffffe8ffffd0f218 ffff8801ce84f190
> 0000000000000282 ffffe8ffffd0f140 ffffe8ffffd0f220 0000000041b58ab3
> Call Trace:
> [<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
> [<ffffffff8219cdad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
> [<ffffffff8219cdad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
> [<ffffffff8219cdad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
> [<ffffffff8219c29f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
> [<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
> [<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
> [<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff8436fbea>] 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 <c7>
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP <ffff8801ce84eef8>
> CR2: 0000000000000060
> ---[ end trace 3af8184eabd21203 ]---
^ permalink raw reply
* Re: [PATCH v6 1/5] lib: Update LZ4 compressor module
From: Jonathan Corbet @ 2017-01-31 22:27 UTC (permalink / raw)
To: Sven Schmidt
Cc: akpm, bongkyu.kim, rsalvaterra, sergey.senozhatsky, gregkh,
linux-kernel, herbert, davem, linux-crypto, anton, ccross,
keescook, tony.luck
In-Reply-To: <1485554524-4844-2-git-send-email-4sschmid@informatik.uni-hamburg.de>
On Fri, 27 Jan 2017 23:02:00 +0100
Sven Schmidt <4sschmid@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
^ permalink raw reply
* Crypto Fixes for 4.10
From: Herbert Xu @ 2017-02-01 9:04 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20170111115646.GA8943@gondor.apana.org.au>
Hi Linus:
This push fixes a bug in CBC/CTR on ARM64 that breaks chaining
as well as a bug in the core API that causes registration failures
when a driver unloads and then reloads an algorithm.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Ard Biesheuvel (1):
crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
Salvatore Benedetto (1):
crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg
arch/arm64/crypto/aes-modes.S | 88 ++++++++++++++++++++---------------------
crypto/algapi.c | 1 +
2 files changed, 43 insertions(+), 46 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler
From: Ard Biesheuvel @ 2017-02-01 9:07 UTC (permalink / raw)
To: Will Deacon
Cc: Matthias Brugger, Herbert Xu, David S. Miller, Catalin Marinas,
Yazen Ghannam, Alexander Graf, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170127105244.GF21144@arm.com>
On 27 January 2017 at 10:52, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2017 at 10:43:16AM +0000, Ard Biesheuvel wrote:
>> On 27 January 2017 at 10:40, Matthias Brugger <mbrugger@suse.com> wrote:
>> > Older compilers may not be able to detect the crc32 extended cpu type.
>>
>> What do you mean 'detect'? Could you describe the failure in more detail
>> please?
>>
>> > Anyway only inline assembler code is used, which gets passed to the
>> > assembler. This patch moves the crc detection to the assembler.
>> >
>> > Suggested-by: Alexander Graf <agraf@suse.de>
>> > Signed-off-by: Matthias Brugger <mbrugger@suse.com>
>> > ---
>> > arch/arm64/crypto/Makefile | 2 --
>> > arch/arm64/crypto/crc32-arm64.c | 3 +++
>> > 2 files changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>> > index aa8888d7b744..0d779dac75cd 100644
>> > --- a/arch/arm64/crypto/Makefile
>> > +++ b/arch/arm64/crypto/Makefile
>> > @@ -48,8 +48,6 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS
>> >
>> > obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
>> >
>> > -CFLAGS_crc32-arm64.o := -mcpu=generic+crc
>> > -
>> > $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
>> > $(call if_changed_rule,cc_o_c)
>> >
>> > diff --git a/arch/arm64/crypto/crc32-arm64.c b/arch/arm64/crypto/crc32-arm64.c
>> > index 6a37c3c6b11d..10f5dd075323 100644
>> > --- a/arch/arm64/crypto/crc32-arm64.c
>> > +++ b/arch/arm64/crypto/crc32-arm64.c
>> > @@ -29,6 +29,9 @@ MODULE_AUTHOR("Yazen Ghannam <yazen.ghannam@linaro.org>");
>> > MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8 instructions");
>> > MODULE_LICENSE("GPL v2");
>> >
>> > +/* Request crc extension capabilities from the assembler */
>> > +asm(".arch_extension crc");
>> > +
>>
>> Will should confirm, but I think this is a recent feature in GAS for
>> AArch64, so this may break older toolchains as well.
>
> Yes, the .arch_extension directive isn't universally supported by AArch64
> gas so we can't rely on it unconditionally. The best bet is to check for
> the support and, if it's not present, then disable whatever feature relies
> on it. See the lseinstr variable in Makefile.
>
Actually, this driver has become somewhat redundant now that we have
an alternative that combines an implementation based on 64x64
polynomial multiplication with an implementation based on the CRC32
instructions.
I will propose a patch that makes the latter usable when only the
CRC32 instructions are supported.
^ permalink raw reply
* Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler
From: Ard Biesheuvel @ 2017-02-01 9:43 UTC (permalink / raw)
To: Will Deacon
Cc: Matthias Brugger, Herbert Xu, David S. Miller, Catalin Marinas,
Yazen Ghannam, Alexander Graf, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAKv+Gu_LcU3mSSMdrjks02ZuhHLhkYqNuZGOcTp1AmS8cpzCDg@mail.gmail.com>
On 1 February 2017 at 09:07, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 27 January 2017 at 10:52, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Jan 27, 2017 at 10:43:16AM +0000, Ard Biesheuvel wrote:
>>> On 27 January 2017 at 10:40, Matthias Brugger <mbrugger@suse.com> wrote:
>>> > Older compilers may not be able to detect the crc32 extended cpu type.
>>>
>>> What do you mean 'detect'? Could you describe the failure in more detail
>>> please?
>>>
>>> > Anyway only inline assembler code is used, which gets passed to the
>>> > assembler. This patch moves the crc detection to the assembler.
>>> >
>>> > Suggested-by: Alexander Graf <agraf@suse.de>
>>> > Signed-off-by: Matthias Brugger <mbrugger@suse.com>
>>> > ---
>>> > arch/arm64/crypto/Makefile | 2 --
>>> > arch/arm64/crypto/crc32-arm64.c | 3 +++
>>> > 2 files changed, 3 insertions(+), 2 deletions(-)
>>> >
>>> > diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>>> > index aa8888d7b744..0d779dac75cd 100644
>>> > --- a/arch/arm64/crypto/Makefile
>>> > +++ b/arch/arm64/crypto/Makefile
>>> > @@ -48,8 +48,6 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS
>>> >
>>> > obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
>>> >
>>> > -CFLAGS_crc32-arm64.o := -mcpu=generic+crc
>>> > -
>>> > $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
>>> > $(call if_changed_rule,cc_o_c)
>>> >
>>> > diff --git a/arch/arm64/crypto/crc32-arm64.c b/arch/arm64/crypto/crc32-arm64.c
>>> > index 6a37c3c6b11d..10f5dd075323 100644
>>> > --- a/arch/arm64/crypto/crc32-arm64.c
>>> > +++ b/arch/arm64/crypto/crc32-arm64.c
>>> > @@ -29,6 +29,9 @@ MODULE_AUTHOR("Yazen Ghannam <yazen.ghannam@linaro.org>");
>>> > MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8 instructions");
>>> > MODULE_LICENSE("GPL v2");
>>> >
>>> > +/* Request crc extension capabilities from the assembler */
>>> > +asm(".arch_extension crc");
>>> > +
>>>
>>> Will should confirm, but I think this is a recent feature in GAS for
>>> AArch64, so this may break older toolchains as well.
>>
>> Yes, the .arch_extension directive isn't universally supported by AArch64
>> gas so we can't rely on it unconditionally. The best bet is to check for
>> the support and, if it's not present, then disable whatever feature relies
>> on it. See the lseinstr variable in Makefile.
>>
>
> Actually, this driver has become somewhat redundant now that we have
> an alternative that combines an implementation based on 64x64
> polynomial multiplication with an implementation based on the CRC32
> instructions.
>
> I will propose a patch that makes the latter usable when only the
> CRC32 instructions are supported.
... although you still haven't explained what the actual problem is
that you are trying to solve.
^ permalink raw reply
* Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler
From: Alexander Graf @ 2017-02-01 13:58 UTC (permalink / raw)
To: Ard Biesheuvel, Will Deacon
Cc: Matthias Brugger, Herbert Xu, David S. Miller, Catalin Marinas,
Yazen Ghannam, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAKv+Gu9gPAb-AMdbK32dXciX1mgh1sqSrxMAjB-ZGw7uAk2r2Q@mail.gmail.com>
On 02/01/2017 10:43 AM, Ard Biesheuvel wrote:
> On 1 February 2017 at 09:07, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 27 January 2017 at 10:52, Will Deacon <will.deacon@arm.com> wrote:
>>> On Fri, Jan 27, 2017 at 10:43:16AM +0000, Ard Biesheuvel wrote:
>>>> On 27 January 2017 at 10:40, Matthias Brugger <mbrugger@suse.com> wrote:
>>>>> Older compilers may not be able to detect the crc32 extended cpu type.
>>>> What do you mean 'detect'? Could you describe the failure in more detail
>>>> please?
>>>>
>>>>> Anyway only inline assembler code is used, which gets passed to the
>>>>> assembler. This patch moves the crc detection to the assembler.
>>>>>
>>>>> Suggested-by: Alexander Graf <agraf@suse.de>
>>>>> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
>>>>> ---
>>>>> arch/arm64/crypto/Makefile | 2 --
>>>>> arch/arm64/crypto/crc32-arm64.c | 3 +++
>>>>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>>>>> index aa8888d7b744..0d779dac75cd 100644
>>>>> --- a/arch/arm64/crypto/Makefile
>>>>> +++ b/arch/arm64/crypto/Makefile
>>>>> @@ -48,8 +48,6 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS
>>>>>
>>>>> obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
>>>>>
>>>>> -CFLAGS_crc32-arm64.o := -mcpu=generic+crc
>>>>> -
>>>>> $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
>>>>> $(call if_changed_rule,cc_o_c)
>>>>>
>>>>> diff --git a/arch/arm64/crypto/crc32-arm64.c b/arch/arm64/crypto/crc32-arm64.c
>>>>> index 6a37c3c6b11d..10f5dd075323 100644
>>>>> --- a/arch/arm64/crypto/crc32-arm64.c
>>>>> +++ b/arch/arm64/crypto/crc32-arm64.c
>>>>> @@ -29,6 +29,9 @@ MODULE_AUTHOR("Yazen Ghannam <yazen.ghannam@linaro.org>");
>>>>> MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8 instructions");
>>>>> MODULE_LICENSE("GPL v2");
>>>>>
>>>>> +/* Request crc extension capabilities from the assembler */
>>>>> +asm(".arch_extension crc");
>>>>> +
>>>> Will should confirm, but I think this is a recent feature in GAS for
>>>> AArch64, so this may break older toolchains as well.
>>> Yes, the .arch_extension directive isn't universally supported by AArch64
>>> gas so we can't rely on it unconditionally. The best bet is to check for
>>> the support and, if it's not present, then disable whatever feature relies
>>> on it. See the lseinstr variable in Makefile.
>>>
>> Actually, this driver has become somewhat redundant now that we have
>> an alternative that combines an implementation based on 64x64
>> polynomial multiplication with an implementation based on the CRC32
>> instructions.
>>
>> I will propose a patch that makes the latter usable when only the
>> CRC32 instructions are supported.
> ... although you still haven't explained what the actual problem is
> that you are trying to solve.
The problem is that in Leap 42.2 (as well as SLES12 SP2) we have a 4.8
based system compiler, but recent binutils. That means that while our
assembler is happy to work with crc instructions, passing the -mcpu
parameter to gcc fails because gcc isn't aware of the flavor yet.
That in turn means that we want to tell the assembler about feature
requirements rather than the compiler. Fortunately the ".arch_extension"
primitive allows you to do so.
As far as checking for availability of it goes, I agree that it'd be
nice to check if ".arch_extension" is supported. But so would be to
check if -mcpu=generic+crc is supported. IMHO this patch doesn't make
the current non-checking situation any worse. But of course checking is
always nicer than not checking :)
Alex
^ permalink raw reply
* Re: [PATCH] crypto: tcrypt - Add mode to test specified algs
From: Herbert Xu @ 2017-02-01 14:03 UTC (permalink / raw)
To: Rabin Vincent; +Cc: linux-crypto
In-Reply-To: <20170123151304.GA20450@axis.com>
On Mon, Jan 23, 2017 at 04:13:04PM +0100, Rabin Vincent wrote:
>
> That's what I thought so too, but that doesn't seem to be the case. The
> mode=0 handling is this:
>
> switch (m) {
> case 0:
> if (alg) {
> if (!crypto_has_alg(alg, type,
> mask ?: CRYPTO_ALG_TYPE_MASK))
> ret = -ENOENT;
> break;
> }
>
> for (i = 1; i < 200; i++)
> ret += do_test(NULL, 0, 0, i);
> break;
>
> So, if alg= is specified, after first checking if the specified alg is
> present, it just goes ahead and runs all the tests. I'm not sure what
> mode=0 alg=foo is meant to be used for.
You need to set the type and mask for it to work.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg
From: Herbert Xu @ 2017-02-01 14:06 UTC (permalink / raw)
To: Benedetto, Salvatore; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <309B30E91F5E2846B79BD9AA9711D031A56A79@IRSMSX102.ger.corp.intel.com>
On Mon, Jan 23, 2017 at 05:06:34PM +0000, Benedetto, Salvatore wrote:
>
> I forgot to add CC stable to it.
>
> This error was introduced in 4.8 and so I think it should go into stable 4.8 and 4.9.
>
> Should I resend or can you add that?
I had added it when applying the patch.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: 4.10 aesni-intel no longer having lrw/ablk_helper dependencies?
From: Herbert Xu @ 2017-02-01 14:17 UTC (permalink / raw)
To: Arkadiusz Miśkiewicz; +Cc: Eric Biggers, linux-crypto
In-Reply-To: <201701301742.35626.arekm@maven.pl>
On Mon, Jan 30, 2017 at 05:42:35PM +0100, Arkadiusz Miśkiewicz wrote:
> On Monday 30 of January 2017, Eric Biggers wrote:
>
> > First, aesni-intel no longer includes an LRW implementation itself.
> > Instead, the generic LRW module must be selected. Internally it will use
> > the aesni-intel accelerated ECB algorithm if available. So you need to
> > make sure that the "lrw" module is included in the initrd if it's not
> > already.
> >
> > But I think the bigger problem is that aesni-intel couldn't be insmod'ed at
> > all, which shouldn't happen. The problem might actually be related to the
> > "pcbc" algorithm. Upon initialization, aesni-intel now tries to wrap
> > "pcbc(__aes-aesni)" with the "fpu" template. This will fail if the "pcbc"
> > module hasn't been inserted. I think this wasn't a problem before because
> > the old code using ablk_helper instead of crypto_simd didn't try to find
> > "pcbc" until someone asked for it, while now aesni-intel will try to find
> > it immediately. And since aesni-intel has no direct dependency on pcbc,
> > I'm guessing what happened is that pcbc didn't end up in your initrd even
> > though it may have been built. (You can verify this by adding pcbc to
> > your initrd and seeing if that works around the problem.)
>
> (hardcoded) loading of pcbc fixed my problem, intel-aesni loaded fine and luks
> partition unlocked correctly.
Thanks for the report. Does this patch fix the problem?
---8<---
Subject: crypto: aesni - Fix failure when pcbc module is absent
When aesni is built as a module together with pcbc, the pcbc module
must be present for aesni to load. However, the pcbc module may not
be present for reasons such as its absence on initramfs. This patch
allows the aesni to function even if the pcbc module is enabled but
not present.
Reported-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 7ad0ed7..93de8ea 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1089,9 +1089,9 @@ static void aesni_free_simds(void)
aesni_simd_skciphers[i]; i++)
simd_skcipher_free(aesni_simd_skciphers[i]);
- for (i = 0; i < ARRAY_SIZE(aesni_simd_skciphers2) &&
- aesni_simd_skciphers2[i].simd; i++)
- simd_skcipher_free(aesni_simd_skciphers2[i].simd);
+ for (i = 0; i < ARRAY_SIZE(aesni_simd_skciphers2); i++)
+ if (aesni_simd_skciphers2[i].simd)
+ simd_skcipher_free(aesni_simd_skciphers2[i].simd);
}
static int __init aesni_init(void)
@@ -1172,7 +1172,7 @@ static int __init aesni_init(void)
simd = simd_skcipher_create_compat(algname, drvname, basename);
err = PTR_ERR(simd);
if (IS_ERR(simd))
- goto unregister_simds;
+ continue;
aesni_simd_skciphers2[i].simd = simd;
}
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler
From: Ard Biesheuvel @ 2017-02-01 15:12 UTC (permalink / raw)
To: Alexander Graf
Cc: Will Deacon, Matthias Brugger, Herbert Xu, David S. Miller,
Catalin Marinas, Yazen Ghannam, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5ebb24d2-81d4-53c7-0365-f35a0eb3588b@suse.de>
On 1 February 2017 at 13:58, Alexander Graf <agraf@suse.de> wrote:
> On 02/01/2017 10:43 AM, Ard Biesheuvel wrote:
>>
>> On 1 February 2017 at 09:07, Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> wrote:
>>>
>>> On 27 January 2017 at 10:52, Will Deacon <will.deacon@arm.com> wrote:
>>>>
>>>> On Fri, Jan 27, 2017 at 10:43:16AM +0000, Ard Biesheuvel wrote:
>>>>>
>>>>> On 27 January 2017 at 10:40, Matthias Brugger <mbrugger@suse.com>
>>>>> wrote:
>>>>>>
>>>>>> Older compilers may not be able to detect the crc32 extended cpu type.
>>>>>
>>>>> What do you mean 'detect'? Could you describe the failure in more
>>>>> detail
>>>>> please?
>>>>>
>>>>>> Anyway only inline assembler code is used, which gets passed to the
>>>>>> assembler. This patch moves the crc detection to the assembler.
>>>>>>
>>>>>> Suggested-by: Alexander Graf <agraf@suse.de>
>>>>>> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
>>>>>> ---
>>>>>> arch/arm64/crypto/Makefile | 2 --
>>>>>> arch/arm64/crypto/crc32-arm64.c | 3 +++
>>>>>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>>>>>> index aa8888d7b744..0d779dac75cd 100644
>>>>>> --- a/arch/arm64/crypto/Makefile
>>>>>> +++ b/arch/arm64/crypto/Makefile
>>>>>> @@ -48,8 +48,6 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS
>>>>>>
>>>>>> obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
>>>>>>
>>>>>> -CFLAGS_crc32-arm64.o := -mcpu=generic+crc
>>>>>> -
>>>>>> $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
>>>>>> $(call if_changed_rule,cc_o_c)
>>>>>>
>>>>>> diff --git a/arch/arm64/crypto/crc32-arm64.c
>>>>>> b/arch/arm64/crypto/crc32-arm64.c
>>>>>> index 6a37c3c6b11d..10f5dd075323 100644
>>>>>> --- a/arch/arm64/crypto/crc32-arm64.c
>>>>>> +++ b/arch/arm64/crypto/crc32-arm64.c
>>>>>> @@ -29,6 +29,9 @@ MODULE_AUTHOR("Yazen Ghannam
>>>>>> <yazen.ghannam@linaro.org>");
>>>>>> MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8
>>>>>> instructions");
>>>>>> MODULE_LICENSE("GPL v2");
>>>>>>
>>>>>> +/* Request crc extension capabilities from the assembler */
>>>>>> +asm(".arch_extension crc");
>>>>>> +
>>>>>
>>>>> Will should confirm, but I think this is a recent feature in GAS for
>>>>> AArch64, so this may break older toolchains as well.
>>>>
>>>> Yes, the .arch_extension directive isn't universally supported by
>>>> AArch64
>>>> gas so we can't rely on it unconditionally. The best bet is to check for
>>>> the support and, if it's not present, then disable whatever feature
>>>> relies
>>>> on it. See the lseinstr variable in Makefile.
>>>>
>>> Actually, this driver has become somewhat redundant now that we have
>>> an alternative that combines an implementation based on 64x64
>>> polynomial multiplication with an implementation based on the CRC32
>>> instructions.
>>>
>>> I will propose a patch that makes the latter usable when only the
>>> CRC32 instructions are supported.
>>
>> ... although you still haven't explained what the actual problem is
>> that you are trying to solve.
>
>
>
>
> The problem is that in Leap 42.2 (as well as SLES12 SP2) we have a 4.8 based
> system compiler, but recent binutils. That means that while our assembler is
> happy to work with crc instructions, passing the -mcpu parameter to gcc
> fails because gcc isn't aware of the flavor yet.
>
> That in turn means that we want to tell the assembler about feature
> requirements rather than the compiler. Fortunately the ".arch_extension"
> primitive allows you to do so.
>
> As far as checking for availability of it goes, I agree that it'd be nice to
> check if ".arch_extension" is supported. But so would be to check if
> -mcpu=generic+crc is supported. IMHO this patch doesn't make the current
> non-checking situation any worse. But of course checking is always nicer
> than not checking :)
>
Well, I am pretty sure binutils v2.25 and older are in wider use than
GCC v4.8 and older, which means the runtime test would disable the CRC
module altogether for a lot of users.
However, as I mentioned, we can also remove this driver once the PMULL
based one is updated.
^ permalink raw reply
* [PATCH] crypto: arm64/crc32 - merge CRC32 and PMULL instruction based drivers
From: Ard Biesheuvel @ 2017-02-01 15:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto
Cc: will.deacon, herbert, yazen.ghannam, steve.capper, agraf,
mbrugger, Ard Biesheuvel
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 <ard.biesheuvel@linaro.org>
---
This is a meaningful patch by itself imho, but also fixes the issue reported
by Matthias where their v4.8 based GCC does not understand the -mcpu=generic+crc
command line option, resulting in failed builds.
arch/arm64/configs/defconfig | 1 -
arch/arm64/crypto/Kconfig | 9 +-
arch/arm64/crypto/Makefile | 4 -
arch/arm64/crypto/crc32-arm64.c | 290 --------------------
arch/arm64/crypto/crc32-ce-glue.c | 49 +++-
5 files changed, 41 insertions(+), 312 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 33b744d54739..6fc6f5a2a6e5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -516,4 +516,3 @@ CONFIG_CRYPTO_GHASH_ARM64_CE=y
CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
# CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
-CONFIG_CRYPTO_CRC32_ARM64=y
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index bed7feddfeed..d92293747d63 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -37,8 +37,8 @@ config CRYPTO_CRCT10DIF_ARM64_CE
select CRYPTO_HASH
config CRYPTO_CRC32_ARM64_CE
- tristate "CRC32 and CRC32C digest algorithms using PMULL instructions"
- depends on KERNEL_MODE_NEON && CRC32
+ tristate "CRC32 and CRC32C digest algorithms using ARMv8 extensions"
+ depends on CRC32
select CRYPTO_HASH
config CRYPTO_AES_ARM64
@@ -71,11 +71,6 @@ config CRYPTO_AES_ARM64_NEON_BLK
select CRYPTO_AES
select CRYPTO_SIMD
-config CRYPTO_CRC32_ARM64
- tristate "CRC32 and CRC32C using optional ARMv8 instructions"
- depends on ARM64
- select CRYPTO_HASH
-
config CRYPTO_CHACHA20_NEON
tristate "NEON accelerated ChaCha20 symmetric cipher"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index d1ae1b9cbe70..b5edc5918c28 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -55,10 +55,6 @@ AFLAGS_aes-neon.o := -DINTERLEAVE=4
CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS
-obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
-
-CFLAGS_crc32-arm64.o := -mcpu=generic+crc
-
$(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
$(call if_changed_rule,cc_o_c)
diff --git a/arch/arm64/crypto/crc32-arm64.c b/arch/arm64/crypto/crc32-arm64.c
deleted file mode 100644
index 6a37c3c6b11d..000000000000
--- a/arch/arm64/crypto/crc32-arm64.c
+++ /dev/null
@@ -1,290 +0,0 @@
-/*
- * crc32-arm64.c - CRC32 and CRC32C using optional ARMv8 instructions
- *
- * Module based on crypto/crc32c_generic.c
- *
- * CRC32 loop taken from Ed Nevill's Hadoop CRC patch
- * http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201406.mbox/%3C1403687030.3355.19.camel%40localhost.localdomain%3E
- *
- * Using inline assembly instead of intrinsics in order to be backwards
- * compatible with older compilers.
- *
- * Copyright (C) 2014 Linaro Ltd <yazen.ghannam@linaro.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/unaligned/access_ok.h>
-#include <linux/cpufeature.h>
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/string.h>
-
-#include <crypto/internal/hash.h>
-
-MODULE_AUTHOR("Yazen Ghannam <yazen.ghannam@linaro.org>");
-MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8 instructions");
-MODULE_LICENSE("GPL v2");
-
-#define CRC32X(crc, value) __asm__("crc32x %w[c], %w[c], %x[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32W(crc, value) __asm__("crc32w %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32H(crc, value) __asm__("crc32h %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32B(crc, value) __asm__("crc32b %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32CX(crc, value) __asm__("crc32cx %w[c], %w[c], %x[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32CW(crc, value) __asm__("crc32cw %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32CH(crc, value) __asm__("crc32ch %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-#define CRC32CB(crc, value) __asm__("crc32cb %w[c], %w[c], %w[v]":[c]"+r"(crc):[v]"r"(value))
-
-static u32 crc32_arm64_le_hw(u32 crc, const u8 *p, unsigned int len)
-{
- s64 length = len;
-
- while ((length -= sizeof(u64)) >= 0) {
- CRC32X(crc, get_unaligned_le64(p));
- p += sizeof(u64);
- }
-
- /* The following is more efficient than the straight loop */
- if (length & sizeof(u32)) {
- CRC32W(crc, get_unaligned_le32(p));
- p += sizeof(u32);
- }
- if (length & sizeof(u16)) {
- CRC32H(crc, get_unaligned_le16(p));
- p += sizeof(u16);
- }
- if (length & sizeof(u8))
- CRC32B(crc, *p);
-
- return crc;
-}
-
-static u32 crc32c_arm64_le_hw(u32 crc, const u8 *p, unsigned int len)
-{
- s64 length = len;
-
- while ((length -= sizeof(u64)) >= 0) {
- CRC32CX(crc, get_unaligned_le64(p));
- p += sizeof(u64);
- }
-
- /* The following is more efficient than the straight loop */
- if (length & sizeof(u32)) {
- CRC32CW(crc, get_unaligned_le32(p));
- p += sizeof(u32);
- }
- if (length & sizeof(u16)) {
- CRC32CH(crc, get_unaligned_le16(p));
- p += sizeof(u16);
- }
- if (length & sizeof(u8))
- CRC32CB(crc, *p);
-
- return crc;
-}
-
-#define CHKSUM_BLOCK_SIZE 1
-#define CHKSUM_DIGEST_SIZE 4
-
-struct chksum_ctx {
- u32 key;
-};
-
-struct chksum_desc_ctx {
- u32 crc;
-};
-
-static int chksum_init(struct shash_desc *desc)
-{
- struct chksum_ctx *mctx = crypto_shash_ctx(desc->tfm);
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- ctx->crc = mctx->key;
-
- return 0;
-}
-
-/*
- * Setting the seed allows arbitrary accumulators and flexible XOR policy
- * If your algorithm starts with ~0, then XOR with ~0 before you set
- * the seed.
- */
-static int chksum_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
-{
- struct chksum_ctx *mctx = crypto_shash_ctx(tfm);
-
- if (keylen != sizeof(mctx->key)) {
- crypto_shash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
- return -EINVAL;
- }
- mctx->key = get_unaligned_le32(key);
- return 0;
-}
-
-static int chksum_update(struct shash_desc *desc, const u8 *data,
- unsigned int length)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- ctx->crc = crc32_arm64_le_hw(ctx->crc, data, length);
- return 0;
-}
-
-static int chksumc_update(struct shash_desc *desc, const u8 *data,
- unsigned int length)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- ctx->crc = crc32c_arm64_le_hw(ctx->crc, data, length);
- return 0;
-}
-
-static int chksum_final(struct shash_desc *desc, u8 *out)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- put_unaligned_le32(ctx->crc, out);
- return 0;
-}
-
-static int chksumc_final(struct shash_desc *desc, u8 *out)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- put_unaligned_le32(~ctx->crc, out);
- return 0;
-}
-
-static int __chksum_finup(u32 crc, const u8 *data, unsigned int len, u8 *out)
-{
- put_unaligned_le32(crc32_arm64_le_hw(crc, data, len), out);
- return 0;
-}
-
-static int __chksumc_finup(u32 crc, const u8 *data, unsigned int len, u8 *out)
-{
- put_unaligned_le32(~crc32c_arm64_le_hw(crc, data, len), out);
- return 0;
-}
-
-static int chksum_finup(struct shash_desc *desc, const u8 *data,
- unsigned int len, u8 *out)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- return __chksum_finup(ctx->crc, data, len, out);
-}
-
-static int chksumc_finup(struct shash_desc *desc, const u8 *data,
- unsigned int len, u8 *out)
-{
- struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
-
- return __chksumc_finup(ctx->crc, data, len, out);
-}
-
-static int chksum_digest(struct shash_desc *desc, const u8 *data,
- unsigned int length, u8 *out)
-{
- struct chksum_ctx *mctx = crypto_shash_ctx(desc->tfm);
-
- return __chksum_finup(mctx->key, data, length, out);
-}
-
-static int chksumc_digest(struct shash_desc *desc, const u8 *data,
- unsigned int length, u8 *out)
-{
- struct chksum_ctx *mctx = crypto_shash_ctx(desc->tfm);
-
- return __chksumc_finup(mctx->key, data, length, out);
-}
-
-static int crc32_cra_init(struct crypto_tfm *tfm)
-{
- struct chksum_ctx *mctx = crypto_tfm_ctx(tfm);
-
- mctx->key = 0;
- return 0;
-}
-
-static int crc32c_cra_init(struct crypto_tfm *tfm)
-{
- struct chksum_ctx *mctx = crypto_tfm_ctx(tfm);
-
- mctx->key = ~0;
- return 0;
-}
-
-static struct shash_alg crc32_alg = {
- .digestsize = CHKSUM_DIGEST_SIZE,
- .setkey = chksum_setkey,
- .init = chksum_init,
- .update = chksum_update,
- .final = chksum_final,
- .finup = chksum_finup,
- .digest = chksum_digest,
- .descsize = sizeof(struct chksum_desc_ctx),
- .base = {
- .cra_name = "crc32",
- .cra_driver_name = "crc32-arm64-hw",
- .cra_priority = 300,
- .cra_blocksize = CHKSUM_BLOCK_SIZE,
- .cra_alignmask = 0,
- .cra_ctxsize = sizeof(struct chksum_ctx),
- .cra_module = THIS_MODULE,
- .cra_init = crc32_cra_init,
- }
-};
-
-static struct shash_alg crc32c_alg = {
- .digestsize = CHKSUM_DIGEST_SIZE,
- .setkey = chksum_setkey,
- .init = chksum_init,
- .update = chksumc_update,
- .final = chksumc_final,
- .finup = chksumc_finup,
- .digest = chksumc_digest,
- .descsize = sizeof(struct chksum_desc_ctx),
- .base = {
- .cra_name = "crc32c",
- .cra_driver_name = "crc32c-arm64-hw",
- .cra_priority = 300,
- .cra_blocksize = CHKSUM_BLOCK_SIZE,
- .cra_alignmask = 0,
- .cra_ctxsize = sizeof(struct chksum_ctx),
- .cra_module = THIS_MODULE,
- .cra_init = crc32c_cra_init,
- }
-};
-
-static int __init crc32_mod_init(void)
-{
- int err;
-
- err = crypto_register_shash(&crc32_alg);
-
- if (err)
- return err;
-
- err = crypto_register_shash(&crc32c_alg);
-
- if (err) {
- crypto_unregister_shash(&crc32_alg);
- return err;
- }
-
- return 0;
-}
-
-static void __exit crc32_mod_exit(void)
-{
- crypto_unregister_shash(&crc32_alg);
- crypto_unregister_shash(&crc32c_alg);
-}
-
-module_cpu_feature_match(CRC32, crc32_mod_init);
-module_exit(crc32_mod_exit);
diff --git a/arch/arm64/crypto/crc32-ce-glue.c b/arch/arm64/crypto/crc32-ce-glue.c
index 8594127d5e01..eccb1ae90064 100644
--- a/arch/arm64/crypto/crc32-ce-glue.c
+++ b/arch/arm64/crypto/crc32-ce-glue.c
@@ -72,6 +72,24 @@ static int crc32_pmull_init(struct shash_desc *desc)
return 0;
}
+static int crc32_update(struct shash_desc *desc, const u8 *data,
+ unsigned int length)
+{
+ u32 *crc = shash_desc_ctx(desc);
+
+ *crc = crc32_armv8_le(*crc, data, length);
+ return 0;
+}
+
+static int crc32c_update(struct shash_desc *desc, const u8 *data,
+ unsigned int length)
+{
+ u32 *crc = shash_desc_ctx(desc);
+
+ *crc = crc32c_armv8_le(*crc, data, length);
+ return 0;
+}
+
static int crc32_pmull_update(struct shash_desc *desc, const u8 *data,
unsigned int length)
{
@@ -156,7 +174,7 @@ static int crc32c_pmull_final(struct shash_desc *desc, u8 *out)
static struct shash_alg crc32_pmull_algs[] = { {
.setkey = crc32_pmull_setkey,
.init = crc32_pmull_init,
- .update = crc32_pmull_update,
+ .update = crc32_update,
.final = crc32_pmull_final,
.descsize = sizeof(u32),
.digestsize = sizeof(u32),
@@ -171,7 +189,7 @@ static struct shash_alg crc32_pmull_algs[] = { {
}, {
.setkey = crc32_pmull_setkey,
.init = crc32_pmull_init,
- .update = crc32c_pmull_update,
+ .update = crc32c_update,
.final = crc32c_pmull_final,
.descsize = sizeof(u32),
.digestsize = sizeof(u32),
@@ -187,14 +205,20 @@ static struct shash_alg crc32_pmull_algs[] = { {
static int __init crc32_pmull_mod_init(void)
{
- if (elf_hwcap & HWCAP_CRC32) {
- fallback_crc32 = crc32_armv8_le;
- fallback_crc32c = crc32c_armv8_le;
- } else {
- fallback_crc32 = crc32_le;
- fallback_crc32c = __crc32c_le;
+ if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON) && (elf_hwcap & HWCAP_PMULL)) {
+ crc32_pmull_algs[0].update = crc32_pmull_update;
+ crc32_pmull_algs[1].update = crc32c_pmull_update;
+
+ if (elf_hwcap & HWCAP_CRC32) {
+ fallback_crc32 = crc32_armv8_le;
+ fallback_crc32c = crc32c_armv8_le;
+ } else {
+ fallback_crc32 = crc32_le;
+ fallback_crc32c = __crc32c_le;
+ }
+ } else if (!(elf_hwcap & HWCAP_CRC32)) {
+ return -ENODEV;
}
-
return crypto_register_shashes(crc32_pmull_algs,
ARRAY_SIZE(crc32_pmull_algs));
}
@@ -205,7 +229,12 @@ static void __exit crc32_pmull_mod_exit(void)
ARRAY_SIZE(crc32_pmull_algs));
}
-module_cpu_feature_match(PMULL, crc32_pmull_mod_init);
+static const struct cpu_feature crc32_cpu_feature[] = {
+ { cpu_feature(CRC32) }, { cpu_feature(PMULL) }, { }
+};
+MODULE_DEVICE_TABLE(cpu, crc32_cpu_feature);
+
+module_init(crc32_pmull_mod_init);
module_exit(crc32_pmull_mod_exit);
MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] crypto:algif_aead - Fix kernel panic on list_del
From: Harsh Jain @ 2017-02-01 15:40 UTC (permalink / raw)
To: smueller, herbert, atul.gupta, harshjain.prof, linux-crypto; +Cc: Harsh Jain
Kernel panics when userspace program try to access AEAD interface.
Remove node from Linked List before freeing its memory.
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
crypto/algif_aead.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index f849311..533265f 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -661,9 +661,9 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
unlock:
list_for_each_entry_safe(rsgl, tmp, &ctx->list, list) {
af_alg_free_sg(&rsgl->sgl);
+ list_del(&rsgl->list);
if (rsgl != &ctx->first_rsgl)
sock_kfree_s(sk, rsgl, sizeof(*rsgl));
- list_del(&rsgl->list);
}
INIT_LIST_HEAD(&ctx->list);
aead_wmem_wakeup(sk);
--
1.8.2.3
^ permalink raw reply related
* Re: [PATCH 1/1] crypto:algif_aead - Fix kernel panic on list_del
From: Stephan Müller @ 2017-02-01 15:47 UTC (permalink / raw)
To: Harsh Jain; +Cc: herbert, atul.gupta, harshjain.prof, linux-crypto
In-Reply-To: <3368ebb31bd1670b8ea8ff45c81807c8c0e6bc3b.1485948732.git.harsh@chelsio.com>
Am Mittwoch, 1. Februar 2017, 21:10:28 CET schrieb Harsh Jain:
Hi Harsh,
> Kernel panics when userspace program try to access AEAD interface.
> Remove node from Linked List before freeing its memory.
Very good catch. Thank you.
Reviewed-by: Stephan Müller <smueller@chronox.de>
(PS: Herbert, in case you want to apply my patches regarding fixing the memory
management for algif_aead and algif_skcipher, please note that this error is
in the new function aead_free_rsgl/skcipher_free_sgl. Thus, if you think that
my approach is good after all, I will need to re-send the patch.)
Ciao
Stephan
^ permalink raw reply
* Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2
From: Tim Chen @ 2017-02-01 18:45 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Herbert Xu, David Miller, linux-crypto, LKML, megha.dey,
fenghua.yu, syzkaller
In-Reply-To: <CACT4Y+Z6_x2smshuSgQx0wA+g0H+5dJsF23UqYb9Z_WkDUvwcw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11690 bytes --]
On Tue, Jan 31, 2017 at 02:16:31PM +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?
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
> IP: [<ffffffff813fc09e>] 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: ffff8801d9f346c0 task.stack: ffff8801d9f08000
> RIP: 0010:[<ffffffff813fc09e>] [<ffffffff813fc09e>]
> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP: 0018:ffff8801d9f0eef8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8801d7db1190 RCX: 0000000000000006
> RDX: 0000000000000001 RSI: ffff8801d9f34ee8 RDI: ffff8801d7db1040
> RBP: ffff8801d9f0f258 R08: 0000000100000000 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000003 R12: ffff8801d9f0f230
> R13: ffff8801c8bbc4e0 R14: ffff8801c8bbc530 R15: ffff8801d9f0ef70
> FS: 0000000000000000(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 00000001cc15a000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Stack:
> ffff8801d7db1040 ffffffff813fa207 dffffc0000000000 ffffe8ffffc0f238
> 0000000000000002 1ffff1003b3e1dea ffffe8ffffc0f218 ffff8801d9f0f190
> 0000000000000282 ffffe8ffffc0f140 ffffe8ffffc0f220 0000000041b58ab3
> Call Trace:
> [<ffffffff813fb407>] sha512_mb_update+0x2f7/0x4e0
> arch/x86/crypto/sha512-mb/sha512_mb.c:588
> [<ffffffff8219d4ad>] crypto_ahash_update include/crypto/hash.h:512 [inline]
> [<ffffffff8219d4ad>] ahash_mcryptd_update crypto/mcryptd.c:627 [inline]
> [<ffffffff8219d4ad>] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373
> [<ffffffff8219c99f>] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181
> [<ffffffff81492960>] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
> [<ffffffff81493bc3>] worker_thread+0x223/0x1990 kernel/workqueue.c:2230
> [<ffffffff814abb33>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff8436fbaa>] 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 <c7>
> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3
> RIP [<ffffffff813fc09e>] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee
> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251
> RSP <ffff8801d9f0eef8>
> CR2: 0000000000000060
> ---[ end trace 139fd4cda5dfe2c4 ]---
>
Dmitry,
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?
Tim
--->8---
From: Tim Chen <tim.c.chen@linux.intel.com>
Subject: [PATCH] crypto/sha512-mb: Protect sha512 mb ctx mgr access
To: Herbert Xu <herbert@gondor.apana.org.au>, Dmitry Vyukov <dvyukov@google.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>, David Miller <davem@davemloft.net>, linux-crypto@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, megha.dey@linux.intel.com, fenghua.yu@intel.com
The flusher and regular multi-buffer computation via mcryptd may race with another.
Add here a lock and turn off interrupt to to access multi-buffer
computation state cstate->mgr before a round of computation. This should
prevent the flusher code jumping in.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
arch/x86/crypto/sha512-mb/sha512_mb.c | 64 +++++++++++++++++++++++------------
1 file changed, 42 insertions(+), 22 deletions(-)
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c b/arch/x86/crypto/sha512-mb/sha512_mb.c
index d210174..f3c1c21 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb.c
@@ -221,7 +221,7 @@ static struct sha512_hash_ctx *sha512_ctx_mgr_resubmit
}
static struct sha512_hash_ctx
- *sha512_ctx_mgr_get_comp_ctx(struct sha512_ctx_mgr *mgr)
+ *sha512_ctx_mgr_get_comp_ctx(struct mcryptd_alg_cstate *cstate)
{
/*
* If get_comp_job returns NULL, there are no jobs complete.
@@ -233,11 +233,17 @@ static struct sha512_hash_ctx
* Otherwise, all jobs currently being managed by the hash_ctx_mgr
* still need processing.
*/
+ struct sha512_ctx_mgr *mgr;
struct sha512_hash_ctx *ctx;
+ unsigned long flags;
+ mgr = cstate->mgr;
+ spin_lock_irqsave(&cstate->work_lock, flags);
ctx = (struct sha512_hash_ctx *)
sha512_job_mgr_get_comp_job(&mgr->mgr);
- return sha512_ctx_mgr_resubmit(mgr, ctx);
+ ctx = sha512_ctx_mgr_resubmit(mgr, ctx);
+ spin_unlock_irqrestore(&cstate->work_lock, flags);
+ return ctx;
}
static void sha512_ctx_mgr_init(struct sha512_ctx_mgr *mgr)
@@ -246,12 +252,17 @@ static void sha512_ctx_mgr_init(struct sha512_ctx_mgr *mgr)
}
static struct sha512_hash_ctx
- *sha512_ctx_mgr_submit(struct sha512_ctx_mgr *mgr,
+ *sha512_ctx_mgr_submit(struct mcryptd_alg_cstate *cstate,
struct sha512_hash_ctx *ctx,
const void *buffer,
uint32_t len,
int flags)
{
+ struct sha512_ctx_mgr *mgr;
+ unsigned long irqflags;
+
+ mgr = cstate->mgr;
+ spin_lock_irqsave(&cstate->work_lock, irqflags);
if (flags & (~HASH_ENTIRE)) {
/*
* User should not pass anything other than FIRST, UPDATE, or
@@ -351,20 +362,26 @@ static struct sha512_hash_ctx
}
}
- return sha512_ctx_mgr_resubmit(mgr, ctx);
+ ctx = sha512_ctx_mgr_resubmit(mgr, ctx);
+ spin_unlock_irqrestore(&cstate->work_lock, irqflags);
+ return ctx;
}
-static struct sha512_hash_ctx *sha512_ctx_mgr_flush(struct sha512_ctx_mgr *mgr)
+static struct sha512_hash_ctx *sha512_ctx_mgr_flush(struct mcryptd_alg_cstate *cstate)
{
+ struct sha512_ctx_mgr *mgr;
struct sha512_hash_ctx *ctx;
+ unsigned long flags;
+ mgr = cstate->mgr;
+ spin_lock_irqsave(&cstate->work_lock, flags);
while (1) {
ctx = (struct sha512_hash_ctx *)
sha512_job_mgr_flush(&mgr->mgr);
/* If flush returned 0, there are no more jobs in flight. */
if (!ctx)
- return NULL;
+ break;
/*
* If flush returned a job, resubmit the job to finish
@@ -378,8 +395,10 @@ static struct sha512_hash_ctx *sha512_ctx_mgr_flush(struct sha512_ctx_mgr *mgr)
* the sha512_ctx_mgr still need processing. Loop.
*/
if (ctx)
- return ctx;
+ break;
}
+ spin_unlock_irqrestore(&cstate->work_lock, flags);
+ return ctx;
}
static int sha512_mb_init(struct ahash_request *areq)
@@ -439,11 +458,11 @@ static int sha_finish_walk(struct mcryptd_hash_request_ctx **ret_rctx,
sha_ctx = (struct sha512_hash_ctx *)
ahash_request_ctx(&rctx->areq);
kernel_fpu_begin();
- sha_ctx = sha512_ctx_mgr_submit(cstate->mgr, sha_ctx,
+ sha_ctx = sha512_ctx_mgr_submit(cstate, sha_ctx,
rctx->walk.data, nbytes, flag);
if (!sha_ctx) {
if (flush)
- sha_ctx = sha512_ctx_mgr_flush(cstate->mgr);
+ sha_ctx = sha512_ctx_mgr_flush(cstate);
}
kernel_fpu_end();
if (sha_ctx)
@@ -471,11 +490,12 @@ static int sha_complete_job(struct mcryptd_hash_request_ctx *rctx,
struct sha512_hash_ctx *sha_ctx;
struct mcryptd_hash_request_ctx *req_ctx;
int ret;
+ unsigned long flags;
/* remove from work list */
- spin_lock(&cstate->work_lock);
+ spin_lock_irqsave(&cstate->work_lock, flags);
list_del(&rctx->waiter);
- spin_unlock(&cstate->work_lock);
+ spin_unlock_irqrestore(&cstate->work_lock, flags);
if (irqs_disabled())
rctx->complete(&req->base, err);
@@ -486,14 +506,14 @@ static int sha_complete_job(struct mcryptd_hash_request_ctx *rctx,
}
/* check to see if there are other jobs that are done */
- sha_ctx = sha512_ctx_mgr_get_comp_ctx(cstate->mgr);
+ sha_ctx = sha512_ctx_mgr_get_comp_ctx(cstate);
while (sha_ctx) {
req_ctx = cast_hash_to_mcryptd_ctx(sha_ctx);
ret = sha_finish_walk(&req_ctx, cstate, false);
if (req_ctx) {
- spin_lock(&cstate->work_lock);
+ spin_lock_irqsave(&cstate->work_lock, flags);
list_del(&req_ctx->waiter);
- spin_unlock(&cstate->work_lock);
+ spin_unlock_irqrestore(&cstate->work_lock, flags);
req = cast_mcryptd_ctx_to_req(req_ctx);
if (irqs_disabled())
@@ -504,7 +524,7 @@ static int sha_complete_job(struct mcryptd_hash_request_ctx *rctx,
local_bh_enable();
}
}
- sha_ctx = sha512_ctx_mgr_get_comp_ctx(cstate->mgr);
+ sha_ctx = sha512_ctx_mgr_get_comp_ctx(cstate);
}
return 0;
@@ -515,6 +535,7 @@ static void sha512_mb_add_list(struct mcryptd_hash_request_ctx *rctx,
{
unsigned long next_flush;
unsigned long delay = usecs_to_jiffies(FLUSH_INTERVAL);
+ unsigned long flags;
/* initialize tag */
rctx->tag.arrival = jiffies; /* tag the arrival time */
@@ -522,9 +543,9 @@ static void sha512_mb_add_list(struct mcryptd_hash_request_ctx *rctx,
next_flush = rctx->tag.arrival + delay;
rctx->tag.expire = next_flush;
- spin_lock(&cstate->work_lock);
+ spin_lock_irqsave(&cstate->work_lock, flags);
list_add_tail(&rctx->waiter, &cstate->work_list);
- spin_unlock(&cstate->work_lock);
+ spin_unlock_irqrestore(&cstate->work_lock, flags);
mcryptd_arm_flusher(cstate, delay);
}
@@ -565,7 +586,7 @@ static int sha512_mb_update(struct ahash_request *areq)
sha_ctx = (struct sha512_hash_ctx *) ahash_request_ctx(areq);
sha512_mb_add_list(rctx, cstate);
kernel_fpu_begin();
- sha_ctx = sha512_ctx_mgr_submit(cstate->mgr, sha_ctx, rctx->walk.data,
+ sha_ctx = sha512_ctx_mgr_submit(cstate, sha_ctx, rctx->walk.data,
nbytes, HASH_UPDATE);
kernel_fpu_end();
@@ -628,7 +649,7 @@ static int sha512_mb_finup(struct ahash_request *areq)
sha512_mb_add_list(rctx, cstate);
kernel_fpu_begin();
- sha_ctx = sha512_ctx_mgr_submit(cstate->mgr, sha_ctx, rctx->walk.data,
+ sha_ctx = sha512_ctx_mgr_submit(cstate, sha_ctx, rctx->walk.data,
nbytes, flag);
kernel_fpu_end();
@@ -677,8 +698,7 @@ static int sha512_mb_final(struct ahash_request *areq)
/* flag HASH_FINAL and 0 data size */
sha512_mb_add_list(rctx, cstate);
kernel_fpu_begin();
- sha_ctx = sha512_ctx_mgr_submit(cstate->mgr, sha_ctx, &data, 0,
- HASH_LAST);
+ sha_ctx = sha512_ctx_mgr_submit(cstate, sha_ctx, &data, 0, HASH_LAST);
kernel_fpu_end();
/* check if anything is returned */
@@ -940,7 +960,7 @@ static unsigned long sha512_mb_flusher(struct mcryptd_alg_cstate *cstate)
break;
kernel_fpu_begin();
sha_ctx = (struct sha512_hash_ctx *)
- sha512_ctx_mgr_flush(cstate->mgr);
+ sha512_ctx_mgr_flush(cstate);
kernel_fpu_end();
if (!sha_ctx) {
pr_err("sha512_mb error: nothing got flushed for"
--
2.5.5
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply related
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
From: Ard Biesheuvel @ 2017-02-01 20:08 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org; +Cc: Herbert Xu, Ard Biesheuvel
In-Reply-To: <1485636005-5192-1-git-send-email-ard.biesheuvel@linaro.org>
On 28 January 2017 at 20:40, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The skcipher API mandates that chaining modes involving IVs calculate
> an outgoing IV value that is suitable for encrypting additional blocks
> of data. This means the CCM driver cannot assume that req->iv points to
> the original IV value when it calls crypto_ccm_auth. So pass a copy to
> the skcipher instead.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> crypto/ccm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/ccm.c b/crypto/ccm.c
> index b388ac6edfb9..8976ef9bc2e7 100644
> --- a/crypto/ccm.c
> +++ b/crypto/ccm.c
> @@ -362,7 +362,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
> unsigned int cryptlen = req->cryptlen;
> u8 *authtag = pctx->auth_tag;
> u8 *odata = pctx->odata;
> - u8 *iv = req->iv;
> + u8 iv[16];
> int err;
>
> cryptlen -= authsize;
> @@ -378,6 +378,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
> if (req->src != req->dst)
> dst = pctx->dst;
>
> + memcpy(iv, req->iv, sizeof(iv));
> skcipher_request_set_tfm(skreq, ctx->ctr);
> skcipher_request_set_callback(skreq, pctx->flags,
> crypto_ccm_decrypt_done, req);
> --
> 2.7.4
>
Herbert,
Could you please forward this patch to Linus as well? I noticed that the patch
crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
is now in mainline, which means CCM is now broken on arm64, given that
the iv_out requirement for CTR apparently isn't honored by *any*
implementation, and CCM wrongly assumes that req->iv retains its value
across the call into the CTR skcipher
Thanks,
Ard.
^ permalink raw reply
* Re: [PATCH v6 1/5] lib: Update LZ4 compressor module
From: Sven Schmidt @ 2017-02-01 20:18 UTC (permalink / raw)
To: Jonathan Corbet
Cc: akpm, bongkyu.kim, rsalvaterra, sergey.senozhatsky, gregkh,
linux-kernel, herbert, davem, linux-crypto, anton, ccross,
keescook, tony.luck, 4sschmid
In-Reply-To: <20170131152744.5bd2f3ba@lwn.net>
On Tue, Jan 31, 2017 at 03:27:44PM -0700, Jonathan Corbet wrote:
> On Fri, 27 Jan 2017 23:02:00 +0100
> Sven Schmidt <4sschmid@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
Hi Jon,
of course, that makes sense. I already checked the documentation and you're right, I'm not that far from it.
Will do the necessary changes.
Thanks,
Sven
^ permalink raw reply
* КЛИЕНТСКИЕ БАЗЫ тел +79139230330 Skype: prodawez390 Email: prodawez393@gmail.com Узнайте подробнее!
From: linux-crypto @ 2017-02-01 21:01 UTC (permalink / raw)
To: linux-crypto
КЛИЕНТСКИЕ БАЗЫ тел +79139230330 Skype: prodawez390 Email: prodawez393@gmail.com Узнайте подробнее!
^ permalink raw reply
* [PATCH 0/6] Broadcom SBA RAID support
From: Anup Patel @ 2017-02-02 4:47 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA, Anup Patel
The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.
It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).
Important limitations of Broadcom SBA RAID hardware are:
1. Requires disk position instead of disk coefficient
2. Supports only 30 PQ disk coefficients
To address limitation #1, we have added raid_gflog table which
will help driver convert disk coefficient to disk position. To
address limitation #2, we have extended Linux Async Tx APIs to
check for available PQ coefficients before doing PQ offload.
This patchset is based on Linux-4.10-rc6 and depends on patchset
"[PATCH v4 0/2] Broadcom FlexRM ring manager support"
It is also available at sba-raid-v1 branch of
https://github.com/Broadcom/arm64-linux.git
Anup Patel (6):
mailbox: Add new API mbox_channel_device() for clients
lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
async_tx: Handle DMA devices having support for fewer PQ coefficients
async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
dmaengine: Add Broadcom SBA RAID driver
dt-bindings: Add DT bindings document for Broadcom SBA RAID driver
.../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 +
crypto/async_tx/async_pq.c | 8 +-
crypto/async_tx/async_raid6_recov.c | 12 +-
drivers/dma/Kconfig | 13 +
drivers/dma/Makefile | 1 +
drivers/dma/bcm-sba-raid.c | 1309 ++++++++++++++++++++
drivers/mailbox/mailbox.c | 21 +
include/linux/dmaengine.h | 19 +
include/linux/mailbox_client.h | 1 +
include/linux/raid/pq.h | 4 +
lib/raid6/mktables.c | 20 +
11 files changed, 1432 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
create mode 100644 drivers/dma/bcm-sba-raid.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients
From: Anup Patel @ 2017-02-02 4:47 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list, dmaengine, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-raid, Anup Patel
In-Reply-To: <1486010836-25228-1-git-send-email-anup.patel@broadcom.com>
The remote processor can have DMAENGINE capabilities and client
can pass data to be processed via main memory. In such cases,
the client will require DMAble memory for remote processor.
This patch adds new API mbox_channel_device() which can be
used by clients to get struct device pointer of underlying
mailbox controller. This struct device pointer of mailbox
controller can be used by clients to allocate DMAble memory
for remote processor.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
---
drivers/mailbox/mailbox.c | 21 +++++++++++++++++++++
include/linux/mailbox_client.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4671f8a..d4380fc 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -281,6 +281,27 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
EXPORT_SYMBOL_GPL(mbox_send_message);
/**
+ * mbox_channel_device - Get device pointer of a mailbox channel.
+ * @chan: Mailbox channel assigned to this client.
+ *
+ * The remote processor can have DMAENGINE capabilities and client
+ * can pass data to be processed via main memory. In such cases,
+ * the client will require struct device pointer of the mailbox
+ * channel to map/unmap/allocate/free DMAble memory.
+ *
+ * Return: Pointer to the struct device of mailbox channel.
+ * ERR_PTR on failure.
+ */
+struct device *mbox_channel_device(struct mbox_chan *chan)
+{
+ if (!chan || !chan->cl)
+ return ERR_PTR(-EINVAL);
+
+ return chan->mbox->dev;
+}
+EXPORT_SYMBOL_GPL(mbox_channel_device);
+
+/**
* mbox_request_channel - Request a mailbox channel.
* @cl: Identity of the client requesting the channel.
* @index: Index of mailbox specifier in 'mboxes' property.
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 4434871..3daffad 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -40,6 +40,7 @@ struct mbox_client {
void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
};
+struct device *mbox_channel_device(struct mbox_chan *chan);
struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
const char *name);
struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
From: Anup Patel @ 2017-02-02 4:47 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list, dmaengine, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-raid, Anup Patel
In-Reply-To: <1486010836-25228-1-git-send-email-anup.patel@broadcom.com>
The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.
The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)
This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
crypto/async_tx/async_pq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 16c6526..947cf35 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
- if (submit->flags & ASYNC_TX_FENCE)
- dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+ if (submit->flags & ASYNC_TX_FENCE)
+ dma_flags |= DMA_PREP_FENCE;
/* Drivers force forward progress in case they can not provide
* a descriptor
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox