* Re: [RFC PATCH] powerpc: crypto/vmx: clean up generated files
From: Naveen N. Rao @ 2016-11-16 11:27 UTC (permalink / raw)
To: Michael Ellerman
Cc: Leonidas S. Barbosa, linuxppc-dev, Herbert Xu,
Paulo Flabiano Smorigo, linux-crypto
In-Reply-To: <87oa1fyc7s.fsf@concordia.ellerman.id.au>
On 2016/11/16 09:02PM, Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>
> > ..as stray .S files result in build errors, especially when using
> > cross-compilers.
>
> They should be cleaned on make clean, so adding them to clean-files
> seems correct.
>
> > More specifically, the generated .S files are endian-specific and will break
> > subsequent builds targeting the other endian architecture.
>
> But that indicates we're missing an if_changed somewhere, ie. switching
> endian should cause them to be regenerated.
>
> Also they should be generated into $(obj) not $(src) I think.
>
> How about this?
Nice!
>
> diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
> index de6e241..52f6ae9 100644
> --- a/drivers/crypto/vmx/Makefile
> +++ b/drivers/crypto/vmx/Makefile
> @@ -10,10 +10,10 @@ endif
> quiet_cmd_perl = PERL $@
> cmd_perl = $(PERL) $(<) $(TARGET) > $(@)
>
Looks like we also need:
targets += aesp8-ppc.S ghashp8-ppc.S
> -$(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
> - $(call cmd,perl)
> +$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
> + $(call if_changed,perl)
>
> -$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
> - $(call cmd,perl)
> +$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
> + $(call if_changed,perl)
>
> .PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
I will send a v2 with these changes.
Thanks,
Naveen
^ permalink raw reply
* [PATCH] powerpc: crypto/vmx: various build fixes
From: Naveen N. Rao @ 2016-11-16 15:11 UTC (permalink / raw)
To: Leonidas S. Barbosa, Herbert Xu, Michael Ellerman
Cc: Paulo Flabiano Smorigo, linux-crypto, linuxppc-dev
First up, clean up the generated .S files properly on a 'make clean'.
Secondly, force re-generation of these files when building for different
endian-ness than what was built previously. Finally, generate the new
files in the build tree, rather than the source tree.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
Michael,
I've added your SOB here though you didn't explicitly include it in your
previous mail. I hope that's fine from your end.
- Naveen
drivers/crypto/vmx/Makefile | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index de6e241..55f7c39 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -10,10 +10,12 @@ endif
quiet_cmd_perl = PERL $@
cmd_perl = $(PERL) $(<) $(TARGET) > $(@)
-$(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
- $(call cmd,perl)
+targets += aesp8-ppc.S ghashp8-ppc.S
+
+$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
+ $(call if_changed,perl)
-$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
- $(call cmd,perl)
+$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
+ $(call if_changed,perl)
-.PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
+clean-files := aesp8-ppc.S ghashp8-ppc.S
--
2.10.2
^ permalink raw reply related
* crypto: caam warning fix, was: master build: 0 failures 1 warnings (v4.9-rc5-177-g81bcfe5)
From: Arnd Bergmann @ 2016-11-16 16:40 UTC (permalink / raw)
To: linaro-kernel
Cc: Build bot for Mark Brown, kernel-build-reports, Horia Geantă,
Herbert Xu, linux-crypto
In-Reply-To: <E1c6kSQ-0008UC-DM@optimist>
On Tuesday, November 15, 2016 8:35:54 PM CET Build bot for Mark Brown wrote:
> Tree/Branch: master
> Git describe: v4.9-rc5-177-g81bcfe5
> Commit: 81bcfe5e48 Merge tag 'trace-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
>
> Build Time: 87 min 40 sec
>
> Passed: 10 / 10 (100.00 %)
> Failed: 0 / 10 ( 0.00 %)
>
> Errors: 0
> Warnings: 1
> Section Mismatches: 0
>
> -------------------------------------------------------------------------------
> defconfigs with issues (other than build errors):
> 1 warnings 0 mismatches : arm64-allmodconfig
>
> -------------------------------------------------------------------------------
>
> Warnings Summary: 1
> 1 ../include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
>
Hi Herbert,
This is currently the only build warning reported for v4.9, and you have merged
the fix for v4.10 in
d69985a07692 ("crypto: caam - fix type mismatch warning")
Any chance you can send this for v4.9 so we have a clean build?
Thanks,
Arnd
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix handling of RSA exponent on a v5 device
From: Gary R Hook @ 2016-11-16 17:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: Gary R Hook, linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161116090125.GC29644@gondor.apana.org.au>
On 11/16/2016 03:01 AM, Herbert Xu wrote:
> On Tue, Nov 15, 2016 at 03:41:25PM -0600, Gary R Hook wrote:
>> On 11/13/2016 03:49 AM, Herbert Xu wrote:
>>> On Tue, Nov 01, 2016 at 02:05:05PM -0500, Gary R Hook wrote:
>>>> The exponent size in the ccp_op structure is in bits. A v5
>>>> CCP requires the exponent size to be in bytes, so convert
>>>> the size from bits to bytes when populating the descriptor.
>>>>
>>>> The current code references the exponent in memory, but
>>>> these fields have not been set since the exponent is
>>>> actually store in the LSB. Populate the descriptor with
>>>> the LSB location (address).
>>>>
>>>> Signed-off-by: Gary R Hook <gary.hook@amd.com>
>>>
>>> Patch applied. Thanks.
>>>
>>
>> Thanks, Herbert.
>>
>> Is there a possibility of getting this pushed to 4.9, being
>> it's a bug fix?
>
> I thought ccp doesn't support RSA yet or is there another entry
> path into this code?
The kernel crypto layer does not yet support RSA, true. However, we
designed the ccp.ko layer to be available to anyone that wants to use
it. The underlying module currently has differing behavior/results
between the v3 and v5 implementations of the RSA command function.
This patch fixes the borked v5 code.
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* BUG: algif_hash crash with extra recv() in 4.9-rc5
From: Mat Martineau @ 2016-11-16 19:17 UTC (permalink / raw)
To: linux-crypto, herbert
Herbert -
Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
dereference crash in algif_hash when recv() is called twice like this:
send(sk, data, len, MSG_MORE);
recv(sk, hash1, len, 0);
recv(sk, hash2, len, 0);
In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
second recv triggers this:
[ 53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
(shash_ahash_digest+0x23 corresponds to the second line of the function,
which accesses sg->offset)
[ 53.042572] PGD 131f74067 [ 53.042796] PUD 13140f067
PMD 0 [ 53.043093]
[ 53.043236] Oops: 0000 [#1] SMP
[ 53.043511] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle iptable_raw iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hda_core ghash_clmulni_intel snd_hwdep snd_seq ppdev snd_seq_device snd_pcm joydev snd_timer virtio_balloon snd pcspkr acpi_cpufreq tpm_tis parport_pc parport tpm_tis_core tpm i2c_piix4 soundcore qemu_fw_cfg nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_net virtio_blk virtio_console qxl
drm_kms_helper ttm ata_generic crc32c_intel drm virtio_pci serio_raw floppy virtio_ring pata_acpi virtio
[ 53.050799] CPU: 0 PID: 1069 Comm: test-checksum Not tainted 4.9.0-rc5+ #75
[ 53.051393] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 53.052131] task: ffff8d2d72430000 task.stack: ffff95b280fe4000
[ 53.052622] RIP: 0010:[<ffffffffa73fdfb3>] [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
[ 53.053363] RSP: 0018:ffff95b280fe7d40 EFLAGS: 00010246
[ 53.053827] RAX: 0000000000001000 RBX: ffff8d2d71c8bbf8 RCX: 0000000000000000
[ 53.054424] RDX: 0000000000000000 RSI: ffff8d2d71c8bbf8 RDI: ffff8d2d71c8bba8
[ 53.055014] RBP: ffff95b280fe7d60 R08: 00000000001ddb00 R09: ffff8d2d71f03810
[ 53.055603] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa73fe0c0
[ 53.056210] R13: ffff8d2d71c8bba8 R14: ffff95b280fe7e30 R15: 0000000000000000
[ 53.056822] FS: 00007f91f1138700(0000) GS:ffff8d2d7b200000(0000) knlGS:0000000000000000
[ 53.057502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 53.058004] CR2: 0000000000000010 CR3: 000000013149e000 CR4: 00000000003406f0
[ 53.058616] Stack:
[ 53.058796] ffff8d2d71c8bba8 ffffffffa73fe0c0 ffff8d2d71c8d000 ffff95b280fe7e30
[ 53.059473] ffff95b280fe7d70 ffffffffa73fe0e4 ffff95b280fe7d98 ffffffffa73fd4c9
[ 53.060153] ffff8d2d71c8b800 ffff8d2d71c8b800 0000000000000010 ffff95b280fe7da8
[ 53.060831] Call Trace:
[ 53.061051] [<ffffffffa73fe0c0>] ? shash_ahash_digest+0x130/0x130
[ 53.061601] [<ffffffffa73fe0e4>] shash_async_digest+0x24/0x30
[ 53.062119] [<ffffffffa73fd4c9>] crypto_ahash_op+0x29/0x70
[ 53.062621] [<ffffffffa73fd566>] crypto_ahash_digest+0x16/0x20
[ 53.063149] [<ffffffffa7415519>] hash_recvmsg+0x1a9/0x1d0
[ 53.063655] [<ffffffffa777180d>] sock_recvmsg+0x3d/0x50
[ 53.064129] [<ffffffffa7771a4d>] SYSC_recvfrom+0xdd/0x160
[ 53.064786] [<ffffffffa70d3339>] ? task_work_run+0x99/0xc0
[ 53.065501] [<ffffffffa710db55>] ? trace_hardirqs_on_caller+0xf5/0x1b0
[ 53.066313] [<ffffffffa700301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 53.067069] [<ffffffffa777318e>] SyS_recvfrom+0xe/0x10
[ 53.067706] [<ffffffffa78f1101>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 53.068476] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 b8 00 10 00 00 48 89 e5 41 56 41 55 41 54 53 49 89 fd 48 8b 4f 38 41 8b 55 30 48 89 f3 <8b> 79 10 29 f8 39 41 14 0f 46 41 14 39 c2 72 3a 48 8b 06 48 89
[ 53.071995] RIP [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
[ 53.072800] RSP <ffff95b280fe7d40>
[ 53.073259] CR2: 0000000000000010
[ 53.073700] ---[ end trace 6249058719c9daea ]---
If I revert 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is no crash.
Regards,
--
Mat Martineau
Intel OTC
^ permalink raw reply
* [REGRESSION] 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
From: Laura Abbott @ 2016-11-17 0:21 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, Linux Kernel Mailing List, Russell King - ARM Linux
Hi,
Fedora got a bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1395896
of an oops with this program:
#include <linux/if_alg.h>
#include <stddef.h>
#include <sys/socket.h>
int main(int argc, char *argv[]) {
static const union {
struct sockaddr sa;
struct sockaddr_alg alg;
} sa = {
.alg.salg_family = AF_ALG,
.alg.salg_type = "hash",
.alg.salg_name = "sha256",
};
char c;
int fd1, fd2;
fd1 = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(fd1, &sa.sa, sizeof(sa));
fd2 = accept(fd1, NULL, 0);
recv(fd2, &c, sizeof(c), 0);
return 0;
}
[ 10.802304] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 10.803970] IP: [<ffffffff812f743e>] shash_ahash_digest+0x1e/0x100
[ 10.805046] PGD eb37067 PUD 12425067 PMD 0
[ 10.806019] Oops: 0000 [#1] SMP
[ 10.806702] Modules linked in:
[ 10.807421] CPU: 0 PID: 1098 Comm: a.out Not tainted 4.8.0-rc1+ #29
[ 10.808444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 10.809839] task: ffff880010a92400 task.stack: ffff880012458000
[ 10.810653] RIP: 0010:[<ffffffff812f743e>] [<ffffffff812f743e>] shash_ahash_digest+0x1e/0x100
[ 10.811979] RSP: 0018:ffff88001245bd48 EFLAGS: 00010246
[ 10.812730] RAX: 0000000000001000 RBX: ffff88001249b390 RCX: 0000000000000000
[ 10.814419] RDX: 0000000000000000 RSI: ffff88001249b390 RDI: ffff88001249b340
[ 10.815303] RBP: ffff88001245bd68 R08: ffff88000eb54fa0 R09: 0000000000000000
[ 10.816126] R10: ffff88000eb547d0 R11: 0000000000000001 R12: ffffffff812f7520
[ 10.816946] R13: ffff88001249b340 R14: ffff88001245be38 R15: 0000000000000000
[ 10.818098] FS: 00007f1849f3a700(0000) GS:ffff880011800000(0000) knlGS:0000000000000000
[ 10.819644] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 10.820370] CR2: 0000000000000008 CR3: 000000000eb36000 CR4: 00000000000006f0
[ 10.821198] Stack:
[ 10.821641] ffff88001249b340 ffffffff812f7520 ffff880012498c18 ffff88001245be38
[ 10.822905] ffff88001245bd78 ffffffff812f753f ffff88001245bda0 ffffffff812f6aa4
[ 10.824168] ffff88001249b060 ffff88001249b060 0000000000000001 ffff88001245bdb0
[ 10.825434] Call Trace:
[ 10.825910] [<ffffffff812f7520>] ? shash_ahash_digest+0x100/0x100
[ 10.826663] [<ffffffff812f753f>] shash_async_digest+0x1f/0x30
[ 10.827389] [<ffffffff812f6aa4>] crypto_ahash_op+0x24/0x60
[ 10.828097] [<ffffffff812f6b31>] crypto_ahash_digest+0x11/0x20
[ 10.828835] [<ffffffff813087a4>] hash_recvmsg+0x1a4/0x1c0
[ 10.829539] [<ffffffff817253b8>] sock_recvmsg+0x38/0x40
[ 10.830232] [<ffffffff817255ab>] SYSC_recvfrom+0xcb/0x130
[ 10.830937] [<ffffffff81724ccf>] ? sock_map_fd+0x3f/0x60
[ 10.831635] [<ffffffff81726729>] SyS_recvfrom+0x9/0x10
[ 10.832317] [<ffffffff81922572>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 10.833091] Code: 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 b8 00 10 00 00 48 89 e5 41 56 41 55 41 54 53 49 89 fd 48 8b 4f 38 41 8b 55 30 48 89 f3 <8b> 79 08 29 f8 39 41 0c 0f 46 41 0c 39 c2 73 74 48 8b 31 48 83
[ 10.838754] RIP [<ffffffff812f743e>] shash_ahash_digest+0x1e/0x100
[ 10.839560] RSP <ffff88001245bd48>
[ 10.840112] CR2: 0000000000000008
[ 10.840674] ---[ end trace 4314dcc948f7acad ]---
[ 10.841320] Kernel panic - not syncing: Fatal exception
[ 10.842106] Kernel Offset: disabled
It looks like hash_recvmsg sets the sg to NULL with
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
which then blows up when crypto_ahash_digest -> hash_ahash_digest
tries to access it.
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH] powerpc: crypto/vmx: various build fixes
From: Michael Ellerman @ 2016-11-17 0:51 UTC (permalink / raw)
To: Naveen N. Rao, Leonidas S. Barbosa, Herbert Xu
Cc: Paulo Flabiano Smorigo, linux-crypto, linuxppc-dev
In-Reply-To: <20161116151146.15720-1-naveen.n.rao@linux.vnet.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> First up, clean up the generated .S files properly on a 'make clean'.
> Secondly, force re-generation of these files when building for different
> endian-ness than what was built previously. Finally, generate the new
> files in the build tree, rather than the source tree.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> Michael,
> I've added your SOB here though you didn't explicitly include it in your
> previous mail. I hope that's fine from your end.
Yeah that's fine, thanks.
Crypto patches usually have a subject like:
crypto: vmx - Various build fixes
But maybe Herbert can fix it up for you when he applies this.
cheers
^ permalink raw reply
* 12225 linux-crypto
From: isaac @ 2016-11-17 3:14 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: EMAIL_2200126_linux-crypto.zip --]
[-- Type: application/zip, Size: 4839 bytes --]
^ permalink raw reply
* 22773 linux-crypto
From: membership @ 2016-11-17 4:56 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: EMAIL_284983759749_linux-crypto.zip --]
[-- Type: application/zip, Size: 4107 bytes --]
^ permalink raw reply
* Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez391@gmail.com
From: beer.c@gmx.com @ 2016-11-18 0:55 UTC (permalink / raw)
To: hp627@daum.net
Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez391@gmail.com
^ permalink raw reply
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-11-17 8:05 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: Herbert Xu, davem, maxime.ripard, wens, linux-kernel,
linux-crypto, linux-arm-kernel
In-Reply-To: <CANc+2y63p1b5ATDY0oU4nLckk9CJhSs3CXGHy=NwoXn_awP9aA@mail.gmail.com>
On Tue, Oct 18, 2016 at 09:39:17PM +0530, PrasannaKumar Muralidharan wrote:
> Hi Corentin,
>
> I have a few minor comments.
>
> On 18 October 2016 at 18:04, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> > From: LABBE Corentin <clabbe.montjoie@gmail.com>
> >
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/Kconfig | 8 ++++
> > drivers/crypto/sunxi-ss/Makefile | 1 +
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +++++++
> > drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 ++++++++++++++++++++++++++++++++
> > drivers/crypto/sunxi-ss/sun4i-ss.h | 8 ++++
> > 5 files changed, 101 insertions(+)
> > create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..38f7aca 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
> > To compile this driver as a module, choose M here: the module
> > will be called sun4i-ss.
> >
> > +config CRYPTO_DEV_SUN4I_SS_PRNG
> > + bool "Support for Allwinner Security System PRNG"
> > + depends on CRYPTO_DEV_SUN4I_SS
> > + select HW_RANDOM
> > + help
> > + This driver provides kernel-side support for the Pseudo-Random
> > + Number Generator found in the Security System.
> > +
> > config CRYPTO_DEV_ROCKCHIP
> > tristate "Rockchip's Cryptographic Engine driver"
> > depends on OF && ARCH_ROCKCHIP
> > diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
> > index 8f4c7a2..ca049ee 100644
> > --- a/drivers/crypto/sunxi-ss/Makefile
> > +++ b/drivers/crypto/sunxi-ss/Makefile
> > @@ -1,2 +1,3 @@
> > obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
> > sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
> > +sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index 3ac6c6c..fa739de 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > }
> > }
> > platform_set_drvdata(pdev, ss);
> > +
> > +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> > + /* Voluntarily made the PRNG optional */
> > + err = sun4i_ss_hwrng_register(&ss->hwrng);
> > + if (!err)
> > + dev_info(ss->dev, "sun4i-ss PRNG loaded");
> > + else
> > + dev_err(ss->dev, "sun4i-ss PRNG failed");
> > +#endif
> > +
> > return 0;
> > error_alg:
> > i--;
> > @@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
> > int i;
> > struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
> >
> > +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> > + sun4i_ss_hwrng_remove(&ss->hwrng);
> > +#endif
> > +
> > for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
> > switch (ss_algs[i].type) {
> > case CRYPTO_ALG_TYPE_ABLKCIPHER:
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > new file mode 100644
> > index 0000000..95fadb7
> > --- /dev/null
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > @@ -0,0 +1,70 @@
> > +#include "sun4i-ss.h"
> > +
> > +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> > +{
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + get_random_bytes(ss->seed, SS_SEED_LEN);
> > +
> > + return 0;
> > +}
> > +
> > +static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
> > + size_t max, bool wait)
> > +{
> > + int i;
> > + u32 v;
> > + u32 *data = buf;
> > + const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
> > + size_t len;
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + len = min_t(size_t, SS_DATA_LEN, max);
> > +
> > + spin_lock_bh(&ss->slock);
>
> Is spin_lock_bh really required here? I could see it is being used in
> sun4i-ss-hash.c but could not find any comment/info about the need.
>
No for sun4i-ss-hwrng it seems not required and work perfecly without _bh
> > + writel(mode, ss->base + SS_CTL);
> > +
> > + /* write the seed */
> > + for (i = 0; i < SS_SEED_LEN / 4; i++)
> > + writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
> > + writel(mode | SS_PRNG_START, ss->base + SS_CTL);
> > +
> > + /* Read the random data */
> > + readsl(ss->base + SS_TXFIFO, data, len / 4);
> > +
> > + if (len % 4 > 0) {
> > + v = readl(ss->base + SS_TXFIFO);
> > + memcpy(data + len / 4, &v, len % 4);
> > + }
>
> hwrng core asks for "rng_buffer_size()" of data which is a multiple of
> 4. So len % 4 will be 0. I think the above check is not required. Feel
> free to correct if I am wrong.
>
Agree, I removed that in v2
Thanks
Corentin Labbe
^ permalink raw reply
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-11-17 8:07 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, davem, maxime.ripard, wens, linux-kernel, linux-crypto,
linux-arm-kernel
In-Reply-To: <1722218.eZlGktOxfL@tauon.atsec.com>
On Tue, Oct 18, 2016 at 04:24:22PM +0200, Stephan Mueller wrote:
> Am Dienstag, 18. Oktober 2016, 14:34:27 CEST schrieb Corentin Labbe:
>
> Hi Corentin,
>
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c new file mode 100644
> > index 0000000..95fadb7
> > --- /dev/null
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> > @@ -0,0 +1,70 @@
> > +#include "sun4i-ss.h"
> > +
> > +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> > +{
> > + struct sun4i_ss_ctx *ss;
> > +
> > + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> > + get_random_bytes(ss->seed, SS_SEED_LEN);
>
> Is it wise to call get_random_bytes once in the init function and never
> thereafter?
>
> This init function may be called during boot time of the kernel at which the
> input_pool may not yet have received sufficient amounts of entropy.
>
> What about registering a callback with add_random_ready_callback and seed
> again when sufficient entropy was collected?
>
Seed again, or just do not seed (and so return -EAGAIN for read() function) until ready_callback ?
Thanks
Corentin Labbe
^ permalink raw reply
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Stephan Mueller @ 2016-11-17 8:18 UTC (permalink / raw)
To: Corentin Labbe
Cc: herbert, davem, maxime.ripard, wens, linux-kernel, linux-crypto,
linux-arm-kernel
In-Reply-To: <20161117080748.GB25394@Red>
Am Donnerstag, 17. November 2016, 09:07:48 CET schrieb Corentin Labbe:
Hi Corentin,
>
> Seed again, or just do not seed (and so return -EAGAIN for read() function)
> until ready_callback ?
This is your choice. But for the start sequence, you should not simply rely on
get_random_bytes.
For the DRBG in crypto/drbg.c we seed with get_random_bytes and the Jitter RNG
in case the input_pool is not fully seeded. The reseed trigger is reduced to
50 DRBG requests, i.e. after 50 requests, the DRBG again reseeds from
get_random_bytes / Jitter RNG. This is continued until the input_pool has been
sufficiently seeded (i.e. the registered callback is triggered). At that
point, another get_random_bytes call is made, the Jitter RNG is deactivated
and the reseed threshold is set to the common value.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] powerpc: crypto/vmx: various build fixes
From: Herbert Xu @ 2016-11-17 13:03 UTC (permalink / raw)
To: Michael Ellerman
Cc: Leonidas S. Barbosa, Naveen N. Rao, linuxppc-dev, linux-crypto,
Paulo Flabiano Smorigo
In-Reply-To: <87inrnx70z.fsf@concordia.ellerman.id.au>
On Thu, Nov 17, 2016 at 11:51:56AM +1100, Michael Ellerman wrote:
>
> But maybe Herbert can fix it up for you when he applies this.
Sure I can fix it up.
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] powerpc: crypto/vmx: various build fixes
From: Naveen N. Rao @ 2016-11-17 14:22 UTC (permalink / raw)
To: Herbert Xu
Cc: Leonidas S. Barbosa, linuxppc-dev, linux-crypto,
Paulo Flabiano Smorigo
In-Reply-To: <20161117130311.GA1839@gondor.apana.org.au>
On 2016/11/17 09:03PM, Herbert Xu wrote:
> On Thu, Nov 17, 2016 at 11:51:56AM +1100, Michael Ellerman wrote:
> >
> > Crypto patches usually have a subject like:
> >
> > crypto: vmx - Various build fixes
Ok.
> >
> > But maybe Herbert can fix it up for you when he applies this.
>
> Sure I can fix it up.
Thanks,
- Naveen
^ permalink raw reply
* Re: [PATCH] powerpc: crypto/vmx: various build fixes
From: Herbert Xu @ 2016-11-17 15:40 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Leonidas S. Barbosa, linuxppc-dev, linux-crypto,
Paulo Flabiano Smorigo
In-Reply-To: <20161116151146.15720-1-naveen.n.rao@linux.vnet.ibm.com>
On Wed, Nov 16, 2016 at 08:41:46PM +0530, Naveen N. Rao wrote:
> First up, clean up the generated .S files properly on a 'make clean'.
> Secondly, force re-generation of these files when building for different
> endian-ness than what was built previously. Finally, generate the new
> files in the build tree, rather than the source tree.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Patch applied. 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: add virtio-crypto driver
From: Benedetto, Salvatore @ 2016-11-17 15:55 UTC (permalink / raw)
To: Gonglei, qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linux-crypto@vger.kernel.org
Cc: pasic@linux.vnet.ibm.com, weidong.huang@huawei.com,
claudio.fontana@huawei.com, mst@redhat.com, luonengjun@huawei.com,
hanweidong@huawei.com, Zeng, Xin, peter.huangpeng@huawei.com,
Benedetto, Salvatore, xuquan8@huawei.com, stefanha@redhat.com,
jianjay.zhou@huawei.com, cornelia.huck@de.ibm.com,
arei.gonglei@hotmail.com, davem@davemloft.net,
wu.wubin@huawei.com, herbert@gondor.apana.org.au
In-Reply-To: <1479106074-32036-1-git-send-email-arei.gonglei@huawei.com>
Hi Gonglei,
...
> +
> +static int virtio_crypto_alg_ablkcipher_init_session(
> + struct virtio_crypto_ablkcipher_ctx *ctx,
> + int alg, const uint8_t *key,
> + unsigned int keylen,
> + int encrypt)
> +{
> + struct scatterlist outhdr, key_sg, inhdr, *sgs[3];
> + unsigned int tmp;
> + struct virtio_crypto_session_input input;
> + struct virtio_crypto_op_ctrl_req ctrl;
> + struct virtio_crypto *vcrypto = ctx->vcrypto;
> + int op = encrypt ? VIRTIO_CRYPTO_OP_ENCRYPT :
> VIRTIO_CRYPTO_OP_DECRYPT;
> + int err;
> + unsigned int num_out = 0, num_in = 0;
> +
> + memset(&ctrl, 0, sizeof(ctrl));
> + memset(&input, 0, sizeof(input));
> + /* Pad ctrl header */
> + ctrl.header.opcode =
> cpu_to_le32(VIRTIO_CRYPTO_CIPHER_CREATE_SESSION);
> + ctrl.header.algo = cpu_to_le32((uint32_t)alg);
> + /* Set the default dataqueue id to 0 */
> + ctrl.header.queue_id = 0;
> +
> + input.status = cpu_to_le32(VIRTIO_CRYPTO_ERR);
> + /* Pad cipher's parameters */
> + ctrl.u.sym_create_session.op_type =
> + cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER);
> + ctrl.u.sym_create_session.u.cipher.para.algo = ctrl.header.algo;
> + ctrl.u.sym_create_session.u.cipher.para.keylen =
> cpu_to_le32(keylen);
> + ctrl.u.sym_create_session.u.cipher.para.op = cpu_to_le32(op);
> +
> + sg_init_one(&outhdr, &ctrl, sizeof(ctrl));
I believe this won't work when the new virtually-mapped kernel stack (VMAP_STACK)
is enabled.
Regards,
Salvatore
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix handling of RSA exponent on a v5 device
From: Gary R Hook @ 2016-11-17 14:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161117131447.GA2029@gondor.apana.org.au>
On 11/17/2016 07:14 AM, Herbert Xu wrote:
> On Wed, Nov 16, 2016 at 11:25:19AM -0600, Gary R Hook wrote:
>>
>> The kernel crypto layer does not yet support RSA, true. However, we
>> designed the ccp.ko layer to be available to anyone that wants to use
>> it. The underlying module currently has differing behavior/results
>> between the v3 and v5 implementations of the RSA command function.
>> This patch fixes the borked v5 code.
>
> Do you mean that an out-of-tree module could enter the buggy
> code path?
I mean that anything that can call ccp_run_cmd() (in ccp.ko) can run
into a problem, yes. Is this likely? We don't know, as we don't know
if anyone actually uses this layer. But it _is_ possible to find the
problem.
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: BUG: algif_hash crash with extra recv() in 4.9-rc5
From: Mat Martineau @ 2016-11-17 16:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, Laura Abbott, Russell King - ARM Linux
In-Reply-To: <20161117140757.GA1149@gondor.apana.org.au>
Herbert,
On Thu, 17 Nov 2016, Herbert Xu wrote:
> On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
>>
>> Herbert -
>>
>> Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
>> dereference crash in algif_hash when recv() is called twice like this:
>>
>> send(sk, data, len, MSG_MORE);
>> recv(sk, hash1, len, 0);
>> recv(sk, hash2, len, 0);
>>
>> In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
>> second recv triggers this:
>>
>> [ 53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>> [ 53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
>
> Ugh. It looks like the shash wrapper is incorrectly dereferencing
> the SG list even when the length is zero. Rather than fixing it
> I'm just going to make algif_hash do the safe thing of doing an
> init followed by a final.
Thanks for the patch. For my test code, it fixed the crash and restored
the previous behavior.
Regards,
Mat
> ---8<---
> Subject: crypto: algif_hash - Fix NULL hash crash with shash
>
> Recently algif_hash has been changed to allow null hashes. This
> triggers a bug when used with an shash algorithm whereby it will
> cause a crash during the digest operation.
>
> This patch fixes it by avoiding the digest operation and instead
> doing an init followed by a final which avoids the buggy code in
> shash.
>
> This patch also ensures that the result buffer is freed after an
> error so that it is not returned as a genuine hash result on the
> next recv call.
>
> The shash/ahash wrapper code will be fixed later to handle this
> case correctly.
>
> Fixes: 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 2d8466f..05e21b4 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -214,23 +214,26 @@ static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>
> ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
>
> - if (ctx->more) {
> + if (!result) {
> + err = af_alg_wait_for_completion(
> + crypto_ahash_init(&ctx->req),
> + &ctx->completion);
> + if (err)
> + goto unlock;
> + }
> +
> + if (!result || ctx->more) {
> ctx->more = 0;
> err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
> &ctx->completion);
> if (err)
> goto unlock;
> - } else if (!result) {
> - err = af_alg_wait_for_completion(
> - crypto_ahash_digest(&ctx->req),
> - &ctx->completion);
> }
>
> err = memcpy_to_msg(msg, ctx->result, len);
>
> - hash_free_result(sk, ctx);
> -
> unlock:
> + hash_free_result(sk, ctx);
> release_sock(sk);
>
> return err ?: len;
> --
> 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
>
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix handling of RSA exponent on a v5 device
From: Herbert Xu @ 2016-11-17 13:14 UTC (permalink / raw)
To: Gary R Hook; +Cc: Gary R Hook, linux-crypto, thomas.lendacky, davem
In-Reply-To: <368b41ee-45e3-c330-10c5-16fcc22d3d16@amd.com>
On Wed, Nov 16, 2016 at 11:25:19AM -0600, Gary R Hook wrote:
>
> The kernel crypto layer does not yet support RSA, true. However, we
> designed the ccp.ko layer to be available to anyone that wants to use
> it. The underlying module currently has differing behavior/results
> between the v3 and v5 implementations of the RSA command function.
> This patch fixes the borked v5 code.
Do you mean that an out-of-tree module could enter the buggy
code path?
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: BUG: algif_hash crash with extra recv() in 4.9-rc5
From: Herbert Xu @ 2016-11-17 14:07 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-crypto, Laura Abbott, Russell King - ARM Linux
In-Reply-To: <alpine.OSX.2.20.1611161027010.67352@mjmartin-mac01.local>
On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
>
> Herbert -
>
> Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
> dereference crash in algif_hash when recv() is called twice like this:
>
> send(sk, data, len, MSG_MORE);
> recv(sk, hash1, len, 0);
> recv(sk, hash2, len, 0);
>
> In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
> second recv triggers this:
>
> [ 53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [ 53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
Ugh. It looks like the shash wrapper is incorrectly dereferencing
the SG list even when the length is zero. Rather than fixing it
I'm just going to make algif_hash do the safe thing of doing an
init followed by a final.
Thanks,
---8<---
Subject: crypto: algif_hash - Fix NULL hash crash with shash
Recently algif_hash has been changed to allow null hashes. This
triggers a bug when used with an shash algorithm whereby it will
cause a crash during the digest operation.
This patch fixes it by avoiding the digest operation and instead
doing an init followed by a final which avoids the buggy code in
shash.
This patch also ensures that the result buffer is freed after an
error so that it is not returned as a genuine hash result on the
next recv call.
The shash/ahash wrapper code will be fixed later to handle this
case correctly.
Fixes: 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 2d8466f..05e21b4 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -214,23 +214,26 @@ static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
- if (ctx->more) {
+ if (!result) {
+ err = af_alg_wait_for_completion(
+ crypto_ahash_init(&ctx->req),
+ &ctx->completion);
+ if (err)
+ goto unlock;
+ }
+
+ if (!result || ctx->more) {
ctx->more = 0;
err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
&ctx->completion);
if (err)
goto unlock;
- } else if (!result) {
- err = af_alg_wait_for_completion(
- crypto_ahash_digest(&ctx->req),
- &ctx->completion);
}
err = memcpy_to_msg(msg, ctx->result, len);
- hash_free_result(sk, ctx);
-
unlock:
+ hash_free_result(sk, ctx);
release_sock(sk);
return err ?: len;
--
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: crypto: caam warning fix, was: master build: 0 failures 1 warnings (v4.9-rc5-177-g81bcfe5)
From: Herbert Xu @ 2016-11-17 15:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Build bot for Mark Brown, kernel-build-reports,
Horia Geantă, linux-crypto
In-Reply-To: <5255539.MpGQJX1bep@wuerfel>
On Wed, Nov 16, 2016 at 05:40:41PM +0100, Arnd Bergmann wrote:
>
> This is currently the only build warning reported for v4.9, and you have merged
> the fix for v4.10 in
>
> d69985a07692 ("crypto: caam - fix type mismatch warning")
>
> Any chance you can send this for v4.9 so we have a clean build?
OK I'll push that along.
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: crypto: caam warning fix, was: master build: 0 failures 1 warnings (v4.9-rc5-177-g81bcfe5)
From: Arnd Bergmann @ 2016-11-17 15:42 UTC (permalink / raw)
To: Herbert Xu
Cc: linaro-kernel, Build bot for Mark Brown, kernel-build-reports,
Horia Geantă, linux-crypto
In-Reply-To: <20161117153403.GA1687@gondor.apana.org.au>
On Thursday, November 17, 2016 11:34:04 PM CET Herbert Xu wrote:
> On Wed, Nov 16, 2016 at 05:40:41PM +0100, Arnd Bergmann wrote:
> >
> > This is currently the only build warning reported for v4.9, and you have merged
> > the fix for v4.10 in
> >
> > d69985a07692 ("crypto: caam - fix type mismatch warning")
> >
> > Any chance you can send this for v4.9 so we have a clean build?
>
> OK I'll push that along.
>
>
Thanks!
Arnd
^ permalink raw reply
* Re: BUG: algif_hash crash with extra recv() in 4.9-rc5
From: Laura Abbott @ 2016-11-17 21:20 UTC (permalink / raw)
To: Herbert Xu, Mat Martineau; +Cc: linux-crypto, Russell King - ARM Linux
In-Reply-To: <20161117140757.GA1149@gondor.apana.org.au>
On 11/17/2016 06:07 AM, Herbert Xu wrote:
> On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
>>
>> Herbert -
>>
>> Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
>> dereference crash in algif_hash when recv() is called twice like this:
>>
>> send(sk, data, len, MSG_MORE);
>> recv(sk, hash1, len, 0);
>> recv(sk, hash2, len, 0);
>>
>> In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
>> second recv triggers this:
>>
>> [ 53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>> [ 53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
>
> Ugh. It looks like the shash wrapper is incorrectly dereferencing
> the SG list even when the length is zero. Rather than fixing it
> I'm just going to make algif_hash do the safe thing of doing an
> init followed by a final.
>
> Thanks,
>
> ---8<---
> Subject: crypto: algif_hash - Fix NULL hash crash with shash
>
> Recently algif_hash has been changed to allow null hashes. This
> triggers a bug when used with an shash algorithm whereby it will
> cause a crash during the digest operation.
>
> This patch fixes it by avoiding the digest operation and instead
> doing an init followed by a final which avoids the buggy code in
> shash.
>
> This patch also ensures that the result buffer is freed after an
> error so that it is not returned as a genuine hash result on the
> next recv call.
>
> The shash/ahash wrapper code will be fixed later to handle this
> case correctly.
>
> Fixes: 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 2d8466f..05e21b4 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -214,23 +214,26 @@ static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>
> ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
>
> - if (ctx->more) {
> + if (!result) {
> + err = af_alg_wait_for_completion(
> + crypto_ahash_init(&ctx->req),
> + &ctx->completion);
> + if (err)
> + goto unlock;
> + }
> +
> + if (!result || ctx->more) {
> ctx->more = 0;
> err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
> &ctx->completion);
> if (err)
> goto unlock;
> - } else if (!result) {
> - err = af_alg_wait_for_completion(
> - crypto_ahash_digest(&ctx->req),
> - &ctx->completion);
> }
>
> err = memcpy_to_msg(msg, ctx->result, len);
>
> - hash_free_result(sk, ctx);
> -
> unlock:
> + hash_free_result(sk, ctx);
> release_sock(sk);
>
> return err ?: len;
>
Confirmed to work for me. You can take that as a Tested-by.
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Sandy Harris @ 2016-11-18 1:07 UTC (permalink / raw)
To: Corentin Labbe
Cc: Herbert Xu, David S. Miller, maxime.ripard, wens, LKML,
linux-crypto, linux-arm-kernel
In-Reply-To: <1476794067-28563-1-git-send-email-clabbe.montjoie@gmail.com>
Add Ted T'so to cc list. Shouldn't he be included on anything affecting
the random(4) driver?
On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> From: LABBE Corentin <clabbe.montjoie@gmail.com>
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
Which is it? A PRNG & a HW RNG are quite different things.
It would, in general, be a fairly serious error to treat a PRNG
as a HWRNG.
If it is just a prng (which it appears to be from a quick look
at your code) then it is not clear it is useful since the
random(4) driver already has two PRNGs. It might be
but I cannot tell.
^ permalink raw reply
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