Re: general protection fault in __crypto_alg_lookup

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:49:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> SELinux: unrecognized netlink message: protocol=0 nlmsg_type=256
> sclass=netlink_route_socket pig=17315 comm=syz-executor6
> SELinux: unrecognized netlink message: protocol=0 nlmsg_type=256
> sclass=netlink_route_socket pig=17326 comm=syz-executor6
> general protection fault:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 17336 Comm: syz-executor7 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__crypto_alg_lookup+0x43/0x190 crypto/api.c:63
> RSP: 0018:c9d7fcb8 EFLAGS: 00010216
> RAX: 0001 RBX: 623e2d6261746826 RCX: 816741f3
> RDX: 00d9 RSI: c90001a01000 RDI: 8801f9d11891
> RBP: c9d7fd00 R08: 0001 R09: 0001
> R10: c9d7fc80 R11:  R12: 
> R13: 72612f66 R14: 240e R15: 040f
> FS:  7ff6c7ec5700() GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20f35000 CR3: 0001fce0e004 CR4: 001606e0
> Call Trace:
>  crypto_alg_lookup+0x31/0x50 crypto/api.c:201
>  crypto_larval_lookup.part.8+0x34/0x1c0 crypto/api.c:218
>  crypto_larval_lookup crypto/api.c:212 [inline]
>  crypto_alg_mod_lookup+0x77/0x120 crypto/api.c:271
>  crypto_find_alg crypto/api.c:501 [inline]
>  crypto_alloc_tfm+0x67/0x180 crypto/api.c:534
>  crypto_alloc_ahash+0x2c/0x40 crypto/ahash.c:540
>  hash_bind+0x51/0x90 crypto/algif_hash.c:422
>  alg_bind+0x94/0x180 crypto/af_alg.c:179
>  SYSC_bind+0xa8/0x130 net/socket.c:1454
>  SyS_bind+0x24/0x30 net/socket.c:1440
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a09
> RSP: 002b:7ff6c7ec4c58 EFLAGS: 0212 ORIG_RAX: 0031
> RAX: ffda RBX: 0071bea0 RCX: 00452a09
> RDX: 0058 RSI: 20f35000 RDI: 0013
> RBP: 0554 R08:  R09: 
> R10:  R11: 0212 R12: 006f5080
> R13:  R14: 7ff6c7ec56d4 R15: 
> Code: 89 7d d0 e8 70 61 c4 ff 48 8b 1d 89 df a6 01 48 81 fb 60 21 0e 83 0f
> 84 4c 01 00 00 c7 45 c4 fe ff ff ff 45 31 e4 e8 4d 61 c4 ff <44> 8b 6b 20 41
> f6 c5 60 0f 85 03 01 00 00 e8 3a 61 c4 ff 44 89
> RIP: __crypto_alg_lookup+0x43/0x190 crypto/api.c:63 RSP: c9d7fcb8
> ---[ end trace 17ac9655be6571e5 ]---
> Kernel panic - not syncing: Fatal exception
> netlink: 5 bytes leftover after parsing attributes in process
> `syz-executor6'.
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 

Invalidating this bug now that a similar one has been fixed; we'll see if it
happens again...

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in crypto_alg_tested

[Eric Biggers]

On Fri, Dec 22, 2017 at 11:33:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> encrypted_key: master key parameter '� 
> ���"j�f@��� 0UY@*��q� -� {�o�' is invalid
> could not allocate digest TFM handle cryptd(sha224)
> BUG: unable to handle kernel NULL pointer dereference at 0020
> binder: BINDER_SET_CONTEXT_MGR already set
> binder: 5108:5114 ioctl 40046207 0 returned -16
> encrypted_key: master key parameter '� 
> ���"j�f@��� 0UY@*��q� -� {�o�' is invalid
> IP: crypto_alg_tested+0xe9/0x260 crypto/algapi.c:275
> PGD 0 P4D 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 5153 Comm: cryptomgr_test Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:crypto_alg_tested+0xe9/0x260 crypto/algapi.c:275
> RSP: 0018:c9eafe98 EFLAGS: 00010293
> RAX: 8801fc9d66c0 RBX: 8801fcb35400 RCX: 81677729
> RDX:  RSI: 880215732481 RDI: 8801fd654081
> RBP: c9eafee8 R08: 0001 R09: 0004
> R10: c9eafe08 R11: 0004 R12: 
> R13: 8801fd654048 R14: 0c8f R15: c9eafeb0
> FS:  () GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0020 CR3: 0301e002 CR4: 001606f0
> DR0: 20001000 DR1: 20001008 DR2: 20001000
> DR3: 20001008 DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  cryptomgr_test+0x17/0x30 crypto/algboss.c:226
>  kthread+0x149/0x170 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> Code: c5 0f 84 a5 00 00 00 e8 36 2c c4 ff 41 81 4d 20 00 04 00 00 49 8d 45
> 38 48 89 45 c0 e8 21 2c c4 ff 4d 39 e5 74 70 e8 17 2c c4 ff <45> 8b 74 24 20
> 41 f6 c6 60 75 60 e8 07 2c c4 ff 49 8d 44 24 38
> RIP: crypto_alg_tested+0xe9/0x260 crypto/algapi.c:275 RSP: c9eafe98
> CR2: 0020
> ---[ end trace bf93c4f60f101736 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Invalidating this bug now that a similar one has been fixed; we'll see if it
happens again...

#syz invalid

Re: general protection fault in crypto_remove_spawns

[Eric Biggers]

On Mon, Nov 27, 2017 at 10:56:46AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 1ea8d039f9edcfefb20d8ddfe136930f6e551529
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 25985 Comm: cryptomgr_test Not tainted 4.14.0-mm1+ #25
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> task: 8801c4562180 task.stack: 8801d5b7
> RIP: 0010:crypto_remove_spawns+0x58c/0x1260 crypto/algapi.c:159
> RSP: 0018:8801d5b779e8 EFLAGS: 00010206
> RAX: 0003 RBX: dc00 RCX: 82258aab
> RDX:  RSI: 11003ab6efa6 RDI: 0018
> RBP: 8801d5b77dd8 R08: 8801d5b77d70 R09: 0004
> R10:  R11: 8747dda0 R12: 
> R13: 8801c505bb60 R14: ed003ab6ef4e R15: 8801d5b77db0
> FS:  () GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fff1d3ffcac CR3: 0001cf825000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  crypto_alg_tested+0x514/0x6f0 crypto/algapi.c:311
>  cryptomgr_test+0x17/0x30 crypto/algboss.c:226
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437
> Code: 84 e3 01 00 00 e8 35 94 4a ff 4c 89 e8 48 c1 e8 03 80 3c 18 00 0f 85
> d8 09 00 00 4d 8b 65 00 49 8d 7c 24 18 48 89 f8 48 c1 e8 03 <80> 3c 18 00 0f
> 85 b4 09 00 00 4d 8b 6c 24 18 4c 3b ad 50 fc ff
> RIP: crypto_remove_spawns+0x58c/0x1260 crypto/algapi.c:159 RSP:
> 8801d5b779e8
> ---[ end trace 14ce8f86fe2873b1 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Fix for the actual crash now is in Linus' tree:

#syz fix: crypto: algapi - fix NULL dereference in crypto_remove_spawns()

Re: KASAN: slab-out-of-bounds Write in sha3_update (2)

[Eric Biggers]

On Fri, Dec 22, 2017 at 11:22:38AM -0600, Eric Biggers wrote:
> [+Cc keyri...@vger.kernel.org]
> 
> On Fri, Dec 22, 2017 at 07:55:01AM -0800, syzbot wrote:
> > Hello,
> > 
> > syzkaller hit the following crash on
> > 9035a8961b504d0997369509ab8c6b1f0a4ee33d
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> > 
> > 
> > audit: type=1400 audit(1513919078.260:7): avc:  denied  { map } for
> > pid=3152 comm="syzkaller717822" path="/root/syzkaller717822551" dev="sda1"
> > ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> > ==
> > BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> > BUG: KASAN: slab-out-of-bounds in sha3_update+0xdf/0x2e0
> > crypto/sha3_generic.c:161
> > Write of size 192 at addr 8801cf0e3b3c by task syzkaller717822/3152
> > 
> > CPU: 0 PID: 3152 Comm: syzkaller717822 Not tainted 4.15.0-rc4+ #232
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:17 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >  kasan_report_error mm/kasan/report.c:351 [inline]
> >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> >  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> >  memcpy include/linux/string.h:344 [inline]
> >  sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
> >  crypto_shash_update+0xda/0x240 crypto/shash.c:110
> >  hmac_update+0x7e/0xa0 crypto/hmac.c:122
> >  crypto_shash_update+0xda/0x240 crypto/shash.c:110
> >  kdf_ctr security/keys/dh.c:181 [inline]
> >  keyctl_dh_compute_kdf security/keys/dh.c:226 [inline]
> >  __keyctl_dh_compute+0x160f/0x1990 security/keys/dh.c:398
> >  keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
> >  SYSC_keyctl security/keys/keyctl.c:1741 [inline]
> >  SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
> >  entry_SYSCALL_64_fastpath+0x1f/0x96
> > RIP: 0033:0x43feb9
> > RSP: 002b:7ffd3aef51a8 EFLAGS: 0217 ORIG_RAX: 00fa
> > RAX: ffda RBX: 004002c8 RCX: 0043feb9
> > RDX: 20c2cfff RSI: 204c8ff4 RDI: 0017
> > RBP: 006ca018 R08: 208e6fd4 R09: 
> > R10: 0001 R11: 0217 R12: 00401820
> > R13: 004018b0 R14:  R15: 
> > 
> > Allocated by task 3152:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >  set_track mm/kasan/kasan.c:459 [inline]
> >  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> >  __do_kmalloc mm/slab.c:3708 [inline]
> >  __kmalloc+0x162/0x760 mm/slab.c:3717
> >  kmalloc include/linux/slab.h:504 [inline]
> >  kdf_alloc security/keys/dh.c:111 [inline]
> >  __keyctl_dh_compute+0x2b0/0x1990 security/keys/dh.c:288
> >  keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
> >  SYSC_keyctl security/keys/keyctl.c:1741 [inline]
> >  SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
> >  entry_SYSCALL_64_fastpath+0x1f/0x96
> > 
> > Freed by task 1637:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >  set_track mm/kasan/kasan.c:459 [inline]
> >  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> >  __cache_free mm/slab.c:3488 [inline]
> >  kfree+0xd6/0x260 mm/slab.c:3803
> >  kernfs_fop_release+0x13f/0x180 fs/kernfs/file.c:783
> >  __fput+0x327/0x7e0 fs/file_table.c:210
> >  fput+0x15/0x20 fs/file_table.c:244
> >  task_work_run+0x199/0x270 kernel/task_work.c:113
> >  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
> >  exit_to_usermode_loop+0x296/0x310 arch/x86/entry/common.c:162
> >  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
> >  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
> >  entry_SYSCALL_64_fastpath+0x94/0x96
> > 
> 
> The problem is that KEYCTL_DH_COMPUTE allows the user to request and use any
> hash algorithm as an unkeyed hash without checking whether it is in fact
> unkeyed.
> 
> We could fix this by checking for !crypto_shash_alg_has_setkey() after
> allocating the hash, but now I'd really like to solve this for all users by
> having crypto_[as]hash_init() and crypto_[as]hash_digest() automatically 
> return
> -ENOKEY if a key is needed and one hasn't been set.  That would also have 
> solved
> the bug I fixed specifically for HMAC by "crypto: hmac - require that the
> underlying hash algorithm is unkeyed".
> 
> Eric

Fixed in cryptodev/master by:

#syz fix: crypto: hash - prevent using keyed hashes without 

Re: kernel failure while loading X.509 certificate

[Paolo Valente]

> Il giorno 17 gen 2018, alle ore 06:44, Eric Biggers  ha 
> scritto:
> 
> On Wed, Jan 17, 2018 at 06:36:16AM +0100, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers  
>>> ha scritto:
>>> 
>>> Hi Paolo,
>>> 
>>> On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
 
 
> Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann  ha 
> scritto:
> 
> On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente  
> wrote:
>> Hi guys,
>> this is a help request, for a problem that has been driving me crazy
>> all day long, without any success :(
>> 
>> I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
>> 27, using the usual "make ; make modules_install ; make install"
>> procedure. No error reported while building.  But at boot the
>> kernel immediately fails as follows, apparently while loading/parsing
>> an X.509 certificate:
> 
> The BUG_ON() you hit is this one in public_key_verify_signature():
> 
>  BUG_ON(!sig->digest);
> 
> There was a patch series by Eric Biggers that touched these files to
> add some fixes
> after v4.15-rc1.  I'm not runnig that code myself, but it sounds like
> a real regression,
> so I'm adding Eric (to look at the code), the corresponding mailing
> list and Thorsten
> (for regression tracking) to Cc.
> 
> x509_cert_parse() allocates the 'cert->sig' structure, and calls
> x509_get_sig_params(),
> which may or may not allocate a digest. It returns with
> cert->unsupported_sig=true
> in case it fails to allocate a digest for some reason (crypto_alloc_shash 
> failed
> or no sig->hash_algo).
> 
> The full set of Eric's patches is
> 
> 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
> 18026d866801 KEYS: reject NULL restriction string when type is specified
> 3d1f0255426a security: keys: remove redundant assignment to key_ref
> aa3300362060 X.509: use crypto_shash_digest()
> 72f9a07b6bfa KEYS: be careful with error codes in 
> public_key_verify_signature()
> a80745a6de51 pkcs7: use crypto_shash_digest()
> 7204eb8590c7 pkcs7: fix check for self-signed certificate
> 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs() 
> fails
> 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is 
> empty
> 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
> 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
> 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
> e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length 
> item
> 4dca6ea1d943 KEYS: add missing permission check for request_key() 
> destination
> a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
> 
> and it's based on -rc2. If you want to do a quicker bisection, I'd
> suggest you try
> 4.15-rc2 and 54c1fb39fe04 to start with.
> 
 
 Thank you very much Arnd.  Fortunately, for the task I'm performing, a
 4.14 will do too.  And I'm under pressure to finally finish this task.
 Yet, even before I finish with this task, I'm willing to do any test
 that the guys you added may want me to do.  And, if more useful for
 the community, ok for me to switch to the most appropriate public
 mailing lists.
 
>>> 
>>> Have you managed to bisect this yet?  I'm not seeing how my changes could 
>>> have
>>> caused this, but it does seem there may be an existing bug where this BUG() 
>>> can
>>> be hit if a certificate's signature uses a hash algorithm that is not built 
>>> into
>>> the kernel.  To verify whether that is happening can you try adding:
>>> 
>>> diff --git a/crypto/asymmetric_keys/x509_public_key.c 
>>> b/crypto/asymmetric_keys/x509_public_key.c
>>> index 9338b4558cdc..f1804640445a 100644
>>> --- a/crypto/asymmetric_keys/x509_public_key.c
>>> +++ b/crypto/asymmetric_keys/x509_public_key.c
>>> @@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
>>> tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
>>> if (IS_ERR(tfm)) {
>>> if (PTR_ERR(tfm) == -ENOENT) {
>>> +   pr_err("Hash algorithm %s not supported by crypto 
>>> API\n",
>>> +  sig->hash_algo);
>>> cert->unsupported_sig = true;
>>> return 0;
>>> }
>>> 
>>> If the pr_err() is hit then check the status of the corresponding 
>>> CONFIG_CRYPTO_
>>> option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
>>> "sha256".
>>> 
>> 
>> Hi Eric,
>> in the meantime I have moved to rc8, and the problem has disappeared.
>> Does this ring any bell?  Otherwise, I'll retry with rc7 after adding
>> your error message.
>> 
>> 

Re: kernel failure while loading X.509 certificate

[Eric Biggers]

On Wed, Jan 17, 2018 at 06:36:16AM +0100, Paolo Valente wrote:
> 
> 
> > Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers  
> > ha scritto:
> > 
> > Hi Paolo,
> > 
> > On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
> >> 
> >> 
> >>> Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann  ha 
> >>> scritto:
> >>> 
> >>> On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente  
> >>> wrote:
>  Hi guys,
>  this is a help request, for a problem that has been driving me crazy
>  all day long, without any success :(
>  
>  I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
>  27, using the usual "make ; make modules_install ; make install"
>  procedure. No error reported while building.  But at boot the
>  kernel immediately fails as follows, apparently while loading/parsing
>  an X.509 certificate:
> >>> 
> >>> The BUG_ON() you hit is this one in public_key_verify_signature():
> >>> 
> >>>   BUG_ON(!sig->digest);
> >>> 
> >>> There was a patch series by Eric Biggers that touched these files to
> >>> add some fixes
> >>> after v4.15-rc1.  I'm not runnig that code myself, but it sounds like
> >>> a real regression,
> >>> so I'm adding Eric (to look at the code), the corresponding mailing
> >>> list and Thorsten
> >>> (for regression tracking) to Cc.
> >>> 
> >>> x509_cert_parse() allocates the 'cert->sig' structure, and calls
> >>> x509_get_sig_params(),
> >>> which may or may not allocate a digest. It returns with
> >>> cert->unsupported_sig=true
> >>> in case it fails to allocate a digest for some reason (crypto_alloc_shash 
> >>> failed
> >>> or no sig->hash_algo).
> >>> 
> >>> The full set of Eric's patches is
> >>> 
> >>> 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
> >>> 18026d866801 KEYS: reject NULL restriction string when type is specified
> >>> 3d1f0255426a security: keys: remove redundant assignment to key_ref
> >>> aa3300362060 X.509: use crypto_shash_digest()
> >>> 72f9a07b6bfa KEYS: be careful with error codes in 
> >>> public_key_verify_signature()
> >>> a80745a6de51 pkcs7: use crypto_shash_digest()
> >>> 7204eb8590c7 pkcs7: fix check for self-signed certificate
> >>> 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs() 
> >>> fails
> >>> 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is 
> >>> empty
> >>> 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
> >>> 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
> >>> 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
> >>> e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length 
> >>> item
> >>> 4dca6ea1d943 KEYS: add missing permission check for request_key() 
> >>> destination
> >>> a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
> >>> 
> >>> and it's based on -rc2. If you want to do a quicker bisection, I'd
> >>> suggest you try
> >>> 4.15-rc2 and 54c1fb39fe04 to start with.
> >>> 
> >> 
> >> Thank you very much Arnd.  Fortunately, for the task I'm performing, a
> >> 4.14 will do too.  And I'm under pressure to finally finish this task.
> >> Yet, even before I finish with this task, I'm willing to do any test
> >> that the guys you added may want me to do.  And, if more useful for
> >> the community, ok for me to switch to the most appropriate public
> >> mailing lists.
> >> 
> > 
> > Have you managed to bisect this yet?  I'm not seeing how my changes could 
> > have
> > caused this, but it does seem there may be an existing bug where this BUG() 
> > can
> > be hit if a certificate's signature uses a hash algorithm that is not built 
> > into
> > the kernel.  To verify whether that is happening can you try adding:
> > 
> > diff --git a/crypto/asymmetric_keys/x509_public_key.c 
> > b/crypto/asymmetric_keys/x509_public_key.c
> > index 9338b4558cdc..f1804640445a 100644
> > --- a/crypto/asymmetric_keys/x509_public_key.c
> > +++ b/crypto/asymmetric_keys/x509_public_key.c
> > @@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
> > tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
> > if (IS_ERR(tfm)) {
> > if (PTR_ERR(tfm) == -ENOENT) {
> > +   pr_err("Hash algorithm %s not supported by crypto 
> > API\n",
> > +  sig->hash_algo);
> > cert->unsupported_sig = true;
> > return 0;
> > }
> > 
> > If the pr_err() is hit then check the status of the corresponding 
> > CONFIG_CRYPTO_
> > option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
> > "sha256".
> > 
> 
> Hi Eric,
> in the meantime I have moved to rc8, and the problem has disappeared.
> Does this ring any bell?  Otherwise, I'll retry with rc7 after adding
> your error message.
> 
> Thanks,
> Paolo
> 

No, it doesn't ring a bell.  Is it possible you changed your kernel config
between rc7 and 

Re: kernel failure while loading X.509 certificate

[Paolo Valente]

> Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers  ha 
> scritto:
> 
> Hi Paolo,
> 
> On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann  ha 
>>> scritto:
>>> 
>>> On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente  
>>> wrote:
 Hi guys,
 this is a help request, for a problem that has been driving me crazy
 all day long, without any success :(
 
 I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
 27, using the usual "make ; make modules_install ; make install"
 procedure. No error reported while building.  But at boot the
 kernel immediately fails as follows, apparently while loading/parsing
 an X.509 certificate:
>>> 
>>> The BUG_ON() you hit is this one in public_key_verify_signature():
>>> 
>>>   BUG_ON(!sig->digest);
>>> 
>>> There was a patch series by Eric Biggers that touched these files to
>>> add some fixes
>>> after v4.15-rc1.  I'm not runnig that code myself, but it sounds like
>>> a real regression,
>>> so I'm adding Eric (to look at the code), the corresponding mailing
>>> list and Thorsten
>>> (for regression tracking) to Cc.
>>> 
>>> x509_cert_parse() allocates the 'cert->sig' structure, and calls
>>> x509_get_sig_params(),
>>> which may or may not allocate a digest. It returns with
>>> cert->unsupported_sig=true
>>> in case it fails to allocate a digest for some reason (crypto_alloc_shash 
>>> failed
>>> or no sig->hash_algo).
>>> 
>>> The full set of Eric's patches is
>>> 
>>> 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
>>> 18026d866801 KEYS: reject NULL restriction string when type is specified
>>> 3d1f0255426a security: keys: remove redundant assignment to key_ref
>>> aa3300362060 X.509: use crypto_shash_digest()
>>> 72f9a07b6bfa KEYS: be careful with error codes in 
>>> public_key_verify_signature()
>>> a80745a6de51 pkcs7: use crypto_shash_digest()
>>> 7204eb8590c7 pkcs7: fix check for self-signed certificate
>>> 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs() 
>>> fails
>>> 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is empty
>>> 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
>>> 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
>>> 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
>>> e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length 
>>> item
>>> 4dca6ea1d943 KEYS: add missing permission check for request_key() 
>>> destination
>>> a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
>>> 
>>> and it's based on -rc2. If you want to do a quicker bisection, I'd
>>> suggest you try
>>> 4.15-rc2 and 54c1fb39fe04 to start with.
>>> 
>> 
>> Thank you very much Arnd.  Fortunately, for the task I'm performing, a
>> 4.14 will do too.  And I'm under pressure to finally finish this task.
>> Yet, even before I finish with this task, I'm willing to do any test
>> that the guys you added may want me to do.  And, if more useful for
>> the community, ok for me to switch to the most appropriate public
>> mailing lists.
>> 
> 
> Have you managed to bisect this yet?  I'm not seeing how my changes could have
> caused this, but it does seem there may be an existing bug where this BUG() 
> can
> be hit if a certificate's signature uses a hash algorithm that is not built 
> into
> the kernel.  To verify whether that is happening can you try adding:
> 
> diff --git a/crypto/asymmetric_keys/x509_public_key.c 
> b/crypto/asymmetric_keys/x509_public_key.c
> index 9338b4558cdc..f1804640445a 100644
> --- a/crypto/asymmetric_keys/x509_public_key.c
> +++ b/crypto/asymmetric_keys/x509_public_key.c
> @@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
>   tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
>   if (IS_ERR(tfm)) {
>   if (PTR_ERR(tfm) == -ENOENT) {
> + pr_err("Hash algorithm %s not supported by crypto 
> API\n",
> +sig->hash_algo);
>   cert->unsupported_sig = true;
>   return 0;
>   }
> 
> If the pr_err() is hit then check the status of the corresponding 
> CONFIG_CRYPTO_
> option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
> "sha256".
> 

Hi Eric,
in the meantime I have moved to rc8, and the problem has disappeared.
Does this ring any bell?  Otherwise, I'll retry with rc7 after adding
your error message.

Thanks,
Paolo

> Eric

Re: kernel failure while loading X.509 certificate

[Eric Biggers]

Hi Paolo,

On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
> 
> 
> > Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann  ha 
> > scritto:
> > 
> > On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente  
> > wrote:
> >> Hi guys,
> >> this is a help request, for a problem that has been driving me crazy
> >> all day long, without any success :(
> >> 
> >> I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
> >> 27, using the usual "make ; make modules_install ; make install"
> >> procedure. No error reported while building.  But at boot the
> >> kernel immediately fails as follows, apparently while loading/parsing
> >> an X.509 certificate:
> > 
> > The BUG_ON() you hit is this one in public_key_verify_signature():
> > 
> >BUG_ON(!sig->digest);
> > 
> > There was a patch series by Eric Biggers that touched these files to
> > add some fixes
> > after v4.15-rc1.  I'm not runnig that code myself, but it sounds like
> > a real regression,
> > so I'm adding Eric (to look at the code), the corresponding mailing
> > list and Thorsten
> > (for regression tracking) to Cc.
> > 
> > x509_cert_parse() allocates the 'cert->sig' structure, and calls
> > x509_get_sig_params(),
> > which may or may not allocate a digest. It returns with
> > cert->unsupported_sig=true
> > in case it fails to allocate a digest for some reason (crypto_alloc_shash 
> > failed
> > or no sig->hash_algo).
> > 
> > The full set of Eric's patches is
> > 
> > 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
> > 18026d866801 KEYS: reject NULL restriction string when type is specified
> > 3d1f0255426a security: keys: remove redundant assignment to key_ref
> > aa3300362060 X.509: use crypto_shash_digest()
> > 72f9a07b6bfa KEYS: be careful with error codes in 
> > public_key_verify_signature()
> > a80745a6de51 pkcs7: use crypto_shash_digest()
> > 7204eb8590c7 pkcs7: fix check for self-signed certificate
> > 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs() 
> > fails
> > 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is empty
> > 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
> > 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
> > 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
> > e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length 
> > item
> > 4dca6ea1d943 KEYS: add missing permission check for request_key() 
> > destination
> > a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
> > 
> > and it's based on -rc2. If you want to do a quicker bisection, I'd
> > suggest you try
> > 4.15-rc2 and 54c1fb39fe04 to start with.
> > 
> 
> Thank you very much Arnd.  Fortunately, for the task I'm performing, a
> 4.14 will do too.  And I'm under pressure to finally finish this task.
> Yet, even before I finish with this task, I'm willing to do any test
> that the guys you added may want me to do.  And, if more useful for
> the community, ok for me to switch to the most appropriate public
> mailing lists.
> 

Have you managed to bisect this yet?  I'm not seeing how my changes could have
caused this, but it does seem there may be an existing bug where this BUG() can
be hit if a certificate's signature uses a hash algorithm that is not built into
the kernel.  To verify whether that is happening can you try adding:

diff --git a/crypto/asymmetric_keys/x509_public_key.c 
b/crypto/asymmetric_keys/x509_public_key.c
index 9338b4558cdc..f1804640445a 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
if (IS_ERR(tfm)) {
if (PTR_ERR(tfm) == -ENOENT) {
+   pr_err("Hash algorithm %s not supported by crypto 
API\n",
+  sig->hash_algo);
cert->unsupported_sig = true;
return 0;
}

If the pr_err() is hit then check the status of the corresponding CONFIG_CRYPTO_
option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
"sha256".

Eric

Re: [RFT PATCH] crypto: arm64 - implement SM3 secure hash using special instructions

[Steve Capper]

On Tue, Jan 16, 2018 at 08:29:22AM +, Ard Biesheuvel wrote:
> Implement the Chinese SM3 secure hash algorithm using the new
> special instructions that have been introduced as an optional
> extension in ARMv8.2.
> 

Hi Ard,
I've tested this in a model against 4.15-rc8.

The following tcrypt modes were tested for sm3-ce:
52, 326 and 425.

So feel free to add:
Tested-by: Steve Capper 

Cheers,
-- 
Steve

AES-NI: BUG in gcmaes_decrypt

[Stephan Müller]

Hi,

When compiling the current cryptodev-2.6 tree with CONFIG_DEBUG_SG and 
invoking a gcm(aes) decrypt operation with an empty ciphertext and an empty 
AAD, I get the following BUG:

[   79.294243] [ cut here ]
[   79.294903] kernel BUG at ./include/linux/scatterlist.h:130!
[   79.295808] invalid opcode:  [#1] SMP
[   79.296689] Modules linked in: ansi_cprng algif_rng ccm algif_aead 
algif_skcipher crypto_user des3_ede_x86_64 des_generic algif_hash af_alg 
ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ip_set nfnetlink 
ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_raw 
ip6table_security iptable_mangle iptable_raw iptable_security ebtable_filter 
ebtables ip6table_filter ip6_tables crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel pcspkr virtio_net virtio_balloon i2c_piix4 sch_fq_codel 
virtio_blk virtio_console crc32c_intel serio_raw virtio_pci virtio_ring virtio
[   79.304600] CPU: 3 PID: 13182 Comm: lt-kcapi Not tainted 4.15.0-rc3+ #584
[   79.305395] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   79.306514] RIP: 0010:gcmaes_decrypt.constprop.11+0x29f/0x310
[   79.307259] RSP: 0018:a9ae026c3ca8 EFLAGS: 00010212
[   79.307948] RAX: cc2a41ee1242 RBX: a192b8cbfa00 RCX: 
87654321
[   79.308853] RDX: a192b8c91410 RSI: 5a5e678f RDI: 

[   79.309749] RBP: 0010 R08: a192b8c91c60 R09: 
a192b8cbfa00
[   79.310652] R10: a9ae026c3d70 R11:  R12: 
a192b89a7060
[   79.311552] R13: 0010 R14: a192b8c91798 R15: 
0010
[   79.312446] FS:  7fe6275f8700() GS:a192bfd8() knlGS:

[   79.313643] CS:  0010 DS:  ES:  CR0: 80050033
[   79.314120] CR2: 7ffeb41ee000 CR3: 78244006 CR4: 
003606e0
[   79.315251] Call Trace:
[   79.315515]  ? sock_kfree_s+0x19/0x30
[   79.315845]  ? generic_gcmaes_decrypt+0x50/0x60
[   79.316251]  ? aead_recvmsg+0x5e1/0x670 [algif_aead]
[   79.316704]  ? aead_recvmsg+0x5e1/0x670 [algif_aead]
[   79.317144]  ? sock_read_iter+0x89/0xd0
[   79.317499]  ? __vfs_read+0xd1/0x120
[   79.317834]  ? vfs_read+0x89/0x130
[   79.318149]  ? SyS_read+0x42/0x90
[   79.318619]  ? do_syscall_64+0x5c/0x120
[   79.319501]  ? entry_SYSCALL64_slow_path+0x25/0x25


The BUG is triggered by the sg_page() invocation in gcmaes_decrypt which 
checks:

BUG_ON(sg->sg_magic != SG_MAGIC);


The issue can be triggered with libkcapi using the following test:

kcapi   -x 2   -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k 
f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t 
"5f24c68cbe6f32c29652442bf5d483ad" -q ""

Ciao
Stephan

[PATCH v2] crypto/ahash: Require export/import in ahash

[Kamil Konieczny]

Export and import were optional in async hash. As most drivers were
rewritten, they become mandatory now, so correct init of ahash
transformation.

Signed-off-by: Kamil Konieczny 
---
This is resend of previous patch. As Bartlomiej Zolnierkiewicz pointed out,
there are still three crypto drivers that didn't have export/import implemented:

drivers/crypto/mxs-dcp.c
drivers/crypto/n2_core.c
drivers/crypto/ux500/hash/hash_core.c

I have no documentation for them, so I sended patches with the behaviour taken
from crypto framework, but maybe that hardware is capable of import/export,
so proper implementation is possible. Unfortunatly, there is no maintainer
for any of these files.

Please take this patch after these remainig drivers will be patched.

 crypto/ahash.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index 3a35d67de7d9..7a8906d5af53 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -434,16 +434,6 @@ static int ahash_def_finup(struct ahash_request *req)
return ahash_def_finup_finish1(req, err);
 }
 
-static int ahash_no_export(struct ahash_request *req, void *out)
-{
-   return -ENOSYS;
-}
-
-static int ahash_no_import(struct ahash_request *req, const void *in)
-{
-   return -ENOSYS;
-}
-
 static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
 {
struct crypto_ahash *hash = __crypto_ahash_cast(tfm);
@@ -451,8 +441,8 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
 
hash->setkey = ahash_nosetkey;
hash->has_setkey = false;
-   hash->export = ahash_no_export;
-   hash->import = ahash_no_import;
+   hash->export = alg->export;
+   hash->import = alg->import;
 
if (tfm->__crt_alg->cra_type != _ahash_type)
return crypto_init_shash_ops_async(tfm);
@@ -467,10 +457,6 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
hash->setkey = alg->setkey;
hash->has_setkey = true;
}
-   if (alg->export)
-   hash->export = alg->export;
-   if (alg->import)
-   hash->import = alg->import;
 
return 0;
 }
-- 
2.15.0

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

[Kamil Konieczny]

On 16.01.2018 18:28, Fabio Estevam wrote:
> Hi Kamil,
> 
> On Tue, Jan 16, 2018 at 2:16 PM, Kamil Konieczny
>  wrote:
>> Crypto framework will require async hash export/import, so add empty
>> functions to prevent OOPS.
> 
> Which Oops exactly are you getting?

None now, it is for preparation for patch removing export/import wrappers.

> 
> Just booted 4.14.13 and the mxs-dcp driver does not even probe successfully:
> 
> [2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
> [2.464042] mxs-dcp: probe of 80028000.dcp failed with error -22
> 

With this option turned on in config:

crypto: Disable run-time self tests 

driver should load. Can you verify ?

Btw, there is no maintainer for this file.

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

Re: [PATCH v2] net/core: Increase default optmem_max limit

[Stephan Mueller]

Am Dienstag, 16. Januar 2018, 18:16:43 CET schrieb Björn 'besser82' Esser:

Hi Björn,

> With the new Linux Kernel Crypto API User Space Interface
> and its underlying AF_ALG socket, the current default value
> for `net.core.optmem_max` can be exhausted pretty quick when
> using asynchronous IO; on 32 bit systems it is not even enough
> for sending about 10 IOVECs at once to the socket interface.
> 
> To provide consumers of this new user space interface a well
> sufficient and reasonable maximum ancillary buffer size per
> socket by default, the limit is increased to four times of
> the previous setting:
> 
>   * 32 bit systems:  from 10240 bytes to 40960 bytes
>   * 64 bit systems:  from 20480 bytes to 81920 bytes
> 
> This allows for sending 32/64 (32/64 bit) parallel IOVECs at
> once to the socket interface, which should be enough for use
> in real world applications.
> 
> Signed-off-by: Björn Esser 

Considering NR_FILE defining the default maximum number of file descriptors, 
at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I 
would assume to be ok in current systems.

Reviewed-by: Stephan Mueller 

Ciao
Stephan

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

[Kamil Konieczny]

On 16.01.2018 17:56, Marek Vasut wrote:
> On 01/16/2018 05:16 PM, Kamil Konieczny wrote:
>> Crypto framework will require async hash export/import, so add empty
>> functions to prevent OOPS.
> 
> Shouldn't this be handled on the subsystem level with some
> 
> if (foo->bar)
>  foo->bar();
> 
> instead?

I am sorry, I should write more elaborate description for patch.

It is handled by subsystem. Most drivers have them, and testmgr is testing for 
export/import and drivers without them fail internal crypto tests,
so I prepared patch which removed these two wrappers from crypto framework.

In summary: export/import are now required, so crypto framework can work 
properly.

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

[Fabio Estevam]

Hi Kamil,

On Tue, Jan 16, 2018 at 2:16 PM, Kamil Konieczny
 wrote:
> Crypto framework will require async hash export/import, so add empty
> functions to prevent OOPS.

Which Oops exactly are you getting?

Just booted 4.14.13 and the mxs-dcp driver does not even probe successfully:

[2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[2.464042] mxs-dcp: probe of 80028000.dcp failed with error -22

Re: [PATCH v2] net/core: Increase default optmem_max limit

[Björn 'besser82' Esser]

With the new Linux Kernel Crypto API User Space Interface
and its underlying AF_ALG socket, the current default value
for `net.core.optmem_max` can be exhausted pretty quick when
using asynchronous IO; on 32 bit systems it is not even enough
for sending about 10 IOVECs at once to the socket interface.

To provide consumers of this new user space interface a well
sufficient and reasonable maximum ancillary buffer size per
socket by default, the limit is increased to four times of
the previous setting:

  * 32 bit systems:  from 10240 bytes to 40960 bytes
  * 64 bit systems:  from 20480 bytes to 81920 bytes

This allows for sending 32/64 (32/64 bit) parallel IOVECs at
once to the socket interface, which should be enough for use
in real world applications.

Signed-off-by: Björn Esser 
---
 net/core/sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index c0b5b2f17412..de00c571c933 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -316,7 +316,7 @@ __u32 sysctl_wmem_default __read_mostly = SK_WMEM_MAX;
 __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
 
 /* Maximal space eaten by iovec or ancillary data plus some space */
-int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
+int sysctl_optmem_max __read_mostly = sizeof(unsigned 
long)*4*(2*UIO_MAXIOV+512);
 EXPORT_SYMBOL(sysctl_optmem_max);
 
 int sysctl_tstamp_allow_data __read_mostly = 1;

[PATCH v2] net/core: Increase default optmem_max limit

[Björn 'besser82' Esser]

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

[Marek Vasut]

On 01/16/2018 05:16 PM, Kamil Konieczny wrote:
> Crypto framework will require async hash export/import, so add empty
> functions to prevent OOPS.

Shouldn't this be handled on the subsystem level with some

if (foo->bar)
 foo->bar();

instead?

> Signed-off-by: Kamil Konieczny 
> ---
>  drivers/crypto/mxs-dcp.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> index 764be3e6933c..a10c418d4e5c 100644
> --- a/drivers/crypto/mxs-dcp.c
> +++ b/drivers/crypto/mxs-dcp.c
> @@ -759,6 +759,16 @@ static int dcp_sha_digest(struct ahash_request *req)
>   return dcp_sha_finup(req);
>  }
>  
> +static int dcp_sha_noimport(struct ahash_request *req, const void *in)
> +{
> + return -ENOSYS;
> +}
> +
> +static int dcp_sha_noexport(struct ahash_request *req, void *out)
> +{
> + return -ENOSYS;
> +}
> +
>  static int dcp_sha_cra_init(struct crypto_tfm *tfm)
>  {
>   crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
> @@ -829,6 +839,8 @@ static struct ahash_alg dcp_sha1_alg = {
>   .final  = dcp_sha_final,
>   .finup  = dcp_sha_finup,
>   .digest = dcp_sha_digest,
> + .import = dcp_sha_noimport,
> + .export = dcp_sha_noexport,
>   .halg   = {
>   .digestsize = SHA1_DIGEST_SIZE,
>   .base   = {
> @@ -853,6 +865,8 @@ static struct ahash_alg dcp_sha256_alg = {
>   .final  = dcp_sha_final,
>   .finup  = dcp_sha_finup,
>   .digest = dcp_sha_digest,
> + .import = dcp_sha_noimport,
> + .export = dcp_sha_noexport,
>   .halg   = {
>   .digestsize = SHA256_DIGEST_SIZE,
>   .base   = {
> 


-- 
Best regards,
Marek Vasut

[PATCH] crypto: ux500/hash: Add empty export and import

[Kamil Konieczny]

Crypto framework will require async hash export/import, so add empty
functions to prevent OOPS.

Signed-off-by: Kamil Konieczny 
---
 drivers/crypto/ux500/hash/hash_core.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/crypto/ux500/hash/hash_core.c 
b/drivers/crypto/ux500/hash/hash_core.c
index 9acccad26928..2d0a677bcc76 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1403,6 +1403,16 @@ static int ahash_sha256_digest(struct ahash_request *req)
return ret1 ? ret1 : ret2;
 }
 
+static int ahash_noimport(struct ahash_request *req, const void *in)
+{
+   return -ENOSYS;
+}
+
+static int ahash_noexport(struct ahash_request *req, void *out)
+{
+   return -ENOSYS;
+}
+
 static int hmac_sha1_init(struct ahash_request *req)
 {
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
@@ -1507,6 +1517,8 @@ static struct hash_algo_template hash_algs[] = {
.update = ahash_update,
.final = ahash_final,
.digest = ahash_sha1_digest,
+   .export = ahash_noexport,
+   .import = ahash_noimport,
.halg.digestsize = SHA1_DIGEST_SIZE,
.halg.statesize = sizeof(struct hash_ctx),
.halg.base = {
@@ -1529,6 +1541,8 @@ static struct hash_algo_template hash_algs[] = {
.update = ahash_update,
.final = ahash_final,
.digest = ahash_sha256_digest,
+   .export = ahash_noexport,
+   .import = ahash_noimport,
.halg.digestsize = SHA256_DIGEST_SIZE,
.halg.statesize = sizeof(struct hash_ctx),
.halg.base = {
@@ -1553,6 +1567,8 @@ static struct hash_algo_template hash_algs[] = {
.final = ahash_final,
.digest = hmac_sha1_digest,
.setkey = hmac_sha1_setkey,
+   .export = ahash_noexport,
+   .import = ahash_noimport,
.halg.digestsize = SHA1_DIGEST_SIZE,
.halg.statesize = sizeof(struct hash_ctx),
.halg.base = {
@@ -1577,6 +1593,8 @@ static struct hash_algo_template hash_algs[] = {
.final = ahash_final,
.digest = hmac_sha256_digest,
.setkey = hmac_sha256_setkey,
+   .export = ahash_noexport,
+   .import = ahash_noimport,
.halg.digestsize = SHA256_DIGEST_SIZE,
.halg.statesize = sizeof(struct hash_ctx),
.halg.base = {
-- 
2.15.0

[PATCH] crypto: n2_core: Add empty hash export and import

[Kamil Konieczny]

Crypto framework will require async hash export/import, so add empty
functions to prevent OOPS.

Signed-off-by: Kamil Konieczny 
---
 drivers/crypto/n2_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 662e709812cc..80e9c842aad4 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -359,6 +359,16 @@ static int n2_hash_async_finup(struct ahash_request *req)
return crypto_ahash_finup(>fallback_req);
 }
 
+static int n2_hash_async_noimport(struct ahash_request *req, const void *in)
+{
+   return -ENOSYS;
+}
+
+static int n2_hash_async_noexport(struct ahash_request *req, void *out)
+{
+   return -ENOSYS;
+}
+
 static int n2_hash_cra_init(struct crypto_tfm *tfm)
 {
const char *fallback_driver_name = crypto_tfm_alg_name(tfm);
@@ -1467,6 +1477,8 @@ static int __n2_register_one_ahash(const struct 
n2_hash_tmpl *tmpl)
ahash->final = n2_hash_async_final;
ahash->finup = n2_hash_async_finup;
ahash->digest = n2_hash_async_digest;
+   ahash->export = n2_hash_async_noexport;
+   ahash->import = n2_hash_async_noimport;
 
halg = >halg;
halg->digestsize = tmpl->digest_size;
-- 
2.15.0

[PATCH] crypto: mxs-dcp: Add empty hash export and import

[Kamil Konieczny]

Crypto framework will require async hash export/import, so add empty
functions to prevent OOPS.

Signed-off-by: Kamil Konieczny 
---
 drivers/crypto/mxs-dcp.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index 764be3e6933c..a10c418d4e5c 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -759,6 +759,16 @@ static int dcp_sha_digest(struct ahash_request *req)
return dcp_sha_finup(req);
 }
 
+static int dcp_sha_noimport(struct ahash_request *req, const void *in)
+{
+   return -ENOSYS;
+}
+
+static int dcp_sha_noexport(struct ahash_request *req, void *out)
+{
+   return -ENOSYS;
+}
+
 static int dcp_sha_cra_init(struct crypto_tfm *tfm)
 {
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
@@ -829,6 +839,8 @@ static struct ahash_alg dcp_sha1_alg = {
.final  = dcp_sha_final,
.finup  = dcp_sha_finup,
.digest = dcp_sha_digest,
+   .import = dcp_sha_noimport,
+   .export = dcp_sha_noexport,
.halg   = {
.digestsize = SHA1_DIGEST_SIZE,
.base   = {
@@ -853,6 +865,8 @@ static struct ahash_alg dcp_sha256_alg = {
.final  = dcp_sha_final,
.finup  = dcp_sha_finup,
.digest = dcp_sha_digest,
+   .import = dcp_sha_noimport,
+   .export = dcp_sha_noexport,
.halg   = {
.digestsize = SHA256_DIGEST_SIZE,
.base   = {
-- 
2.15.0

[PATCH] crypto: testmgr.c: test misuse of result in ahash

[Kamil Konieczny]

Async hash operations can use result pointer in final/finup/digest,
but not in init/update/export/import, so test it for misuse.

Signed-off-by: Kamil Konieczny 
---
Tested with crypto run-time self test on Odroid-U3 with Exynos 4412 CPU
with insmod s5p-sss.ko

 crypto/testmgr.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 44a85d4b3561..d5e23a142a04 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -177,6 +177,18 @@ static void testmgr_free_buf(char *buf[XBUFSIZE])
free_page((unsigned long)buf[i]);
 }
 
+static int ahash_guard_result(char *result, char c, int size)
+{
+   int i;
+
+   for (i = 0; i < size; i++) {
+   if (result[i] != c)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int ahash_partial_update(struct ahash_request **preq,
struct crypto_ahash *tfm, const struct hash_testvec *template,
void *hash_buff, int k, int temp, struct scatterlist *sg,
@@ -186,6 +198,7 @@ static int ahash_partial_update(struct ahash_request **preq,
struct ahash_request *req;
int statesize, ret = -EINVAL;
static const unsigned char guard[] = { 0x00, 0xba, 0xad, 0x00 };
+   int digestsize = crypto_ahash_digestsize(tfm);
 
req = *preq;
statesize = crypto_ahash_statesize(
@@ -196,12 +209,19 @@ static int ahash_partial_update(struct ahash_request 
**preq,
goto out_nostate;
}
memcpy(state + statesize, guard, sizeof(guard));
+   memset(result, 1, digestsize);
ret = crypto_ahash_export(req, state);
WARN_ON(memcmp(state + statesize, guard, sizeof(guard)));
if (ret) {
pr_err("alg: hash: Failed to export() for %s\n", algo);
goto out;
}
+   ret = ahash_guard_result(result, 1, digestsize);
+   if (ret) {
+   pr_err("alg: hash: Failed, export used req->result for %s\n",
+  algo);
+   goto out;
+   }
ahash_request_free(req);
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req) {
@@ -221,6 +241,12 @@ static int ahash_partial_update(struct ahash_request 
**preq,
pr_err("alg: hash: Failed to import() for %s\n", algo);
goto out;
}
+   ret = ahash_guard_result(result, 1, digestsize);
+   if (ret) {
+   pr_err("alg: hash: Failed, import used req->result for %s\n",
+  algo);
+   goto out;
+   }
ret = crypto_wait_req(crypto_ahash_update(req), wait);
if (ret)
goto out;
@@ -316,18 +342,31 @@ static int __test_hash(struct crypto_ahash *tfm,
goto out;
}
} else {
+   memset(result, 1, digest_size);
ret = crypto_wait_req(crypto_ahash_init(req), );
if (ret) {
pr_err("alg: hash: init failed on test %d "
   "for %s: ret=%d\n", j, algo, -ret);
goto out;
}
+   ret = ahash_guard_result(result, 1, digest_size);
+   if (ret) {
+   pr_err("alg: hash: init failed on test %d "
+  "for %s: used req->result\n", j, algo);
+   goto out;
+   }
ret = crypto_wait_req(crypto_ahash_update(req), );
if (ret) {
pr_err("alg: hash: update failed on test %d "
   "for %s: ret=%d\n", j, algo, -ret);
goto out;
}
+   ret = ahash_guard_result(result, 1, digest_size);
+   if (ret) {
+   pr_err("alg: hash: update failed on test %d "
+  "for %s: used req->result\n", j, algo);
+   goto out;
+   }
ret = crypto_wait_req(crypto_ahash_final(req), );
if (ret) {
pr_err("alg: hash: final failed on test %d "
-- 
2.15.0

Re: [RFT PATCH] crypto: ahash.c: Require export/import in ahash

[Bartlomiej Zolnierkiewicz]

On Tuesday, January 16, 2018 11:35:44 AM Kamil Konieczny wrote:
> Export and import were optional in async hash. As drivers were rewritten,
> they become mandatory now, so correct init of ahash transformation.
> 
> Signed-off-by: Kamil Konieczny 
> ---
> Tested with crypto run-time self test on Odroid-U3 with Exynos 4412 CPU,
> with insmod s5p-sss.ko
> Please test with other crypto hash drivers.

Testing all existing ahash drivers is impossible so the code audit
should be done instead. From the quick look there are 3 hash drivers
left that still don't implement ->import/->export methods:

drivers/crypto/mxs-dcp.c
drivers/crypto/n2_core.c
drivers/crypto/ux500/hash/hash_core.c

It seems that after this patch they will OOPS, currently they now
return errors on ->import/->export attempts.

Please verify this and if necessary add dummy ->import/->export
implementations to affected drivers + contact their maintainers
(or authors if there is no maintainer assigned) to make them
aware of the problem (maybe some drivers should be removed now?).

>  crypto/ahash.c | 18 ++
>  1 file changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/crypto/ahash.c b/crypto/ahash.c
> index 3a35d67de7d9..7a8906d5af53 100644
> --- a/crypto/ahash.c
> +++ b/crypto/ahash.c
> @@ -434,16 +434,6 @@ static int ahash_def_finup(struct ahash_request *req)
>   return ahash_def_finup_finish1(req, err);
>  }
>  
> -static int ahash_no_export(struct ahash_request *req, void *out)
> -{
> - return -ENOSYS;
> -}
> -
> -static int ahash_no_import(struct ahash_request *req, const void *in)
> -{
> - return -ENOSYS;
> -}
> -
>  static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
>  {
>   struct crypto_ahash *hash = __crypto_ahash_cast(tfm);
> @@ -451,8 +441,8 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
>  
>   hash->setkey = ahash_nosetkey;
>   hash->has_setkey = false;
> - hash->export = ahash_no_export;
> - hash->import = ahash_no_import;
> + hash->export = alg->export;
> + hash->import = alg->import;
>  
>   if (tfm->__crt_alg->cra_type != _ahash_type)
>   return crypto_init_shash_ops_async(tfm);
> @@ -467,10 +457,6 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
>   hash->setkey = alg->setkey;
>   hash->has_setkey = true;
>   }
> - if (alg->export)
> - hash->export = alg->export;
> - if (alg->import)
> - hash->import = alg->import;
>  
>   return 0;
>  }

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[bug report] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

[Dan Carpenter]

Hello Brijesh Singh,

The patch 200664d5237f: "crypto: ccp: Add Secure Encrypted
Virtualization (SEV) command support" from Dec 4, 2017, leads to the
following static checker warning:

drivers/crypto/ccp/psp-dev.c:779 psp_pci_init()
error: uninitialized symbol 'error'.

drivers/crypto/ccp/psp-dev.c
   764  void psp_pci_init(void)
   765  {
   766  struct sev_user_data_status *status;
   767  struct sp_device *sp;
   768  int error, rc;
   769  
   770  sp = sp_get_psp_master_device();
   771  if (!sp)
   772  return;
   773  
   774  psp_master = sp->psp_data;
   775  
   776  /* Initialize the platform */
   777  rc = sev_platform_init();
   778  if (rc) {
   779  dev_err(sp->dev, "SEV: failed to INIT error %#x\n", 
error);

^
Generally not set on the error paths.

   780  goto err;
   781  }
   782  
   783  /* Display SEV firmware version */

regards,
dan carpenter

Re: [RFC] AF_ALG AIO and IV

[Jonathan Cameron]

On Tue, 16 Jan 2018 07:28:06 +0100
Stephan Mueller  wrote:

> Am Montag, 15. Januar 2018, 15:42:58 CET schrieb Jonathan Cameron:
> 
> Hi Jonathan,
> 
> > > What about:
> > > 
> > > sendmsg(IV, data)
> > > sendmsg(data)
> > > ..
> > > AIO recvmsg with multiple IOCBs
> > > AIO recvmsg with multiple IOCBs
> > > ..
> > > sendmsg(IV, data)
> > > ..
> > > 
> > > This implies, however, that before the sendmsg with the second IV is sent,
> > > all AIO operations from the first invocation would need to be finished.  
> > Yes that works fine, but rather restricts the flow - you would end up
> > waiting until you could concatenate a bunch of data in userspace so as to
> > trade off against the slow down whenever you need to synchronize back up to
> > userspace.  
> 
> I think the solution is already present and even libkcapi's architecture is 
> set up to handle this scenario:
> 
> We have 2 types of FDs: one obtained from socket() and one from accept(). The 
> socket-FD is akin to the TFM. The accept FD is exactly what you want:
> 
> tfmfd = socket()
> setkey(tfmfd)
> opfd = accept()
> opfd2 = accept()
> sendmsg(opfd, IV, data)
> recvmsg(opfd, data)
> 
> sendmsg(opfd2, IV, data)
> recvmsg(opfd2, data)
> 
> sendmsg(opfd, data)
> ..
> 
> There can be multipe FDs from accept and these are the "identifiers" for your 
> cipher operation stream that belongs together.
> 
> libkcapi has already the architecture for this type of work, but it is not 
> exposed to the API yet. The internal calls for sendmsg/recvmsg all take an 
> (op)FD parameter. E.g. _kcapi_common_send_meta_fd has the fdptr variable. 
> internal.h currently wraps this call into _kcapi_common_send_meta where the 
> handle->opfd variable is used.
> 
> The idea why I implemented that is because the caller could maintain an array 
> of opfds. If we would expose these internal calls with the FD argument, you 
> can maintain multiple opfds implementing your use case.
> 
> The only change would be to expose the internal libkcapi calls.
> 
> Ciao
> Stephan

Thanks, I'll take a look at this soonish. Having a busy week.

Jonathan
> 
> 

[RFT PATCH] crypto: ahash.c: Require export/import in ahash

[Kamil Konieczny]

Export and import were optional in async hash. As drivers were rewritten,
they become mandatory now, so correct init of ahash transformation.

Signed-off-by: Kamil Konieczny 
---
Tested with crypto run-time self test on Odroid-U3 with Exynos 4412 CPU,
with insmod s5p-sss.ko
Please test with other crypto hash drivers.

 crypto/ahash.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index 3a35d67de7d9..7a8906d5af53 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -434,16 +434,6 @@ static int ahash_def_finup(struct ahash_request *req)
return ahash_def_finup_finish1(req, err);
 }
 
-static int ahash_no_export(struct ahash_request *req, void *out)
-{
-   return -ENOSYS;
-}
-
-static int ahash_no_import(struct ahash_request *req, const void *in)
-{
-   return -ENOSYS;
-}
-
 static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
 {
struct crypto_ahash *hash = __crypto_ahash_cast(tfm);
@@ -451,8 +441,8 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
 
hash->setkey = ahash_nosetkey;
hash->has_setkey = false;
-   hash->export = ahash_no_export;
-   hash->import = ahash_no_import;
+   hash->export = alg->export;
+   hash->import = alg->import;
 
if (tfm->__crt_alg->cra_type != _ahash_type)
return crypto_init_shash_ops_async(tfm);
@@ -467,10 +457,6 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
hash->setkey = alg->setkey;
hash->has_setkey = true;
}
-   if (alg->export)
-   hash->export = alg->export;
-   if (alg->import)
-   hash->import = alg->import;
 
return 0;
 }
-- 
2.15.0

TRADING ACCOUNT

[MONIRA François]

Hi ,

I MONIRA François  managing director of THALES COMMUNICATIONS & SECURITY 
S.A.S .I send you this email after visiting your website , regarding the 
possibility to open a trading account with your company .
We are a company based in France specialised in supplying Multi -media, 
wholesaler and other private client.
We are looking for a long term supplier/partner with good competitive 
price/quality to fulfil the client demand throughout France and others 
countries because we are interested of buying couple of your products 
you sell and want to place an order with you in large quantities.
Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) 
depending on the size of our different orders?
Please inform us of the procedure to open a trade account and apply for 
a credit insurance account base on credit check


Cordially

MONIRA François

THALES COMMUNICATIONS & SECURITY S.A.S
4 AVENUE DES LOUVRESSES
92230  GENNEVILLIERS
Tel : +33173793202
Fax : +33172703636
email: mon...@thalesgroupes.com

Re: [PATCH 0/5] sha3 fixes and new implementation for arm64

[Ard Biesheuvel]

On 16 January 2018 at 08:41, Steve Capper  wrote:
> On Fri, Jan 12, 2018 at 03:13:56PM +, Ard Biesheuvel wrote:
>> On 12 January 2018 at 13:15, Ard Biesheuvel  
>> wrote:
>> > Add an implementation of SHA3 to arm64 using the new special instructions 
>> > (#4)
>> >
>> > In preparation of that, fix a bug in the SHA3 and refactor it a bit so it
>> > can serve as a fallback for the other code. Also, add some new test vectors
>> > to get better test coverage.
>> >
>> > Ard Biesheuvel (5):
>> >   crypto/generic: sha3 - fixes for alignment and big endian operation
>> >   crypto/generic: sha3 - simplify code
>> >   crypto/generic: sha3 - export init/update/final routines
>> >   crypto/arm64: sha3 - new implementation based on special instructions
>>
>> Forgot to mention: this is an RFT for patch #4, as it has not been
>> validated against a real implementation, only against my own QEMU
>> code.
>
> Hi Ard,
> I have tested this patch set applied to 4.15-rc7 running in a model.
>
> I used the following tcrypt modes:
> 48, 49, 50, 51, 111, 112, 113, 114, 187, 188, 322, 323, 324, 325, 418,
> 419, 420 and 421.
>
> Also, I added some logic to double check that sha3_ce_transform(.)
> was being called rather than sha3_scalar_transform(.).
> (Because both the scalar and ce code paths are contained in the
> sha3-x-arm64 drivers).
>
> So, please feel free to add for the series:
> Tested-by: Steve Capper 
>

Thanks Steve!

Re: [PATCH 0/5] sha3 fixes and new implementation for arm64

[Steve Capper]

On Fri, Jan 12, 2018 at 03:13:56PM +, Ard Biesheuvel wrote:
> On 12 January 2018 at 13:15, Ard Biesheuvel  wrote:
> > Add an implementation of SHA3 to arm64 using the new special instructions 
> > (#4)
> >
> > In preparation of that, fix a bug in the SHA3 and refactor it a bit so it
> > can serve as a fallback for the other code. Also, add some new test vectors
> > to get better test coverage.
> >
> > Ard Biesheuvel (5):
> >   crypto/generic: sha3 - fixes for alignment and big endian operation
> >   crypto/generic: sha3 - simplify code
> >   crypto/generic: sha3 - export init/update/final routines
> >   crypto/arm64: sha3 - new implementation based on special instructions
> 
> Forgot to mention: this is an RFT for patch #4, as it has not been
> validated against a real implementation, only against my own QEMU
> code.

Hi Ard,
I have tested this patch set applied to 4.15-rc7 running in a model.

I used the following tcrypt modes:
48, 49, 50, 51, 111, 112, 113, 114, 187, 188, 322, 323, 324, 325, 418,
419, 420 and 421.

Also, I added some logic to double check that sha3_ce_transform(.)
was being called rather than sha3_scalar_transform(.).
(Because both the scalar and ce code paths are contained in the
sha3-x-arm64 drivers).

So, please feel free to add for the series:
Tested-by: Steve Capper 

Cheers,
-- 
Steve

> 
> >   crypto/testmgr: sha3 - add new testcases
> >
> >  arch/arm64/crypto/Kconfig|   6 +
> >  arch/arm64/crypto/Makefile   |   3 +
> >  arch/arm64/crypto/sha3-ce-core.S | 224 
> >  arch/arm64/crypto/sha3-ce-glue.c | 156 ++
> >  crypto/sha3_generic.c| 198 +++
> >  crypto/testmgr.h | 550 
> >  include/crypto/sha3.h|   6 +-
> >  7 files changed, 1012 insertions(+), 131 deletions(-)
> >  create mode 100644 arch/arm64/crypto/sha3-ce-core.S
> >  create mode 100644 arch/arm64/crypto/sha3-ce-glue.c
> >
> > --
> > 2.11.0
> >
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFT PATCH] crypto: arm64 - implement SM3 secure hash using special instructions

[Ard Biesheuvel]

Implement the Chinese SM3 secure hash algorithm using the new
special instructions that have been introduced as an optional
extension in ARMv8.2.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/Kconfig   |   5 ++
 arch/arm64/crypto/Makefile  |   3 +
 arch/arm64/crypto/sm3-ce-core.S | 142 
 arch/arm64/crypto/sm3-ce-glue.c |  92 ++
 4 files changed, 242 insertions(+)
 create mode 100644 arch/arm64/crypto/sm3-ce-core.S
 create mode 100644 arch/arm64/crypto/sm3-ce-glue.c

diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 71293e049a5d..225c3842644c 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -105,4 +105,9 @@ config CRYPTO_AES_ARM64_BS
select CRYPTO_AES_ARM64
select CRYPTO_SIMD
 
+config CRYPTO_SM3_ARM64_CE
+   tristate "SM3 digest algorithm (ARMv8.2 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_HASH
+
 endif
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 267764473ef6..989d6e51f6c9 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -56,6 +56,9 @@ aes-arm64-y := aes-cipher-core.o aes-cipher-glue.o
 obj-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o
 aes-neon-bs-y := aes-neonbs-core.o aes-neonbs-glue.o
 
+obj-$(CONFIG_CRYPTO_SM3_ARM64_CE) += sm3-ce.o
+sm3-ce-y := sm3-ce-glue.o sm3-ce-core.o
+
 AFLAGS_aes-ce.o:= -DINTERLEAVE=4
 AFLAGS_aes-neon.o  := -DINTERLEAVE=4
 
diff --git a/arch/arm64/crypto/sm3-ce-core.S b/arch/arm64/crypto/sm3-ce-core.S
new file mode 100644
index ..961d01764886
--- /dev/null
+++ b/arch/arm64/crypto/sm3-ce-core.S
@@ -0,0 +1,142 @@
+/*
+ * sm3-ce-core.S - SM3 secure hash using ARMv8.2 Crypto Extensions
+ *
+ * Copyright (C) 2018 Linaro Ltd 
+ *
+ * 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 
+#include 
+
+   .irpb,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
+   .set.Lv\b\().4s, \b
+   .endr
+
+   .macro  sm3partw1, rd, rn, rm
+   .inst   0xce60c000 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
+   .endm
+
+   .macro  sm3partw2, rd, rn, rm
+   .inst   0xce60c400 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
+   .endm
+
+   .macro  sm3ss1, rd, rn, rm, ra
+   .inst   0xce40 | .L\rd | (.L\rn << 5) | (.L\ra << 10) | 
(.L\rm << 16)
+   .endm
+
+   .macro  sm3tt1a, rd, rn, rm, imm2
+   .inst   0xce408000 | .L\rd | (.L\rn << 5) | ((\imm2) << 12) | 
(.L\rm << 16)
+   .endm
+
+   .macro  sm3tt1b, rd, rn, rm, imm2
+   .inst   0xce408400 | .L\rd | (.L\rn << 5) | ((\imm2) << 12) | 
(.L\rm << 16)
+   .endm
+
+   .macro  sm3tt2a, rd, rn, rm, imm2
+   .inst   0xce408800 | .L\rd | (.L\rn << 5) | ((\imm2) << 12) | 
(.L\rm << 16)
+   .endm
+
+   .macro  sm3tt2b, rd, rn, rm, imm2
+   .inst   0xce408c00 | .L\rd | (.L\rn << 5) | ((\imm2) << 12) | 
(.L\rm << 16)
+   .endm
+
+   .macro  round, ab, s0, t0, t1, i
+   sm3ss1  v10.4s, v8.4s, \t0\().4s, v9.4s
+   shl \t1\().4s, \t0\().4s, #1
+   sri \t1\().4s, \t0\().4s, #31
+   sm3tt1\ab   v8.4s, v10.4s, v15.4s, \i
+   sm3tt2\ab   v9.4s, v10.4s, \s0\().4s, \i
+   .endm
+
+   .macro  qround, ab, s0, s1, s2, s3, s4
+   .ifnb   \s4
+   ext \s4\().16b, \s1\().16b, \s2\().16b, #12
+   ext v13.16b, \s0\().16b, \s1\().16b, #12
+   ext v14.16b, \s2\().16b, \s3\().16b, #8
+   sm3partw1   \s4\().4s, \s0\().4s, \s3\().4s
+   .endif
+
+   eor v15.16b, \s0\().16b, \s1\().16b
+
+   round   \ab, \s0, v11, v12, 0
+   round   \ab, \s0, v12, v11, 1
+   round   \ab, \s0, v11, v12, 2
+   round   \ab, \s0, v12, v11, 3
+
+   .ifnb   \s4
+   sm3partw2   \s4\().4s, v14.4s, v13.4s
+   .endif
+   .endm
+
+   /*
+* void sm3_ce_transform(struct sm3_state *sst, u8 const *src,
+*   int blocks)
+*/
+   .text
+ENTRY(sm3_ce_transform)
+   /* load state */
+   ld1 {v8.4s-v9.4s}, [x0]
+   rev64   v8.4s, v8.4s
+   rev64   v9.4s, v9.4s
+   ext v8.16b, v8.16b, v8.16b, #8
+   ext v9.16b, v9.16b, v9.16b, #8
+
+   adrpx8, .Lt
+   ldr s16, [x8, :lo12:.Lt]
+   ldr s17, [x8, :lo12:.Lt + 4]
+
+   /* load input */
+0: ld1 {v0.16b-v3.16b}, [x1], #64
+   sub w2, w2, #1
+
+ 

Re: [RFT PATCH] crypto: arm64 - implement SHA-512 using special instructions

[Ard Biesheuvel]

On 16 January 2018 at 08:16, Steve Capper  wrote:
> On Tue, Jan 09, 2018 at 06:23:02PM +, Ard Biesheuvel wrote:
>> Implement the SHA-512 using the new special instructions that have
>> been introduced as an optional extension in ARMv8.2.
>
> Hi Ard,
> I have tested this applied on top of 4.15-rc7 running in a model.
>
> For sha512-ce, I verified that tcrypt successfully passed tests for modes:
> 12, 104, 189, 190, 306, 406 and 424.
> (and I double checked that sha512-ce was being used).
>
> Similarly for sha384-ce, I tested the following modes:
> 11, 103, 187, 188, 305 and 405.
>
> Also, I had:
> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n
>
> So FWIW, please feel free to add:
> Tested-by: Steve Capper 
>

Excellent! Thanks a lot Steve.

Re: [RFT PATCH] crypto: arm64 - implement SHA-512 using special instructions

[Steve Capper]

On Tue, Jan 09, 2018 at 06:23:02PM +, Ard Biesheuvel wrote:
> Implement the SHA-512 using the new special instructions that have
> been introduced as an optional extension in ARMv8.2.

Hi Ard,
I have tested this applied on top of 4.15-rc7 running in a model.

For sha512-ce, I verified that tcrypt successfully passed tests for modes:
12, 104, 189, 190, 306, 406 and 424.
(and I double checked that sha512-ce was being used).

Similarly for sha384-ce, I tested the following modes:
11, 103, 187, 188, 305 and 405. 

Also, I had:
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n

So FWIW, please feel free to add:
Tested-by: Steve Capper 

Cheers,
-- 
Steve