linux-stable.git/drivers/crypto, branch v4.10.8

crypto: ccp - Assign DMA commands to the channel's CCP

2017-03-30T07:44:07+00:00

commit 7c468447f40645fbf2a033dfdaa92b1957130d50 upstream.

The CCP driver generally uses a round-robin approach when
assigning operations to available CCPs. For the DMA engine,
however, the DMA mappings of the SGs are associated with a
specific CCP. When an IOMMU is enabled, the IOMMU is
programmed based on this specific device.

If the DMA operations are not performed by that specific
CCP then addressing errors and I/O page faults will occur.

Update the CCP driver to allow a specific CCP device to be
requested for an operation and use this in the DMA engine
support.

Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: s5p-sss - Fix spinlock recursion on LRW(AES)

2017-03-22T11:57:05+00:00

commit 28b62b1458685d8f68f67d9b2d511bf8fa32b746 upstream.

Running TCRYPT with LRW compiled causes spinlock recursion:

    testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
    tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
    tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
    tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
    tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
    tcrypt: test 4 (256 bit key, 8192 byte blocks):
    BUG: spinlock recursion on CPU#1, irq/84-10830000/89
     lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
    CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
    Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
    [] (show_stack) from [] (dump_stack+0x78/0x8c)
    [] (dump_stack) from [] (do_raw_spin_lock+0x11c/0x120)
    [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x20/0x28)
    [] (_raw_spin_lock_irqsave) from [] (s5p_aes_crypt+0x2c/0xb4)
    [] (s5p_aes_crypt) from [] (do_encrypt+0x78/0xb0 [lrw])
    [] (do_encrypt [lrw]) from [] (encrypt_done+0x24/0x54 [lrw])
    [] (encrypt_done [lrw]) from [] (s5p_aes_complete+0x60/0xcc)
    [] (s5p_aes_complete) from [] (s5p_aes_interrupt+0x134/0x1a0)
    [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54)
    [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0)
    [] (irq_thread) from [] (kthread+0x108/0x138)
    [] (kthread) from [] (ret_from_fork+0x14/0x3c)

Interrupt handling routine was calling req->base.complete() under
spinlock.  In most cases this wasn't fatal but when combined with some
of the cipher modes (like LRW) this caused recursion - starting the new
encryption (s5p_aes_crypt()) while still holding the spinlock from
previous round (s5p_aes_complete()).

Beside that, the s5p_aes_interrupt() error handling path could execute
two completions in case of error for RX and TX blocks.

Rewrite the interrupt handling routine and the completion by:

1. Splitting the operations on scatterlist copies from
   s5p_aes_complete() into separate s5p_sg_done(). This still should be
   done under lock.
   The s5p_aes_complete() now only calls req->base.complete() and it has
   to be called outside of lock.

2. Moving the s5p_aes_complete() out of spinlock critical sections.
   In interrupt service routine s5p_aes_interrupts(), it appeared in few
   places, including error paths inside other functions called from ISR.
   This code was not so obvious to read so simplify it by putting the
   s5p_aes_complete() only within ISR level.

Reported-by: Nathan Royce 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: vmx - Use skcipher for xts fallback

2017-03-12T05:44:15+00:00

commit 5839f555fa576be57371686265206398d9ea1480 upstream.

Signed-off-by: Paulo Flabiano Smorigo 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: vmx - Use skcipher for cbc fallback

2017-03-12T05:44:15+00:00

commit c96d0a1c47abd5c4fa544dcedb5fac4d020ac58b upstream.

Signed-off-by: Paulo Flabiano Smorigo 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2017-02-06T22:16:23+00:00

Pull crypto fixes from Herbert Xu:

 - use-after-free in algif_aead

 - modular aesni regression when pcbc is modular but absent

 - bug causing IO page faults in ccp

 - double list add in ccp

 - NULL pointer dereference in qat (two patches)

 - panic in chcr

 - NULL pointer dereference in chcr

 - out-of-bound access in chcr

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: chcr - Fix key length for RFC4106
  crypto: algif_aead - Fix kernel panic on list_del
  crypto: aesni - Fix failure when pcbc module is absent
  crypto: ccp - Fix double add when creating new DMA command
  crypto: ccp - Fix DMA operations when IOMMU is enabled
  crypto: chcr - Check device is allocated before use
  crypto: chcr - Fix panic on dma_unmap_sg
  crypto: qat - zero esram only for DH85x devices
  crypto: qat - fix bar discovery for c62x

crypto: chcr - Fix key length for RFC4106

2017-02-03T10:09:31+00:00

Check keylen before copying salt to avoid wrap around of Integer.

Signed-off-by: Harsh Jain 
Signed-off-by: Herbert Xu

crypto: ccp - Fix double add when creating new DMA command

2017-02-03T09:45:46+00:00

Eliminate a double-add by creating a new list to manage
command descriptors when created; move the descriptor to
the pending list when the command is submitted.

Cc: 
Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: ccp - Fix DMA operations when IOMMU is enabled

2017-02-03T09:45:45+00:00

An I/O page fault occurs when the IOMMU is enabled on a
system that supports the v5 CCP.  DMA operations use a
Request ID value that does not match what is expected by
the IOMMU, resulting in the I/O page fault.  Setting the
Request ID value to 0 corrects this issue.

Cc: 
Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: chcr - Check device is allocated before use

2017-02-03T09:45:44+00:00

Ensure dev is allocated for crypto uld context before using the device
for crypto operations.

Cc: 
Signed-off-by: Atul Gupta 
Signed-off-by: Herbert Xu

crypto: chcr - Fix panic on dma_unmap_sg

2017-02-03T09:45:44+00:00

Save DMA mapped sg list addresses to request context buffer.

Signed-off-by: Atul Gupta 
Signed-off-by: Herbert Xu