2011-04-08 12:40:51 +00:00
|
|
|
/*
|
|
|
|
* Cryptographic API.
|
|
|
|
*
|
|
|
|
* Support for Samsung S5PV210 HW acceleration.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2011 NetUP Inc. All rights reserved.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2016-03-22 01:58:25 +00:00
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/crypto.h>
|
|
|
|
#include <linux/dma-mapping.h>
|
2011-04-08 12:40:51 +00:00
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/errno.h>
|
2016-03-22 01:58:25 +00:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/io.h>
|
2011-04-08 12:40:51 +00:00
|
|
|
#include <linux/kernel.h>
|
2016-03-22 01:58:25 +00:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/of.h>
|
2011-04-08 12:40:51 +00:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
|
|
|
|
#include <crypto/ctr.h>
|
2016-03-22 01:58:25 +00:00
|
|
|
#include <crypto/aes.h>
|
|
|
|
#include <crypto/algapi.h>
|
2016-03-22 01:58:24 +00:00
|
|
|
#include <crypto/scatterwalk.h>
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define _SBF(s, v) ((v) << (s))
|
|
|
|
|
|
|
|
/* Feed control registers */
|
|
|
|
#define SSS_REG_FCINTSTAT 0x0000
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCINTSTAT_BRDMAINT BIT(3)
|
|
|
|
#define SSS_FCINTSTAT_BTDMAINT BIT(2)
|
|
|
|
#define SSS_FCINTSTAT_HRDMAINT BIT(1)
|
|
|
|
#define SSS_FCINTSTAT_PKDMAINT BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCINTENSET 0x0004
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCINTENSET_BRDMAINTENSET BIT(3)
|
|
|
|
#define SSS_FCINTENSET_BTDMAINTENSET BIT(2)
|
|
|
|
#define SSS_FCINTENSET_HRDMAINTENSET BIT(1)
|
|
|
|
#define SSS_FCINTENSET_PKDMAINTENSET BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCINTENCLR 0x0008
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCINTENCLR_BRDMAINTENCLR BIT(3)
|
|
|
|
#define SSS_FCINTENCLR_BTDMAINTENCLR BIT(2)
|
|
|
|
#define SSS_FCINTENCLR_HRDMAINTENCLR BIT(1)
|
|
|
|
#define SSS_FCINTENCLR_PKDMAINTENCLR BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCINTPEND 0x000C
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCINTPEND_BRDMAINTP BIT(3)
|
|
|
|
#define SSS_FCINTPEND_BTDMAINTP BIT(2)
|
|
|
|
#define SSS_FCINTPEND_HRDMAINTP BIT(1)
|
|
|
|
#define SSS_FCINTPEND_PKDMAINTP BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCFIFOSTAT 0x0010
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCFIFOSTAT_BRFIFOFUL BIT(7)
|
|
|
|
#define SSS_FCFIFOSTAT_BRFIFOEMP BIT(6)
|
|
|
|
#define SSS_FCFIFOSTAT_BTFIFOFUL BIT(5)
|
|
|
|
#define SSS_FCFIFOSTAT_BTFIFOEMP BIT(4)
|
|
|
|
#define SSS_FCFIFOSTAT_HRFIFOFUL BIT(3)
|
|
|
|
#define SSS_FCFIFOSTAT_HRFIFOEMP BIT(2)
|
|
|
|
#define SSS_FCFIFOSTAT_PKFIFOFUL BIT(1)
|
|
|
|
#define SSS_FCFIFOSTAT_PKFIFOEMP BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCFIFOCTRL 0x0014
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCFIFOCTRL_DESSEL BIT(2)
|
2011-04-08 12:40:51 +00:00
|
|
|
#define SSS_HASHIN_INDEPENDENT _SBF(0, 0x00)
|
|
|
|
#define SSS_HASHIN_CIPHER_INPUT _SBF(0, 0x01)
|
|
|
|
#define SSS_HASHIN_CIPHER_OUTPUT _SBF(0, 0x02)
|
|
|
|
|
|
|
|
#define SSS_REG_FCBRDMAS 0x0020
|
|
|
|
#define SSS_REG_FCBRDMAL 0x0024
|
|
|
|
#define SSS_REG_FCBRDMAC 0x0028
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCBRDMAC_BYTESWAP BIT(1)
|
|
|
|
#define SSS_FCBRDMAC_FLUSH BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCBTDMAS 0x0030
|
|
|
|
#define SSS_REG_FCBTDMAL 0x0034
|
|
|
|
#define SSS_REG_FCBTDMAC 0x0038
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCBTDMAC_BYTESWAP BIT(1)
|
|
|
|
#define SSS_FCBTDMAC_FLUSH BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCHRDMAS 0x0040
|
|
|
|
#define SSS_REG_FCHRDMAL 0x0044
|
|
|
|
#define SSS_REG_FCHRDMAC 0x0048
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCHRDMAC_BYTESWAP BIT(1)
|
|
|
|
#define SSS_FCHRDMAC_FLUSH BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCPKDMAS 0x0050
|
|
|
|
#define SSS_REG_FCPKDMAL 0x0054
|
|
|
|
#define SSS_REG_FCPKDMAC 0x0058
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_FCPKDMAC_BYTESWAP BIT(3)
|
|
|
|
#define SSS_FCPKDMAC_DESCEND BIT(2)
|
|
|
|
#define SSS_FCPKDMAC_TRANSMIT BIT(1)
|
|
|
|
#define SSS_FCPKDMAC_FLUSH BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG_FCPKDMAO 0x005C
|
|
|
|
|
|
|
|
/* AES registers */
|
2014-05-08 13:58:14 +00:00
|
|
|
#define SSS_REG_AES_CONTROL 0x00
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_AES_BYTESWAP_DI BIT(11)
|
|
|
|
#define SSS_AES_BYTESWAP_DO BIT(10)
|
|
|
|
#define SSS_AES_BYTESWAP_IV BIT(9)
|
|
|
|
#define SSS_AES_BYTESWAP_CNT BIT(8)
|
|
|
|
#define SSS_AES_BYTESWAP_KEY BIT(7)
|
|
|
|
#define SSS_AES_KEY_CHANGE_MODE BIT(6)
|
2011-04-08 12:40:51 +00:00
|
|
|
#define SSS_AES_KEY_SIZE_128 _SBF(4, 0x00)
|
|
|
|
#define SSS_AES_KEY_SIZE_192 _SBF(4, 0x01)
|
|
|
|
#define SSS_AES_KEY_SIZE_256 _SBF(4, 0x02)
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_AES_FIFO_MODE BIT(3)
|
2011-04-08 12:40:51 +00:00
|
|
|
#define SSS_AES_CHAIN_MODE_ECB _SBF(1, 0x00)
|
|
|
|
#define SSS_AES_CHAIN_MODE_CBC _SBF(1, 0x01)
|
|
|
|
#define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_AES_MODE_DECRYPT BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
#define SSS_REG_AES_STATUS 0x04
|
2016-04-22 12:15:22 +00:00
|
|
|
#define SSS_AES_BUSY BIT(2)
|
|
|
|
#define SSS_AES_INPUT_READY BIT(1)
|
|
|
|
#define SSS_AES_OUTPUT_READY BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
#define SSS_REG_AES_IN_DATA(s) (0x10 + (s << 2))
|
|
|
|
#define SSS_REG_AES_OUT_DATA(s) (0x20 + (s << 2))
|
|
|
|
#define SSS_REG_AES_IV_DATA(s) (0x30 + (s << 2))
|
|
|
|
#define SSS_REG_AES_CNT_DATA(s) (0x40 + (s << 2))
|
|
|
|
#define SSS_REG_AES_KEY_DATA(s) (0x80 + (s << 2))
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
#define SSS_REG(dev, reg) ((dev)->ioaddr + (SSS_REG_##reg))
|
|
|
|
#define SSS_READ(dev, reg) __raw_readl(SSS_REG(dev, reg))
|
|
|
|
#define SSS_WRITE(dev, reg, val) __raw_writel((val), SSS_REG(dev, reg))
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
#define SSS_AES_REG(dev, reg) ((dev)->aes_ioaddr + SSS_REG_##reg)
|
|
|
|
#define SSS_AES_WRITE(dev, reg, val) __raw_writel((val), \
|
|
|
|
SSS_AES_REG(dev, reg))
|
|
|
|
|
2011-04-08 12:40:51 +00:00
|
|
|
/* HW engine modes */
|
2016-04-22 12:15:22 +00:00
|
|
|
#define FLAGS_AES_DECRYPT BIT(0)
|
2011-04-08 12:40:51 +00:00
|
|
|
#define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
|
|
|
|
#define FLAGS_AES_CBC _SBF(1, 0x01)
|
|
|
|
#define FLAGS_AES_CTR _SBF(1, 0x02)
|
|
|
|
|
|
|
|
#define AES_KEY_LEN 16
|
|
|
|
#define CRYPTO_QUEUE_LEN 1
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
/**
|
|
|
|
* struct samsung_aes_variant - platform specific SSS driver data
|
|
|
|
* @aes_offset: AES register offset from SSS module's base.
|
|
|
|
*
|
|
|
|
* Specifies platform specific configuration of SSS module.
|
|
|
|
* Note: A structure for driver specific platform data is used for future
|
|
|
|
* expansion of its usage.
|
|
|
|
*/
|
|
|
|
struct samsung_aes_variant {
|
2016-05-27 11:49:40 +00:00
|
|
|
unsigned int aes_offset;
|
2014-05-08 13:58:14 +00:00
|
|
|
};
|
|
|
|
|
2011-04-08 12:40:51 +00:00
|
|
|
struct s5p_aes_reqctx {
|
2016-05-27 11:49:40 +00:00
|
|
|
unsigned long mode;
|
2011-04-08 12:40:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct s5p_aes_ctx {
|
2016-05-27 11:49:40 +00:00
|
|
|
struct s5p_aes_dev *dev;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2016-05-27 11:49:40 +00:00
|
|
|
uint8_t aes_key[AES_MAX_KEY_SIZE];
|
|
|
|
uint8_t nonce[CTR_RFC3686_NONCE_SIZE];
|
|
|
|
int keylen;
|
2011-04-08 12:40:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct s5p_aes_dev {
|
2016-05-27 11:49:40 +00:00
|
|
|
struct device *dev;
|
|
|
|
struct clk *clk;
|
|
|
|
void __iomem *ioaddr;
|
|
|
|
void __iomem *aes_ioaddr;
|
|
|
|
int irq_fc;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2016-05-27 11:49:40 +00:00
|
|
|
struct ablkcipher_request *req;
|
|
|
|
struct s5p_aes_ctx *ctx;
|
|
|
|
struct scatterlist *sg_src;
|
|
|
|
struct scatterlist *sg_dst;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
/* In case of unaligned access: */
|
2016-05-27 11:49:40 +00:00
|
|
|
struct scatterlist *sg_src_cpy;
|
|
|
|
struct scatterlist *sg_dst_cpy;
|
2016-03-22 01:58:24 +00:00
|
|
|
|
2016-05-27 11:49:40 +00:00
|
|
|
struct tasklet_struct tasklet;
|
|
|
|
struct crypto_queue queue;
|
|
|
|
bool busy;
|
|
|
|
spinlock_t lock;
|
2014-05-08 13:58:14 +00:00
|
|
|
|
2016-05-27 11:49:40 +00:00
|
|
|
struct samsung_aes_variant *variant;
|
2011-04-08 12:40:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct s5p_aes_dev *s5p_dev;
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
static const struct samsung_aes_variant s5p_aes_data = {
|
|
|
|
.aes_offset = 0x4000,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct samsung_aes_variant exynos_aes_data = {
|
|
|
|
.aes_offset = 0x200,
|
|
|
|
};
|
|
|
|
|
2014-05-08 13:58:13 +00:00
|
|
|
static const struct of_device_id s5p_sss_dt_match[] = {
|
2014-05-08 13:58:14 +00:00
|
|
|
{
|
|
|
|
.compatible = "samsung,s5pv210-secss",
|
|
|
|
.data = &s5p_aes_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "samsung,exynos4210-secss",
|
|
|
|
.data = &exynos_aes_data,
|
|
|
|
},
|
2014-05-08 13:58:13 +00:00
|
|
|
{ },
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
static inline struct samsung_aes_variant *find_s5p_sss_version
|
|
|
|
(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
if (IS_ENABLED(CONFIG_OF) && (pdev->dev.of_node)) {
|
|
|
|
const struct of_device_id *match;
|
2016-01-11 11:45:50 +00:00
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
match = of_match_node(s5p_sss_dt_match,
|
|
|
|
pdev->dev.of_node);
|
|
|
|
return (struct samsung_aes_variant *)match->data;
|
|
|
|
}
|
|
|
|
return (struct samsung_aes_variant *)
|
|
|
|
platform_get_device_id(pdev)->driver_data;
|
|
|
|
}
|
|
|
|
|
2011-04-08 12:40:51 +00:00
|
|
|
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
|
|
|
|
{
|
|
|
|
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
|
|
|
|
SSS_WRITE(dev, FCBRDMAL, sg_dma_len(sg));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_set_dma_outdata(struct s5p_aes_dev *dev, struct scatterlist *sg)
|
|
|
|
{
|
|
|
|
SSS_WRITE(dev, FCBTDMAS, sg_dma_address(sg));
|
|
|
|
SSS_WRITE(dev, FCBTDMAL, sg_dma_len(sg));
|
|
|
|
}
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
static void s5p_free_sg_cpy(struct s5p_aes_dev *dev, struct scatterlist **sg)
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if (!*sg)
|
|
|
|
return;
|
|
|
|
|
|
|
|
len = ALIGN(dev->req->nbytes, AES_BLOCK_SIZE);
|
|
|
|
free_pages((unsigned long)sg_virt(*sg), get_order(len));
|
|
|
|
|
|
|
|
kfree(*sg);
|
|
|
|
*sg = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_sg_copy_buf(void *buf, struct scatterlist *sg,
|
|
|
|
unsigned int nbytes, int out)
|
|
|
|
{
|
|
|
|
struct scatter_walk walk;
|
|
|
|
|
|
|
|
if (!nbytes)
|
|
|
|
return;
|
|
|
|
|
|
|
|
scatterwalk_start(&walk, sg);
|
|
|
|
scatterwalk_copychunks(buf, &walk, nbytes, out);
|
|
|
|
scatterwalk_done(&walk, out, 0);
|
|
|
|
}
|
|
|
|
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
static void s5p_sg_done(struct s5p_aes_dev *dev)
|
2011-04-08 12:40:51 +00:00
|
|
|
{
|
2016-03-22 01:58:24 +00:00
|
|
|
if (dev->sg_dst_cpy) {
|
|
|
|
dev_dbg(dev->dev,
|
|
|
|
"Copying %d bytes of output data back to original place\n",
|
|
|
|
dev->req->nbytes);
|
|
|
|
s5p_sg_copy_buf(sg_virt(dev->sg_dst_cpy), dev->req->dst,
|
|
|
|
dev->req->nbytes, 1);
|
|
|
|
}
|
|
|
|
s5p_free_sg_cpy(dev, &dev->sg_src_cpy);
|
|
|
|
s5p_free_sg_cpy(dev, &dev->sg_dst_cpy);
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
}
|
2016-03-22 01:58:24 +00:00
|
|
|
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
/* Calls the completion. Cannot be called with dev->lock hold. */
|
|
|
|
static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
|
|
|
|
{
|
2011-04-08 12:40:51 +00:00
|
|
|
dev->req->base.complete(&dev->req->base, err);
|
|
|
|
dev->busy = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_unset_outdata(struct s5p_aes_dev *dev)
|
|
|
|
{
|
|
|
|
dma_unmap_sg(dev->dev, dev->sg_dst, 1, DMA_FROM_DEVICE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_unset_indata(struct s5p_aes_dev *dev)
|
|
|
|
{
|
|
|
|
dma_unmap_sg(dev->dev, dev->sg_src, 1, DMA_TO_DEVICE);
|
|
|
|
}
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
static int s5p_make_sg_cpy(struct s5p_aes_dev *dev, struct scatterlist *src,
|
|
|
|
struct scatterlist **dst)
|
|
|
|
{
|
|
|
|
void *pages;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
*dst = kmalloc(sizeof(**dst), GFP_ATOMIC);
|
|
|
|
if (!*dst)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
len = ALIGN(dev->req->nbytes, AES_BLOCK_SIZE);
|
|
|
|
pages = (void *)__get_free_pages(GFP_ATOMIC, get_order(len));
|
|
|
|
if (!pages) {
|
|
|
|
kfree(*dst);
|
|
|
|
*dst = NULL;
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
s5p_sg_copy_buf(pages, src, dev->req->nbytes, 0);
|
|
|
|
|
|
|
|
sg_init_table(*dst, 1);
|
|
|
|
sg_set_buf(*dst, pages, len);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-04-08 12:40:51 +00:00
|
|
|
static int s5p_set_outdata(struct s5p_aes_dev *dev, struct scatterlist *sg)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2016-04-26 07:29:26 +00:00
|
|
|
if (!sg->length) {
|
2011-04-08 12:40:51 +00:00
|
|
|
err = -EINVAL;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = dma_map_sg(dev->dev, sg, 1, DMA_FROM_DEVICE);
|
|
|
|
if (!err) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev->sg_dst = sg;
|
|
|
|
err = 0;
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
exit:
|
2011-04-08 12:40:51 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_set_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2016-04-26 07:29:26 +00:00
|
|
|
if (!sg->length) {
|
2011-04-08 12:40:51 +00:00
|
|
|
err = -EINVAL;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = dma_map_sg(dev->dev, sg, 1, DMA_TO_DEVICE);
|
|
|
|
if (!err) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev->sg_src = sg;
|
|
|
|
err = 0;
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
exit:
|
2011-04-08 12:40:51 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-04-22 12:15:23 +00:00
|
|
|
/*
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
* Returns -ERRNO on error (mapping of new data failed).
|
|
|
|
* On success returns:
|
|
|
|
* - 0 if there is no more data,
|
|
|
|
* - 1 if new transmitting (output) data is ready and its address+length
|
|
|
|
* have to be written to device (by calling s5p_set_dma_outdata()).
|
2016-04-22 12:15:23 +00:00
|
|
|
*/
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
static int s5p_aes_tx(struct s5p_aes_dev *dev)
|
2011-04-08 12:40:51 +00:00
|
|
|
{
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
int ret = 0;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
s5p_unset_outdata(dev);
|
|
|
|
|
|
|
|
if (!sg_is_last(dev->sg_dst)) {
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
ret = s5p_set_outdata(dev, sg_next(dev->sg_dst));
|
|
|
|
if (!ret)
|
|
|
|
ret = 1;
|
2014-05-08 13:58:15 +00:00
|
|
|
}
|
2016-04-22 12:15:23 +00:00
|
|
|
|
|
|
|
return ret;
|
2011-04-08 12:40:51 +00:00
|
|
|
}
|
|
|
|
|
2016-04-22 12:15:23 +00:00
|
|
|
/*
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
* Returns -ERRNO on error (mapping of new data failed).
|
|
|
|
* On success returns:
|
|
|
|
* - 0 if there is no more data,
|
|
|
|
* - 1 if new receiving (input) data is ready and its address+length
|
|
|
|
* have to be written to device (by calling s5p_set_dma_indata()).
|
2016-04-22 12:15:23 +00:00
|
|
|
*/
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
static int s5p_aes_rx(struct s5p_aes_dev *dev/*, bool *set_dma*/)
|
2011-04-08 12:40:51 +00:00
|
|
|
{
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
int ret = 0;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
s5p_unset_indata(dev);
|
|
|
|
|
|
|
|
if (!sg_is_last(dev->sg_src)) {
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
ret = s5p_set_indata(dev, sg_next(dev->sg_src));
|
|
|
|
if (!ret)
|
|
|
|
ret = 1;
|
2011-04-08 12:40:51 +00:00
|
|
|
}
|
2016-04-22 12:15:23 +00:00
|
|
|
|
|
|
|
return ret;
|
2011-04-08 12:40:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t s5p_aes_interrupt(int irq, void *dev_id)
|
|
|
|
{
|
|
|
|
struct platform_device *pdev = dev_id;
|
2016-05-27 11:49:40 +00:00
|
|
|
struct s5p_aes_dev *dev = platform_get_drvdata(pdev);
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
int err_dma_tx = 0;
|
|
|
|
int err_dma_rx = 0;
|
|
|
|
bool tx_end = false;
|
2016-05-27 11:49:40 +00:00
|
|
|
unsigned long flags;
|
|
|
|
uint32_t status;
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
int err;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->lock, flags);
|
|
|
|
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
/*
|
|
|
|
* Handle rx or tx interrupt. If there is still data (scatterlist did not
|
|
|
|
* reach end), then map next scatterlist entry.
|
|
|
|
* In case of such mapping error, s5p_aes_complete() should be called.
|
|
|
|
*
|
|
|
|
* If there is no more data in tx scatter list, call s5p_aes_complete()
|
|
|
|
* and schedule new tasklet.
|
|
|
|
*/
|
2016-04-19 13:44:12 +00:00
|
|
|
status = SSS_READ(dev, FCINTSTAT);
|
|
|
|
if (status & SSS_FCINTSTAT_BRDMAINT)
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
err_dma_rx = s5p_aes_rx(dev);
|
|
|
|
|
|
|
|
if (status & SSS_FCINTSTAT_BTDMAINT) {
|
|
|
|
if (sg_is_last(dev->sg_dst))
|
|
|
|
tx_end = true;
|
|
|
|
err_dma_tx = s5p_aes_tx(dev);
|
|
|
|
}
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2016-04-19 13:44:12 +00:00
|
|
|
SSS_WRITE(dev, FCINTPEND, status);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
if (err_dma_rx < 0) {
|
|
|
|
err = err_dma_rx;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (err_dma_tx < 0) {
|
|
|
|
err = err_dma_tx;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tx_end) {
|
|
|
|
s5p_sg_done(dev);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
|
|
|
|
|
|
|
s5p_aes_complete(dev, 0);
|
|
|
|
dev->busy = true;
|
|
|
|
tasklet_schedule(&dev->tasklet);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Writing length of DMA block (either receiving or
|
|
|
|
* transmitting) will start the operation immediately, so this
|
|
|
|
* should be done at the end (even after clearing pending
|
|
|
|
* interrupts to not miss the interrupt).
|
|
|
|
*/
|
|
|
|
if (err_dma_tx == 1)
|
|
|
|
s5p_set_dma_outdata(dev, dev->sg_dst);
|
|
|
|
if (err_dma_rx == 1)
|
|
|
|
s5p_set_dma_indata(dev, dev->sg_src);
|
2016-04-22 12:15:23 +00:00
|
|
|
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
|
|
|
|
error:
|
|
|
|
s5p_sg_done(dev);
|
2011-04-08 12:40:51 +00:00
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
s5p_aes_complete(dev, err);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_set_aes(struct s5p_aes_dev *dev,
|
|
|
|
uint8_t *key, uint8_t *iv, unsigned int keylen)
|
|
|
|
{
|
|
|
|
void __iomem *keystart;
|
|
|
|
|
2014-05-08 13:58:15 +00:00
|
|
|
if (iv)
|
2016-01-11 11:45:51 +00:00
|
|
|
memcpy_toio(dev->aes_ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
if (keylen == AES_KEYSIZE_256)
|
2014-05-08 13:58:14 +00:00
|
|
|
keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
|
2011-04-08 12:40:51 +00:00
|
|
|
else if (keylen == AES_KEYSIZE_192)
|
2014-05-08 13:58:14 +00:00
|
|
|
keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(2);
|
2011-04-08 12:40:51 +00:00
|
|
|
else
|
2014-05-08 13:58:14 +00:00
|
|
|
keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(4);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2016-01-11 11:45:51 +00:00
|
|
|
memcpy_toio(keystart, key, keylen);
|
2011-04-08 12:40:51 +00:00
|
|
|
}
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
static bool s5p_is_sg_aligned(struct scatterlist *sg)
|
|
|
|
{
|
|
|
|
while (sg) {
|
2016-04-26 07:29:26 +00:00
|
|
|
if (!IS_ALIGNED(sg->length, AES_BLOCK_SIZE))
|
2016-03-22 01:58:24 +00:00
|
|
|
return false;
|
|
|
|
sg = sg_next(sg);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_set_indata_start(struct s5p_aes_dev *dev,
|
|
|
|
struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
struct scatterlist *sg;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
dev->sg_src_cpy = NULL;
|
|
|
|
sg = req->src;
|
|
|
|
if (!s5p_is_sg_aligned(sg)) {
|
|
|
|
dev_dbg(dev->dev,
|
|
|
|
"At least one unaligned source scatter list, making a copy\n");
|
|
|
|
err = s5p_make_sg_cpy(dev, sg, &dev->sg_src_cpy);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
sg = dev->sg_src_cpy;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = s5p_set_indata(dev, sg);
|
|
|
|
if (err) {
|
|
|
|
s5p_free_sg_cpy(dev, &dev->sg_src_cpy);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_set_outdata_start(struct s5p_aes_dev *dev,
|
|
|
|
struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
struct scatterlist *sg;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
dev->sg_dst_cpy = NULL;
|
|
|
|
sg = req->dst;
|
|
|
|
if (!s5p_is_sg_aligned(sg)) {
|
|
|
|
dev_dbg(dev->dev,
|
|
|
|
"At least one unaligned dest scatter list, making a copy\n");
|
|
|
|
err = s5p_make_sg_cpy(dev, sg, &dev->sg_dst_cpy);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
sg = dev->sg_dst_cpy;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = s5p_set_outdata(dev, sg);
|
|
|
|
if (err) {
|
|
|
|
s5p_free_sg_cpy(dev, &dev->sg_dst_cpy);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-04-08 12:40:51 +00:00
|
|
|
static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode)
|
|
|
|
{
|
2016-05-27 11:49:40 +00:00
|
|
|
struct ablkcipher_request *req = dev->req;
|
|
|
|
uint32_t aes_control;
|
|
|
|
unsigned long flags;
|
|
|
|
int err;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
aes_control = SSS_AES_KEY_CHANGE_MODE;
|
|
|
|
if (mode & FLAGS_AES_DECRYPT)
|
|
|
|
aes_control |= SSS_AES_MODE_DECRYPT;
|
|
|
|
|
|
|
|
if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
|
|
|
|
aes_control |= SSS_AES_CHAIN_MODE_CBC;
|
|
|
|
else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
|
|
|
|
aes_control |= SSS_AES_CHAIN_MODE_CTR;
|
|
|
|
|
|
|
|
if (dev->ctx->keylen == AES_KEYSIZE_192)
|
|
|
|
aes_control |= SSS_AES_KEY_SIZE_192;
|
|
|
|
else if (dev->ctx->keylen == AES_KEYSIZE_256)
|
|
|
|
aes_control |= SSS_AES_KEY_SIZE_256;
|
|
|
|
|
|
|
|
aes_control |= SSS_AES_FIFO_MODE;
|
|
|
|
|
|
|
|
/* as a variant it is possible to use byte swapping on DMA side */
|
|
|
|
aes_control |= SSS_AES_BYTESWAP_DI
|
|
|
|
| SSS_AES_BYTESWAP_DO
|
|
|
|
| SSS_AES_BYTESWAP_IV
|
|
|
|
| SSS_AES_BYTESWAP_KEY
|
|
|
|
| SSS_AES_BYTESWAP_CNT;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->lock, flags);
|
|
|
|
|
|
|
|
SSS_WRITE(dev, FCINTENCLR,
|
|
|
|
SSS_FCINTENCLR_BTDMAINTENCLR | SSS_FCINTENCLR_BRDMAINTENCLR);
|
|
|
|
SSS_WRITE(dev, FCFIFOCTRL, 0x00);
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
err = s5p_set_indata_start(dev, req);
|
2011-04-08 12:40:51 +00:00
|
|
|
if (err)
|
|
|
|
goto indata_error;
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
err = s5p_set_outdata_start(dev, req);
|
2011-04-08 12:40:51 +00:00
|
|
|
if (err)
|
|
|
|
goto outdata_error;
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
|
2011-04-08 12:40:51 +00:00
|
|
|
s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
|
|
|
|
|
2016-03-22 01:58:24 +00:00
|
|
|
s5p_set_dma_indata(dev, dev->sg_src);
|
|
|
|
s5p_set_dma_outdata(dev, dev->sg_dst);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
SSS_WRITE(dev, FCINTENSET,
|
|
|
|
SSS_FCINTENSET_BTDMAINTENSET | SSS_FCINTENSET_BRDMAINTENSET);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
outdata_error:
|
2011-04-08 12:40:51 +00:00
|
|
|
s5p_unset_indata(dev);
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
indata_error:
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
s5p_sg_done(dev);
|
2011-04-08 12:40:51 +00:00
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
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)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (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 <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-08 21:14:20 +00:00
|
|
|
s5p_aes_complete(dev, err);
|
2011-04-08 12:40:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void s5p_tasklet_cb(unsigned long data)
|
|
|
|
{
|
|
|
|
struct s5p_aes_dev *dev = (struct s5p_aes_dev *)data;
|
|
|
|
struct crypto_async_request *async_req, *backlog;
|
|
|
|
struct s5p_aes_reqctx *reqctx;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->lock, flags);
|
|
|
|
backlog = crypto_get_backlog(&dev->queue);
|
|
|
|
async_req = crypto_dequeue_request(&dev->queue);
|
|
|
|
|
2014-05-08 13:58:15 +00:00
|
|
|
if (!async_req) {
|
|
|
|
dev->busy = false;
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
2011-04-08 12:40:51 +00:00
|
|
|
return;
|
2014-05-08 13:58:15 +00:00
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
if (backlog)
|
|
|
|
backlog->complete(backlog, -EINPROGRESS);
|
|
|
|
|
|
|
|
dev->req = ablkcipher_request_cast(async_req);
|
|
|
|
dev->ctx = crypto_tfm_ctx(dev->req->base.tfm);
|
|
|
|
reqctx = ablkcipher_request_ctx(dev->req);
|
|
|
|
|
|
|
|
s5p_aes_crypt_start(dev, reqctx->mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_handle_req(struct s5p_aes_dev *dev,
|
|
|
|
struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->lock, flags);
|
2014-05-08 13:58:15 +00:00
|
|
|
err = ablkcipher_enqueue_request(&dev->queue, req);
|
2011-04-08 12:40:51 +00:00
|
|
|
if (dev->busy) {
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
dev->busy = true;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&dev->lock, flags);
|
|
|
|
|
|
|
|
tasklet_schedule(&dev->tasklet);
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
exit:
|
2011-04-08 12:40:51 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_crypt(struct ablkcipher_request *req, unsigned long mode)
|
|
|
|
{
|
2016-05-27 11:49:40 +00:00
|
|
|
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
|
|
|
|
struct s5p_aes_reqctx *reqctx = ablkcipher_request_ctx(req);
|
|
|
|
struct s5p_aes_ctx *ctx = crypto_ablkcipher_ctx(tfm);
|
|
|
|
struct s5p_aes_dev *dev = ctx->dev;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
if (!IS_ALIGNED(req->nbytes, AES_BLOCK_SIZE)) {
|
2016-01-11 11:45:50 +00:00
|
|
|
dev_err(dev->dev, "request size is not exact amount of AES blocks\n");
|
2011-04-08 12:40:51 +00:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
reqctx->mode = mode;
|
|
|
|
|
|
|
|
return s5p_aes_handle_req(dev, req);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_setkey(struct crypto_ablkcipher *cipher,
|
|
|
|
const uint8_t *key, unsigned int keylen)
|
|
|
|
{
|
2016-05-27 11:49:40 +00:00
|
|
|
struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
|
2011-04-08 12:40:51 +00:00
|
|
|
struct s5p_aes_ctx *ctx = crypto_tfm_ctx(tfm);
|
|
|
|
|
|
|
|
if (keylen != AES_KEYSIZE_128 &&
|
|
|
|
keylen != AES_KEYSIZE_192 &&
|
|
|
|
keylen != AES_KEYSIZE_256)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
memcpy(ctx->aes_key, key, keylen);
|
|
|
|
ctx->keylen = keylen;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_ecb_encrypt(struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
return s5p_aes_crypt(req, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_ecb_decrypt(struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
return s5p_aes_crypt(req, FLAGS_AES_DECRYPT);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_cbc_encrypt(struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
return s5p_aes_crypt(req, FLAGS_AES_CBC);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_cbc_decrypt(struct ablkcipher_request *req)
|
|
|
|
{
|
|
|
|
return s5p_aes_crypt(req, FLAGS_AES_DECRYPT | FLAGS_AES_CBC);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_cra_init(struct crypto_tfm *tfm)
|
|
|
|
{
|
2016-01-11 11:45:50 +00:00
|
|
|
struct s5p_aes_ctx *ctx = crypto_tfm_ctx(tfm);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
ctx->dev = s5p_dev;
|
|
|
|
tfm->crt_ablkcipher.reqsize = sizeof(struct s5p_aes_reqctx);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct crypto_alg algs[] = {
|
|
|
|
{
|
|
|
|
.cra_name = "ecb(aes)",
|
|
|
|
.cra_driver_name = "ecb-aes-s5p",
|
|
|
|
.cra_priority = 100,
|
|
|
|
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
|
2011-11-01 12:39:56 +00:00
|
|
|
CRYPTO_ALG_ASYNC |
|
|
|
|
CRYPTO_ALG_KERN_DRIVER_ONLY,
|
2011-04-08 12:40:51 +00:00
|
|
|
.cra_blocksize = AES_BLOCK_SIZE,
|
|
|
|
.cra_ctxsize = sizeof(struct s5p_aes_ctx),
|
|
|
|
.cra_alignmask = 0x0f,
|
|
|
|
.cra_type = &crypto_ablkcipher_type,
|
|
|
|
.cra_module = THIS_MODULE,
|
|
|
|
.cra_init = s5p_aes_cra_init,
|
|
|
|
.cra_u.ablkcipher = {
|
|
|
|
.min_keysize = AES_MIN_KEY_SIZE,
|
|
|
|
.max_keysize = AES_MAX_KEY_SIZE,
|
|
|
|
.setkey = s5p_aes_setkey,
|
|
|
|
.encrypt = s5p_aes_ecb_encrypt,
|
|
|
|
.decrypt = s5p_aes_ecb_decrypt,
|
|
|
|
}
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.cra_name = "cbc(aes)",
|
|
|
|
.cra_driver_name = "cbc-aes-s5p",
|
|
|
|
.cra_priority = 100,
|
|
|
|
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
|
2011-11-01 12:39:56 +00:00
|
|
|
CRYPTO_ALG_ASYNC |
|
|
|
|
CRYPTO_ALG_KERN_DRIVER_ONLY,
|
2011-04-08 12:40:51 +00:00
|
|
|
.cra_blocksize = AES_BLOCK_SIZE,
|
|
|
|
.cra_ctxsize = sizeof(struct s5p_aes_ctx),
|
|
|
|
.cra_alignmask = 0x0f,
|
|
|
|
.cra_type = &crypto_ablkcipher_type,
|
|
|
|
.cra_module = THIS_MODULE,
|
|
|
|
.cra_init = s5p_aes_cra_init,
|
|
|
|
.cra_u.ablkcipher = {
|
|
|
|
.min_keysize = AES_MIN_KEY_SIZE,
|
|
|
|
.max_keysize = AES_MAX_KEY_SIZE,
|
|
|
|
.ivsize = AES_BLOCK_SIZE,
|
|
|
|
.setkey = s5p_aes_setkey,
|
|
|
|
.encrypt = s5p_aes_cbc_encrypt,
|
|
|
|
.decrypt = s5p_aes_cbc_decrypt,
|
|
|
|
}
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
static int s5p_aes_probe(struct platform_device *pdev)
|
|
|
|
{
|
2016-05-27 11:49:40 +00:00
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
int i, j, err = -ENODEV;
|
2014-05-08 13:58:14 +00:00
|
|
|
struct samsung_aes_variant *variant;
|
2016-05-27 11:49:40 +00:00
|
|
|
struct s5p_aes_dev *pdata;
|
|
|
|
struct resource *res;
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
if (s5p_dev)
|
|
|
|
return -EEXIST;
|
|
|
|
|
|
|
|
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
|
|
|
|
if (!pdata)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2014-02-12 04:24:57 +00:00
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
pdata->ioaddr = devm_ioremap_resource(&pdev->dev, res);
|
|
|
|
if (IS_ERR(pdata->ioaddr))
|
|
|
|
return PTR_ERR(pdata->ioaddr);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
variant = find_s5p_sss_version(pdev);
|
|
|
|
|
2013-01-10 02:05:30 +00:00
|
|
|
pdata->clk = devm_clk_get(dev, "secss");
|
2011-04-08 12:40:51 +00:00
|
|
|
if (IS_ERR(pdata->clk)) {
|
|
|
|
dev_err(dev, "failed to find secss clock source\n");
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
2014-05-08 13:58:15 +00:00
|
|
|
err = clk_prepare_enable(pdata->clk);
|
|
|
|
if (err < 0) {
|
|
|
|
dev_err(dev, "Enabling SSS clk failed, err %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
spin_lock_init(&pdata->lock);
|
|
|
|
|
2014-05-08 13:58:14 +00:00
|
|
|
pdata->aes_ioaddr = pdata->ioaddr + variant->aes_offset;
|
|
|
|
|
2014-05-08 13:58:12 +00:00
|
|
|
pdata->irq_fc = platform_get_irq(pdev, 0);
|
|
|
|
if (pdata->irq_fc < 0) {
|
|
|
|
err = pdata->irq_fc;
|
|
|
|
dev_warn(dev, "feed control interrupt is not available.\n");
|
2011-04-08 12:40:51 +00:00
|
|
|
goto err_irq;
|
|
|
|
}
|
2017-03-05 17:14:07 +00:00
|
|
|
err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL,
|
|
|
|
s5p_aes_interrupt, IRQF_ONESHOT,
|
|
|
|
pdev->name, pdev);
|
2011-04-08 12:40:51 +00:00
|
|
|
if (err < 0) {
|
2014-05-08 13:58:12 +00:00
|
|
|
dev_warn(dev, "feed control interrupt is not available.\n");
|
2011-04-08 12:40:51 +00:00
|
|
|
goto err_irq;
|
|
|
|
}
|
|
|
|
|
2014-05-08 13:58:15 +00:00
|
|
|
pdata->busy = false;
|
2014-05-08 13:58:14 +00:00
|
|
|
pdata->variant = variant;
|
2011-04-08 12:40:51 +00:00
|
|
|
pdata->dev = dev;
|
|
|
|
platform_set_drvdata(pdev, pdata);
|
|
|
|
s5p_dev = pdata;
|
|
|
|
|
|
|
|
tasklet_init(&pdata->tasklet, s5p_tasklet_cb, (unsigned long)pdata);
|
|
|
|
crypto_init_queue(&pdata->queue, CRYPTO_QUEUE_LEN);
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(algs); i++) {
|
|
|
|
err = crypto_register_alg(&algs[i]);
|
|
|
|
if (err)
|
|
|
|
goto err_algs;
|
|
|
|
}
|
|
|
|
|
2016-01-11 11:45:50 +00:00
|
|
|
dev_info(dev, "s5p-sss driver registered\n");
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
err_algs:
|
2011-04-08 12:40:51 +00:00
|
|
|
dev_err(dev, "can't register '%s': %d\n", algs[i].cra_name, err);
|
|
|
|
|
|
|
|
for (j = 0; j < i; j++)
|
|
|
|
crypto_unregister_alg(&algs[j]);
|
|
|
|
|
|
|
|
tasklet_kill(&pdata->tasklet);
|
|
|
|
|
2016-03-22 01:58:23 +00:00
|
|
|
err_irq:
|
2014-05-08 13:58:15 +00:00
|
|
|
clk_disable_unprepare(pdata->clk);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
s5p_dev = NULL;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int s5p_aes_remove(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct s5p_aes_dev *pdata = platform_get_drvdata(pdev);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!pdata)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(algs); i++)
|
|
|
|
crypto_unregister_alg(&algs[i]);
|
|
|
|
|
|
|
|
tasklet_kill(&pdata->tasklet);
|
|
|
|
|
2014-05-08 13:58:15 +00:00
|
|
|
clk_disable_unprepare(pdata->clk);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
s5p_dev = NULL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct platform_driver s5p_aes_crypto = {
|
|
|
|
.probe = s5p_aes_probe,
|
|
|
|
.remove = s5p_aes_remove,
|
|
|
|
.driver = {
|
|
|
|
.name = "s5p-secss",
|
2014-05-08 13:58:13 +00:00
|
|
|
.of_match_table = s5p_sss_dt_match,
|
2011-04-08 12:40:51 +00:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2011-11-26 13:26:19 +00:00
|
|
|
module_platform_driver(s5p_aes_crypto);
|
2011-04-08 12:40:51 +00:00
|
|
|
|
|
|
|
MODULE_DESCRIPTION("S5PV210 AES hw acceleration support.");
|
|
|
|
MODULE_LICENSE("GPL v2");
|
|
|
|
MODULE_AUTHOR("Vladimir Zapolskiy <vzapolskiy@gmail.com>");
|