[PATCH 3/8] crypto: mediatek - make crypto request queue management more generic
This patch changes mtk_aes_handle_queue() to make it more generic.
The function argument is now a pointer to struct crypto_async_request,
which is the common base of struct ablkcipher_request and
struct aead_request.
Also this patch introduces struct mtk_aes_base_ctx which will be the
common base of all the transformation contexts.
Hence the very same queue will be used to manage both block cipher and
AEAD requests (such as gcm and authenc implemented in further patches).
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 75 --
drivers/crypto/mediatek/mtk-platform.h | 14 ---
2 files changed, 53 insertions(+), 36 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index b658cb9..7e5a8e0 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -73,9 +73,10 @@ struct mtk_aes_reqctx {
u64 mode;
};
-struct mtk_aes_ctx {
+struct mtk_aes_base_ctx {
struct mtk_cryp *cryp;
u32 keylen;
+ mtk_aes_fn start;
struct mtk_aes_ct ct;
dma_addr_t ct_dma;
@@ -86,6 +87,10 @@ struct mtk_aes_ctx {
u32 ct_size;
};
+struct mtk_aes_ctx {
+ struct mtk_aes_base_ctx base;
+};
+
struct mtk_aes_drv {
struct list_head dev_list;
/* Device list lock */
@@ -108,7 +113,7 @@ static inline void mtk_aes_write(struct mtk_cryp *cryp,
writel_relaxed(value, cryp->base + offset);
}
-static struct mtk_cryp *mtk_aes_find_dev(struct mtk_aes_ctx *ctx)
+static struct mtk_cryp *mtk_aes_find_dev(struct mtk_aes_base_ctx *ctx)
{
struct mtk_cryp *cryp = NULL;
struct mtk_cryp *tmp;
@@ -170,7 +175,8 @@ static int mtk_aes_info_map(struct mtk_cryp *cryp,
struct mtk_aes_rec *aes,
size_t len)
{
- struct mtk_aes_ctx *ctx = aes->ctx;
+ struct ablkcipher_request *req = ablkcipher_request_cast(aes->areq);
+ struct mtk_aes_base_ctx *ctx = aes->ctx;
ctx->ct_hdr = AES_CT_CTRL_HDR | cpu_to_le32(len);
ctx->ct.cmd[0] = AES_CMD0 | cpu_to_le32(len);
@@ -189,7 +195,7 @@ static int mtk_aes_info_map(struct mtk_cryp *cryp,
ctx->tfm.ctrl[0] |= AES_TFM_192BITS;
if (aes->flags & AES_FLAGS_CBC) {
- const u32 *iv = (const u32 *)aes->req->info;
+ const u32 *iv = (const u32 *)req->info;
u32 *iv_state = ctx->tfm.state + ctx->keylen;
int i;
@@ -299,11 +305,10 @@ static inline void mtk_aes_restore_sg(const struct
mtk_aes_dma *dma)
sg->length += dma->remainder;
}
-static int mtk_aes_map(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
+static int mtk_aes_map(struct mtk_cryp *cryp, struct mtk_aes_rec *aes,
+ struct scatterlist *src, struct scatterlist *dst,
+ size_t len)
{
- struct scatterlist *src = aes->req->src;
- struct scatterlist *dst = aes->req->dst;
- size_t len = aes->req->nbytes;
size_t padlen = 0;
bool src_aligned, dst_aligned;
@@ -366,18 +371,17 @@ static int mtk_aes_map(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
}
static int mtk_aes_handle_queue(struct mtk_cryp *cryp, u8 id,
- struct ablkcipher_request *req)
+ struct crypto_async_request *new_areq)
{
struct mtk_aes_rec *aes = cryp->aes[id];
struct crypto_async_request *areq, *backlog;
- struct mtk_aes_reqctx *rctx;
- struct mtk_aes_ctx *ctx;
+ struct mtk_aes_base_ctx *ctx;
unsigned long flags;
- int err, ret = 0;
+ int ret = 0;
spin_lock_irqsave(&aes->lock, flags);
- if (req)
- ret = ablkcipher_enqueue_request(&aes->queue, req);
+ if (new_areq)
+ ret = crypto_enqueue_request(&aes->queue, new_areq);
if (aes->flags & AES_FLAGS_BUSY) {
spin_unlock_irqrestore(&aes->lock, flags);
return ret;
@@ -394,16 +398,25 @@ static int mtk_aes_handle_queue(struct mtk_cryp *cryp, u8
id,
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
- req = ablkcipher_request_cast(areq);
- ctx = crypto_ablkcipher_ctx(crypto_ablkcipher_reqtfm(req));
+ ctx = crypto_tfm_ctx(areq->tfm);
+
+ aes->areq = areq;
+ aes->ctx = ctx;
+
+ return ctx->start(cryp, aes);
+}
+
+static int mtk_aes_start(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
+{
+ struct ablkcipher_request *req = ablkcipher_request_cast(aes->areq);
+ struct mtk_aes_reqctx *rctx = ablkcipher_request_ctx(req);
+ int err;
+
rctx = ablkcipher_request_ctx(req);
rctx->mode &= AES_FLAGS_MODE_MSK;
- /* Assign new request to device */
- aes->req = req;
- aes->ctx = ctx;
aes->flags = (aes->flags & ~AES_FLAGS_MODE_MSK) | rctx->mode;
- err = mtk_aes_map(cry
[PATCH 7/8] crypto: mediatek - add support to CTR mode
This patch adds support to the CTR mode.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 151 --
1 file changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 5e7c3ce..bb5b4ff 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -23,8 +23,10 @@
/* AES command token size */
#define AES_CT_SIZE_ECB2
#define AES_CT_SIZE_CBC3
+#define AES_CT_SIZE_CTR3
#define AES_CT_CTRL_HDRcpu_to_le32(0x0022)
-/* AES-CBC/ECB command token */
+
+/* AES-CBC/ECB/CTR command token */
#define AES_CMD0 cpu_to_le32(0x0500)
#define AES_CMD1 cpu_to_le32(0x2d06)
#define AES_CMD2 cpu_to_le32(0xe4a63806)
@@ -39,13 +41,15 @@
/* AES transform information word 1 fields */
#define AES_TFM_ECBcpu_to_le32(0x0 << 0)
#define AES_TFM_CBCcpu_to_le32(0x1 << 0)
-#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5)
+#define AES_TFM_CTR_LOAD cpu_to_le32(0x6 << 0) /* load/reuse counter */
+#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5) /* using IV 0-3
*/
/* AES flags */
#define AES_FLAGS_ECB BIT(0)
#define AES_FLAGS_CBC BIT(1)
-#define AES_FLAGS_ENCRYPT BIT(2)
-#define AES_FLAGS_BUSY BIT(3)
+#define AES_FLAGS_CTR BIT(2)
+#define AES_FLAGS_ENCRYPT BIT(3)
+#define AES_FLAGS_BUSY BIT(4)
/**
* Command token(CT) is a set of hardware instructions that
@@ -90,6 +94,15 @@ struct mtk_aes_ctx {
struct mtk_aes_base_ctx base;
};
+struct mtk_aes_ctr_ctx {
+ struct mtk_aes_base_ctx base;
+
+ u32 iv[AES_BLOCK_SIZE / sizeof(u32)];
+ size_t offset;
+ struct scatterlist src[2];
+ struct scatterlist dst[2];
+};
+
struct mtk_aes_drv {
struct list_head dev_list;
/* Device list lock */
@@ -332,7 +345,7 @@ static int mtk_aes_map(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
return -EINVAL;
}
-/* Initialize transform information of CBC/ECB mode */
+/* Initialize transform information of CBC/ECB/CTR mode */
static void mtk_aes_info_init(struct mtk_cryp *cryp, struct mtk_aes_rec *aes,
size_t len)
{
@@ -374,6 +387,13 @@ static void mtk_aes_info_init(struct mtk_cryp *cryp,
struct mtk_aes_rec *aes,
ctx->tfm.ctrl[1] = AES_TFM_ECB;
ctx->ct_size = AES_CT_SIZE_ECB;
+ } else if (aes->flags & AES_FLAGS_CTR) {
+ ctx->tfm.ctrl[0] |= AES_TFM_SIZE(ctx->keylen +
+ SIZE_IN_WORDS(AES_BLOCK_SIZE));
+ ctx->tfm.ctrl[1] = AES_TFM_CTR_LOAD | AES_TFM_FULL_IV;
+
+ ctx->ct.cmd[2] = AES_CMD2;
+ ctx->ct_size = AES_CT_SIZE_CTR;
}
}
@@ -479,6 +499,80 @@ static int mtk_aes_start(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
return mtk_aes_dma(cryp, aes, req->src, req->dst, req->nbytes);
}
+static inline struct mtk_aes_ctr_ctx *
+mtk_aes_ctr_ctx_cast(struct mtk_aes_base_ctx *ctx)
+{
+ return container_of(ctx, struct mtk_aes_ctr_ctx, base);
+}
+
+static int mtk_aes_ctr_transfer(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
+{
+ struct mtk_aes_base_ctx *ctx = aes->ctx;
+ struct mtk_aes_ctr_ctx *cctx = mtk_aes_ctr_ctx_cast(ctx);
+ struct ablkcipher_request *req = ablkcipher_request_cast(aes->areq);
+ struct scatterlist *src, *dst;
+ int i;
+ u32 start, end, ctr, blocks, *iv_state;
+ size_t datalen;
+ bool fragmented = false;
+
+ /* Check for transfer completion. */
+ cctx->offset += aes->total;
+ if (cctx->offset >= req->nbytes)
+ return mtk_aes_complete(cryp, aes);
+
+ /* Compute data length. */
+ datalen = req->nbytes - cctx->offset;
+ blocks = DIV_ROUND_UP(datalen, AES_BLOCK_SIZE);
+ ctr = be32_to_cpu(cctx->iv[3]);
+
+ /* Check 32bit counter overflow. */
+ start = ctr;
+ end = start + blocks - 1;
+ if (end < start) {
+ ctr |= 0x;
+ datalen = AES_BLOCK_SIZE * -start;
+ fragmented = true;
+ }
+
+ /* Jump to offset. */
+ src = scatterwalk_ffwd(cctx->src, req->src, cctx->offset);
+ dst = ((req->src == req->dst) ? src :
+ scatterwalk_ffwd(cctx->dst, req->dst, cctx->offset));
+
+ /* Write IVs into transform state buffer. */
+ iv_state = ctx->tfm.state + ctx->keylen;
+ for (i = 0; i < SIZE_IN_WORDS(AES_BLOCK_SIZE); i++)
+ iv_state[i] = cpu_to_le32(cctx->iv[i]);
+
+ if (unlikely(fragmented)) {
+ /*
+* Increment the counter manually to cope with the hardware
+* counter overflow.
+*/
+ cctx->iv[3] = cpu_to_be32(ctr);
+ crypto_inc((u8
[PATCH 1/8] crypto: mediatek - move HW control data to transformation context
This patch moves hardware control block members from
mtk_*_rec to transformation context and refines related
definition. This makes operational context to manage its
own control information easily for each DMA transfer.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 144 -
drivers/crypto/mediatek/mtk-platform.h | 26 +-
drivers/crypto/mediatek/mtk-sha.c | 101 ---
3 files changed, 126 insertions(+), 145 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 1370cab..126b93c 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -20,23 +20,25 @@
#define AES_BUF_SIZE ((PAGE_SIZE << AES_BUF_ORDER) \
& ~(AES_BLOCK_SIZE - 1))
-/* AES command token */
+/* AES command token size */
#define AES_CT_SIZE_ECB2
#define AES_CT_SIZE_CBC3
#define AES_CT_CTRL_HDRcpu_to_le32(0x0022)
-#define AES_COMMAND0 cpu_to_le32(0x0500)
-#define AES_COMMAND1 cpu_to_le32(0x2d06)
-#define AES_COMMAND2 cpu_to_le32(0xe4a63806)
-
-/* AES transform information */
-#define AES_TFM_ECBcpu_to_le32(0x0 << 0)
-#define AES_TFM_CBCcpu_to_le32(0x1 << 0)
-#define AES_TFM_DECRYPTcpu_to_le32(0x5 << 0)
-#define AES_TFM_ENCRYPTcpu_to_le32(0x4 << 0)
+/* AES-CBC/ECB command token */
+#define AES_CMD0 cpu_to_le32(0x0500)
+#define AES_CMD1 cpu_to_le32(0x2d06)
+#define AES_CMD2 cpu_to_le32(0xe4a63806)
+
+/* AES transform information word 0 fields */
+#define AES_TFM_BASIC_OUT cpu_to_le32(0x4 << 0)
+#define AES_TFM_BASIC_IN cpu_to_le32(0x5 << 0)
#define AES_TFM_SIZE(x)cpu_to_le32((x) << 8)
#define AES_TFM_128BITScpu_to_le32(0xb << 16)
#define AES_TFM_192BITScpu_to_le32(0xd << 16)
#define AES_TFM_256BITScpu_to_le32(0xf << 16)
+/* AES transform information word 1 fields */
+#define AES_TFM_ECBcpu_to_le32(0x0 << 0)
+#define AES_TFM_CBCcpu_to_le32(0x1 << 0)
#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5)
/* AES flags */
@@ -47,47 +49,41 @@
#define AES_FLAGS_BUSY BIT(3)
/**
- * mtk_aes_ct is a set of hardware instructions(command token)
- * that are used to control engine's processing flow of AES.
+ * Command token(CT) is a set of hardware instructions that
+ * are used to control engine's processing flow of AES.
+ *
+ * Transform information(TFM) is used to define AES state and
+ * contains all keys and initial vectors.
+ *
+ * The engine requires CT and TFM to do:
+ * - Commands decoding and control of the engine's data path.
+ * - Coordinating hardware data fetch and store operations.
+ * - Result token construction and output.
*/
struct mtk_aes_ct {
- __le32 ct_ctrl0;
- __le32 ct_ctrl1;
- __le32 ct_ctrl2;
+ __le32 cmd[AES_CT_SIZE_CBC];
};
-/**
- * mtk_aes_tfm is used to define AES transform state
- * and contains all keys and initial vectors.
- */
struct mtk_aes_tfm {
- __le32 tfm_ctrl0;
- __le32 tfm_ctrl1;
+ __le32 ctrl[2];
__le32 state[SIZE_IN_WORDS(AES_KEYSIZE_256 + AES_BLOCK_SIZE)];
};
-/**
- * mtk_aes_info consists of command token and transform state of AES,
- * which should be encapsulated in command and result descriptors.
- *
- * The engine requires this information to do:
- * - Commands decoding and control of the engine's data path.
- * - Coordinating hardware data fetch and store operations.
- * - Result token construction and output.
- */
-struct mtk_aes_info {
- struct mtk_aes_ct ct;
- struct mtk_aes_tfm tfm;
-};
-
struct mtk_aes_reqctx {
u64 mode;
};
struct mtk_aes_ctx {
struct mtk_cryp *cryp;
- struct mtk_aes_info info;
u32 keylen;
+
+ struct mtk_aes_ct ct;
+ dma_addr_t ct_dma;
+ struct mtk_aes_tfm tfm;
+ dma_addr_t tfm_dma;
+
+ __le32 ct_hdr;
+ u32 ct_size;
};
struct mtk_aes_drv {
@@ -174,57 +170,57 @@ static int mtk_aes_info_map(struct mtk_cryp *cryp,
struct mtk_aes_rec *aes,
size_t len)
{
- struct mtk_aes_ctx *ctx = crypto_ablkcipher_ctx(
- crypto_ablkcipher_reqtfm(aes->req));
- struct mtk_aes_info *info = aes->info;
- struct mtk_aes_ct *ct = &info->ct;
- struct mtk_aes_tfm *tfm = &info->tfm;
+ struct mtk_aes_ctx *ctx = aes->ctx;
- aes->ct_hdr = AES_CT_CTRL_HDR | cpu_to_le32(len);
+ ctx->ct_hdr = AES_CT_CTRL_HDR | cpu_to_le32(len);
+ ctx->ct.cmd[0] = AES_CMD0 | cpu_to_le32(len);
+ ctx->ct.cmd[1] = AES_CMD1;
if (aes->flags & AES_FLAGS_ENCRYPT)
- tfm->tfm_ctrl0 = AES_TFM_ENCRYPT;
+ ctx->tfm.ct
[PATCH 0/8] update mediatek crypto driver
Hi, This series of patches is a global rework of the mtk driver. Fix bug - incomplete DMA data transfer when SG buffer dst.len != src.len It also updates some part of the code to make them more generic. For instance the crypto request queue management supports both async block cipher and AEAD requests, which allows us to add support the the GCM mode. GMAC mode is not supported yet. Current implementation was validated using the tcrypt module running modes: - 10: ecb(aes), cbc(aes), ctr(aes), rfc3686(ctr(aes)) - 35: gcm(aes) - 2,6,11,12: sha1, sha2 family tcrypt speed test was run with modes: - 211: rfc4106(gcm(aes)), gcm(aes) - 500: ecb(aes), cbc(aes), ctr(aes), rfc3686(ctr(aes)) - 403 ~ 406: sha1, sha2 family IxChariot multiple pairs throughput 24 hours test: - IPSec VPN - MACSec Ryder Lee (8): crypto: mediatek - move HW control data to transformation context crypto: mediatek - fix incorrect data transfer result crypto: mediatek - make crypto request queue management more generic crypto: mediatek - rework crypto request completion crypto: mediatek - regroup functions by usage crypto: mediatek - fix typo and indentation crypto: mediatek - add support to CTR mode crypto: mediatek - add support to GCM mode drivers/crypto/Kconfig |2 + drivers/crypto/mediatek/mtk-aes.c | 1026 drivers/crypto/mediatek/mtk-platform.h | 47 +- drivers/crypto/mediatek/mtk-sha.c | 170 +++--- 4 files changed, 886 insertions(+), 359 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] crypto: mediatek - rework crypto request completion
This patch introduces a new callback 'resume' in the struct mtk_aes_rec.
This callback is run to resume/complete the processing of the crypto
request when woken up by AES interrupts when DMA completion.
This callback will help implementing the GCM mode support in further
patches.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 25 +
drivers/crypto/mediatek/mtk-platform.h | 3 +++
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 7e5a8e0..9c4e468 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -406,6 +406,15 @@ static int mtk_aes_handle_queue(struct mtk_cryp *cryp, u8
id,
return ctx->start(cryp, aes);
}
+static int mtk_aes_complete(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
+{
+ aes->flags &= ~AES_FLAGS_BUSY;
+ aes->areq->complete(aes->areq, 0);
+
+ /* Handle new request */
+ return mtk_aes_handle_queue(cryp, aes->id, NULL);
+}
+
static int mtk_aes_start(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
{
struct ablkcipher_request *req = ablkcipher_request_cast(aes->areq);
@@ -416,6 +425,8 @@ static int mtk_aes_start(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
rctx->mode &= AES_FLAGS_MODE_MSK;
aes->flags = (aes->flags & ~AES_FLAGS_MODE_MSK) | rctx->mode;
+ aes->resume = mtk_aes_complete;
+
err = mtk_aes_map(cryp, aes, req->src, req->dst, req->nbytes);
if (err)
return err;
@@ -458,16 +469,6 @@ static void mtk_aes_unmap(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
aes->buf, aes->total);
}
-static inline void mtk_aes_complete(struct mtk_cryp *cryp,
- struct mtk_aes_rec *aes)
-{
- aes->flags &= ~AES_FLAGS_BUSY;
- aes->areq->complete(aes->areq, 0);
-
- /* Handle new request */
- mtk_aes_handle_queue(cryp, aes->id, NULL);
-}
-
/* Check and set the AES key to transform state buffer */
static int mtk_aes_setkey(struct crypto_ablkcipher *tfm,
const u8 *key, u32 keylen)
@@ -591,7 +592,7 @@ static void mtk_aes_enc_task(unsigned long data)
struct mtk_aes_rec *aes = cryp->aes[0];
mtk_aes_unmap(cryp, aes);
- mtk_aes_complete(cryp, aes);
+ aes->resume(cryp, aes);
}
static void mtk_aes_dec_task(unsigned long data)
@@ -600,7 +601,7 @@ static void mtk_aes_dec_task(unsigned long data)
struct mtk_aes_rec *aes = cryp->aes[1];
mtk_aes_unmap(cryp, aes);
- mtk_aes_complete(cryp, aes);
+ aes->resume(cryp, aes);
}
static irqreturn_t mtk_aes_enc_irq(int irq, void *dev_id)
diff --git a/drivers/crypto/mediatek/mtk-platform.h
b/drivers/crypto/mediatek/mtk-platform.h
index 9f5210c..36d166b 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -131,6 +131,7 @@ struct mtk_aes_dma {
* @dst: the structure that holds destination sg list info
* @aligned_sg:the scatter list is use to alignment
* @real_dst: pointer to the destination sg list
+ * @resume:pointer to resume function
* @total: request buffer length
* @buf: pointer to page buffer
* @id:record identification
@@ -150,6 +151,8 @@ struct mtk_aes_rec {
struct scatterlist aligned_sg;
struct scatterlist *real_dst;
+ mtk_aes_fn resume;
+
size_t total;
void *buf;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] crypto: mediatek - add support to GCM mode
This patch adds support to the GCM mode.
Signed-off-by: Ryder Lee
---
drivers/crypto/Kconfig | 2 +
drivers/crypto/mediatek/mtk-aes.c | 369 -
drivers/crypto/mediatek/mtk-platform.h | 2 +
3 files changed, 369 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ee5057a..bf7da55 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -557,7 +557,9 @@ config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
+ select CRYPTO_AEAD
select CRYPTO_BLKCIPHER
+ select CRYPTO_CTR
select CRYPTO_SHA1
select CRYPTO_SHA256
select CRYPTO_SHA512
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index bb5b4ff..3a47cdb 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -24,16 +24,28 @@
#define AES_CT_SIZE_ECB2
#define AES_CT_SIZE_CBC3
#define AES_CT_SIZE_CTR3
+#define AES_CT_SIZE_GCM_OUT5
+#define AES_CT_SIZE_GCM_IN 6
#define AES_CT_CTRL_HDRcpu_to_le32(0x0022)
/* AES-CBC/ECB/CTR command token */
#define AES_CMD0 cpu_to_le32(0x0500)
#define AES_CMD1 cpu_to_le32(0x2d06)
#define AES_CMD2 cpu_to_le32(0xe4a63806)
+/* AES-GCM command token */
+#define AES_GCM_CMD0 cpu_to_le32(0x0b00)
+#define AES_GCM_CMD1 cpu_to_le32(0xa080)
+#define AES_GCM_CMD2 cpu_to_le32(0x2510)
+#define AES_GCM_CMD3 cpu_to_le32(0x0f02)
+#define AES_GCM_CMD4 cpu_to_le32(0x21e6)
+#define AES_GCM_CMD5 cpu_to_le32(0x40e6)
+#define AES_GCM_CMD6 cpu_to_le32(0xd007)
/* AES transform information word 0 fields */
#define AES_TFM_BASIC_OUT cpu_to_le32(0x4 << 0)
#define AES_TFM_BASIC_IN cpu_to_le32(0x5 << 0)
+#define AES_TFM_GCM_OUTcpu_to_le32(0x6 << 0)
+#define AES_TFM_GCM_IN cpu_to_le32(0xf << 0)
#define AES_TFM_SIZE(x)cpu_to_le32((x) << 8)
#define AES_TFM_128BITScpu_to_le32(0xb << 16)
#define AES_TFM_192BITScpu_to_le32(0xd << 16)
@@ -41,15 +53,22 @@
/* AES transform information word 1 fields */
#define AES_TFM_ECBcpu_to_le32(0x0 << 0)
#define AES_TFM_CBCcpu_to_le32(0x1 << 0)
+#define AES_TFM_CTR_INIT cpu_to_le32(0x2 << 0) /* init counter to 1 */
#define AES_TFM_CTR_LOAD cpu_to_le32(0x6 << 0) /* load/reuse counter */
+#define AES_TFM_3IVcpu_to_le32(0x7 << 5) /* using IV 0-2 */
#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5) /* using IV 0-3
*/
+#define AES_TFM_IV_CTR_MODEcpu_to_le32(0x1 << 10)
+#define AES_TFM_ENC_HASH cpu_to_le32(0x1 << 17)
+#define AES_TFM_GHASH_DIG cpu_to_le32(0x2 << 21)
+#define AES_TFM_GHASH cpu_to_le32(0x4 << 23)
/* AES flags */
#define AES_FLAGS_ECB BIT(0)
#define AES_FLAGS_CBC BIT(1)
#define AES_FLAGS_CTR BIT(2)
-#define AES_FLAGS_ENCRYPT BIT(3)
-#define AES_FLAGS_BUSY BIT(4)
+#define AES_FLAGS_GCM BIT(3)
+#define AES_FLAGS_ENCRYPT BIT(4)
+#define AES_FLAGS_BUSY BIT(5)
/**
* Command token(CT) is a set of hardware instructions that
@@ -62,14 +81,23 @@
* - Commands decoding and control of the engine's data path.
* - Coordinating hardware data fetch and store operations.
* - Result token construction and output.
+ *
+ * Memory map of GCM's TFM:
+ * /---\
+ * | AES KEY | 128/196/256 bits
+ * |---|
+ * | HASH KEY | a string 128 zero bits encrypted using the block cipher
+ * |---|
+ * |IVs| 4 * 4 bytes
+ * \---/
*/
struct mtk_aes_ct {
- __le32 cmd[AES_CT_SIZE_CBC];
+ __le32 cmd[AES_CT_SIZE_GCM_IN];
};
struct mtk_aes_tfm {
__le32 ctrl[2];
- __le32 state[SIZE_IN_WORDS(AES_KEYSIZE_256 + AES_BLOCK_SIZE)];
+ __le32 state[SIZE_IN_WORDS(AES_KEYSIZE_256 + AES_BLOCK_SIZE * 2)];
};
struct mtk_aes_reqctx {
@@ -103,6 +131,20 @@ struct mtk_aes_ctr_ctx {
struct scatterlist dst[2];
};
+struct mtk_aes_gcm_ctx {
+ struct mtk_aes_base_ctx base;
+
+ u32 authsize;
+ size_t textlen;
+
+ struct crypto_skcipher *ctr;
+};
+
+struct mtk_aes_gcm_setkey_result {
+ int err;
+ struct completion completion;
+};
+
struct mtk_aes_drv {
struct list_head dev_list;
/* Device list lock */
@@ -251,6 +293,10 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
}
res->hdr |= MTK_DESC_LAST;
+ /* Prepare enough space for authenticated tag */
+ if (aes->flags & AES_FLAGS_GCM)
+ res->hdr += AES_BLOCK_SIZE;
+
/*
* Make sure
[PATCH 6/8] crypto: mediatek - fix typo and indentation
Dummy patch to fix typo and indentation.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 90 +-
drivers/crypto/mediatek/mtk-platform.h | 2 +-
drivers/crypto/mediatek/mtk-sha.c | 40 +++
3 files changed, 63 insertions(+), 69 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index b5946e9..5e7c3ce 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -314,8 +314,8 @@ static int mtk_aes_map(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
aes->dst.sg_len = dma_map_sg(cryp->dev, aes->dst.sg,
aes->dst.nents, DMA_FROM_DEVICE);
if (unlikely(!aes->dst.sg_len)) {
- dma_unmap_sg(cryp->dev, aes->src.sg,
-aes->src.nents, DMA_TO_DEVICE);
+ dma_unmap_sg(cryp->dev, aes->src.sg, aes->src.nents,
+DMA_TO_DEVICE);
goto sg_map_err;
}
}
@@ -484,7 +484,7 @@ static int mtk_aes_setkey(struct crypto_ablkcipher *tfm,
const u8 *key, u32 keylen)
{
struct mtk_aes_base_ctx *ctx = crypto_ablkcipher_ctx(tfm);
- const u32 *key_tmp = (const u32 *)key;
+ const u32 *aes_key = (const u32 *)key;
u32 *key_state = ctx->tfm.state;
int i;
@@ -498,7 +498,7 @@ static int mtk_aes_setkey(struct crypto_ablkcipher *tfm,
ctx->keylen = SIZE_IN_WORDS(keylen);
for (i = 0; i < ctx->keylen; i++)
- key_state[i] = cpu_to_le32(key_tmp[i]);
+ key_state[i] = cpu_to_le32(aes_key[i]);
return 0;
}
@@ -512,26 +512,26 @@ static int mtk_aes_crypt(struct ablkcipher_request *req,
u64 mode)
rctx = ablkcipher_request_ctx(req);
rctx->mode = mode;
- return mtk_aes_handle_queue(ctx->cryp,
- !(mode & AES_FLAGS_ENCRYPT), &req->base);
+ return mtk_aes_handle_queue(ctx->cryp, !(mode & AES_FLAGS_ENCRYPT),
+ &req->base);
}
-static int mtk_ecb_encrypt(struct ablkcipher_request *req)
+static int mtk_aes_ecb_encrypt(struct ablkcipher_request *req)
{
return mtk_aes_crypt(req, AES_FLAGS_ENCRYPT | AES_FLAGS_ECB);
}
-static int mtk_ecb_decrypt(struct ablkcipher_request *req)
+static int mtk_aes_ecb_decrypt(struct ablkcipher_request *req)
{
return mtk_aes_crypt(req, AES_FLAGS_ECB);
}
-static int mtk_cbc_encrypt(struct ablkcipher_request *req)
+static int mtk_aes_cbc_encrypt(struct ablkcipher_request *req)
{
return mtk_aes_crypt(req, AES_FLAGS_ENCRYPT | AES_FLAGS_CBC);
}
-static int mtk_cbc_decrypt(struct ablkcipher_request *req)
+static int mtk_aes_cbc_decrypt(struct ablkcipher_request *req)
{
return mtk_aes_crypt(req, AES_FLAGS_CBC);
}
@@ -554,44 +554,44 @@ static int mtk_aes_cra_init(struct crypto_tfm *tfm)
static struct crypto_alg aes_algs[] = {
{
- .cra_name = "cbc(aes)",
- .cra_driver_name= "cbc-aes-mtk",
- .cra_priority = 400,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
- CRYPTO_ALG_ASYNC,
- .cra_init = mtk_aes_cra_init,
- .cra_blocksize = AES_BLOCK_SIZE,
- .cra_ctxsize= sizeof(struct mtk_aes_ctx),
- .cra_alignmask = 15,
- .cra_type = &crypto_ablkcipher_type,
- .cra_module = THIS_MODULE,
- .cra_u.ablkcipher = {
- .min_keysize= AES_MIN_KEY_SIZE,
- .max_keysize= AES_MAX_KEY_SIZE,
- .setkey = mtk_aes_setkey,
- .encrypt= mtk_cbc_encrypt,
- .decrypt= mtk_cbc_decrypt,
- .ivsize = AES_BLOCK_SIZE,
+ .cra_name = "cbc(aes)",
+ .cra_driver_name= "cbc-aes-mtk",
+ .cra_priority = 400,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC,
+ .cra_init = mtk_aes_cra_init,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct mtk_aes_ctx),
+ .cra_alignmask = 0xf,
+ .cra_type = &crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_u.ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = mtk_aes_setkey,
+ .encrypt= mtk_aes_cbc_encrypt,
+ .decrypt= mtk_aes_cbc_decrypt,
+ .ivsize = AES_BLOCK_SIZE,
}
[PATCH 2/8] crypto: mediatek - fix incorrect data transfer result
This patch fixes mtk_aes_xmit() data transfer bug.
The original function uses the same loop and ring->pos
to handle both command and result descriptors. But this
produces incomplete results when src.sg_len != dst.sg_len.
To solve the problem, we splits the descriptors into different
loops and uses cmd_pos and res_pos to record them respectively.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 44 --
drivers/crypto/mediatek/mtk-platform.h | 6 +++--
drivers/crypto/mediatek/mtk-sha.c | 29 --
3 files changed, 47 insertions(+), 32 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 126b93c..b658cb9 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -225,29 +225,25 @@ static int mtk_aes_info_map(struct mtk_cryp *cryp,
return 0;
}
+/*
+ * Write descriptors for processing. This will configure the engine, load
+ * the transform information and then start the packet processing.
+ */
static int mtk_aes_xmit(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
{
struct mtk_ring *ring = cryp->ring[aes->id];
struct mtk_desc *cmd = NULL, *res = NULL;
- struct scatterlist *ssg, *dsg;
- u32 len = aes->src.sg_len;
+ struct scatterlist *ssg = aes->src.sg, *dsg = aes->dst.sg;
+ u32 slen = aes->src.sg_len, dlen = aes->dst.sg_len;
int nents;
- /* Fill in the command/result descriptors */
- for (nents = 0; nents < len; ++nents) {
- ssg = &aes->src.sg[nents];
- dsg = &aes->dst.sg[nents];
-
- cmd = ring->cmd_base + ring->pos;
+ /* Write command descriptors */
+ for (nents = 0; nents < slen; ++nents, ssg = sg_next(ssg)) {
+ cmd = ring->cmd_base + ring->cmd_pos;
cmd->hdr = MTK_DESC_BUF_LEN(ssg->length);
cmd->buf = cpu_to_le32(sg_dma_address(ssg));
- res = ring->res_base + ring->pos;
- res->hdr = MTK_DESC_BUF_LEN(dsg->length);
- res->buf = cpu_to_le32(sg_dma_address(dsg));
-
if (nents == 0) {
- res->hdr |= MTK_DESC_FIRST;
cmd->hdr |= MTK_DESC_FIRST |
MTK_DESC_CT_LEN(aes->ctx->ct_size);
cmd->ct = cpu_to_le32(aes->ctx->ct_dma);
@@ -255,11 +251,23 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
cmd->tfm = cpu_to_le32(aes->ctx->tfm_dma);
}
- if (++ring->pos == MTK_DESC_NUM)
- ring->pos = 0;
+ if (++ring->cmd_pos == MTK_DESC_NUM)
+ ring->cmd_pos = 0;
}
-
cmd->hdr |= MTK_DESC_LAST;
+
+ /* Prepare result descriptors */
+ for (nents = 0; nents < dlen; ++nents, dsg = sg_next(dsg)) {
+ res = ring->res_base + ring->res_pos;
+ res->hdr = MTK_DESC_BUF_LEN(dsg->length);
+ res->buf = cpu_to_le32(sg_dma_address(dsg));
+
+ if (nents == 0)
+ res->hdr |= MTK_DESC_FIRST;
+
+ if (++ring->res_pos == MTK_DESC_NUM)
+ ring->res_pos = 0;
+ }
res->hdr |= MTK_DESC_LAST;
/*
@@ -268,8 +276,8 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
*/
wmb();
/* Start DMA transfer */
- mtk_aes_write(cryp, RDR_PREP_COUNT(aes->id), MTK_DESC_CNT(len));
- mtk_aes_write(cryp, CDR_PREP_COUNT(aes->id), MTK_DESC_CNT(len));
+ mtk_aes_write(cryp, RDR_PREP_COUNT(aes->id), MTK_DESC_CNT(dlen));
+ mtk_aes_write(cryp, CDR_PREP_COUNT(aes->id), MTK_DESC_CNT(slen));
return -EINPROGRESS;
}
diff --git a/drivers/crypto/mediatek/mtk-platform.h
b/drivers/crypto/mediatek/mtk-platform.h
index 1516786..8c50b74 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -83,9 +83,10 @@ struct mtk_desc {
* struct mtk_ring - Descriptor ring
* @cmd_base: pointer to command descriptor ring base
* @cmd_dma: DMA address of command descriptor ring
+ * @cmd_pos: current position in the command descriptor ring
* @res_base: pointer to result descriptor ring base
* @res_dma: DMA address of result descriptor ring
- * @pos: current position in the ring
+ * @res_pos: current position in the result descriptor ring
*
* A descriptor ring is a circular buffer that is used to manage
* one or more descriptors. There are two type of descriptor rings;
@@ -94,9 +95,10 @@ struct mtk_desc {
struct mtk_ring {
struct mtk_desc *cmd_base;
dma_addr_t cmd_dma;
+ u32 cmd_pos;
struct mtk_desc *res_base;
dma_addr_t res_dma;
- u32 pos;
+ u32 res_pos;
};
/**
diff --git a/drivers/crypto/mediatek/mtk-sha.c
b/drivers/cr
[PATCH 5/8] crypto: mediatek - regroup functions by usage
This patch only regroup functions by usage.
This will help to integrate the GCM support patch later by
adjusting some shared code section, such as common code which
will be reused by GCM, AES mode setting, and DMA transfer.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 272 --
1 file changed, 141 insertions(+), 131 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 9c4e468..b5946e9 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -42,7 +42,6 @@
#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5)
/* AES flags */
-#define AES_FLAGS_MODE_MSK 0x7
#define AES_FLAGS_ECB BIT(0)
#define AES_FLAGS_CBC BIT(1)
#define AES_FLAGS_ENCRYPT BIT(2)
@@ -170,65 +169,28 @@ static bool mtk_aes_check_aligned(struct scatterlist *sg,
size_t len,
return false;
}
-/* Initialize and map transform information of AES */
-static int mtk_aes_info_map(struct mtk_cryp *cryp,
- struct mtk_aes_rec *aes,
- size_t len)
+static inline void mtk_aes_set_mode(struct mtk_aes_rec *aes,
+ const struct mtk_aes_reqctx *rctx)
{
- struct ablkcipher_request *req = ablkcipher_request_cast(aes->areq);
- struct mtk_aes_base_ctx *ctx = aes->ctx;
-
- ctx->ct_hdr = AES_CT_CTRL_HDR | cpu_to_le32(len);
- ctx->ct.cmd[0] = AES_CMD0 | cpu_to_le32(len);
- ctx->ct.cmd[1] = AES_CMD1;
-
- if (aes->flags & AES_FLAGS_ENCRYPT)
- ctx->tfm.ctrl[0] = AES_TFM_BASIC_OUT;
- else
- ctx->tfm.ctrl[0] = AES_TFM_BASIC_IN;
-
- if (ctx->keylen == SIZE_IN_WORDS(AES_KEYSIZE_128))
- ctx->tfm.ctrl[0] |= AES_TFM_128BITS;
- else if (ctx->keylen == SIZE_IN_WORDS(AES_KEYSIZE_256))
- ctx->tfm.ctrl[0] |= AES_TFM_256BITS;
- else if (ctx->keylen == SIZE_IN_WORDS(AES_KEYSIZE_192))
- ctx->tfm.ctrl[0] |= AES_TFM_192BITS;
-
- if (aes->flags & AES_FLAGS_CBC) {
- const u32 *iv = (const u32 *)req->info;
- u32 *iv_state = ctx->tfm.state + ctx->keylen;
- int i;
-
- ctx->tfm.ctrl[0] |= AES_TFM_SIZE(ctx->keylen +
- SIZE_IN_WORDS(AES_BLOCK_SIZE));
- ctx->tfm.ctrl[1] = AES_TFM_CBC | AES_TFM_FULL_IV;
-
- for (i = 0; i < SIZE_IN_WORDS(AES_BLOCK_SIZE); i++)
- iv_state[i] = cpu_to_le32(iv[i]);
+ /* Clear all but persistent flags and set request flags. */
+ aes->flags = (aes->flags & AES_FLAGS_BUSY) | rctx->mode;
+}
- ctx->ct.cmd[2] = AES_CMD2;
- ctx->ct_size = AES_CT_SIZE_CBC;
- } else if (aes->flags & AES_FLAGS_ECB) {
- ctx->tfm.ctrl[0] |= AES_TFM_SIZE(ctx->keylen);
- ctx->tfm.ctrl[1] = AES_TFM_ECB;
+static inline void mtk_aes_restore_sg(const struct mtk_aes_dma *dma)
+{
+ struct scatterlist *sg = dma->sg;
+ int nents = dma->nents;
- ctx->ct_size = AES_CT_SIZE_ECB;
- }
+ if (!dma->remainder)
+ return;
- ctx->ct_dma = dma_map_single(cryp->dev, &ctx->ct, sizeof(ctx->ct),
-DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(cryp->dev, ctx->ct_dma)))
- return -EINVAL;
+ while (--nents > 0 && sg)
+ sg = sg_next(sg);
- ctx->tfm_dma = dma_map_single(cryp->dev, &ctx->tfm, sizeof(ctx->tfm),
- DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(cryp->dev, ctx->tfm_dma))) {
- dma_unmap_single(cryp->dev, ctx->tfm_dma, sizeof(ctx->tfm),
-DMA_TO_DEVICE);
- return -EINVAL;
- }
+ if (!sg)
+ return;
- return 0;
+ sg->length += dma->remainder;
}
/*
@@ -288,24 +250,134 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct
mtk_aes_rec *aes)
return -EINPROGRESS;
}
-static inline void mtk_aes_restore_sg(const struct mtk_aes_dma *dma)
+static void mtk_aes_unmap(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
{
- struct scatterlist *sg = dma->sg;
- int nents = dma->nents;
+ struct mtk_aes_base_ctx *ctx = aes->ctx;
- if (!dma->remainder)
- return;
+ dma_unmap_single(cryp->dev, ctx->ct_dma, sizeof(ctx->ct),
+DMA_TO_DEVICE);
+ dma_unmap_single(cryp->dev, ctx->tfm_dma, sizeof(ctx->tfm),
+DMA_TO_DEVICE);
- while (--nents > 0 && sg)
- sg = sg_next(sg);
+ if (aes->src.sg == aes->dst.sg) {
+ dma_unmap_sg(cryp->dev, aes->src.sg, aes->src.nents,
+DMA_BIDIRECTIONAL);
- if (!sg)
- return;
+ if (aes->src.sg != &aes->a
Re: [PATCH] x86/crypto: make constants readonly, allow linker to merge them
On Thu, 19 Jan 2017, Denys Vlasenko wrote: > A lot of asm-optimized routines in arch/x86/crypto/ keep its > constants in .data. This is wrong, they should be on .rodata. > > Mnay of these constants are the same in different modules. > For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F > exists in at least half a dozen places. > > There is a way to let linker merge them and use just one copy. > The rules are as follows: mergeable objects of different sizes > should not share sections. You can't put them all in one .rodata > section, they will lose "mergeability". > > GCC puts its mergeable constants in ".rodata.cstSIZE" sections, > or ".rodata.cstSIZE." if -fdata-sections is used. > This patch does the same: > > .section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16 > > It is important that all data in such section consists of > 16-byte elements, not larger ones, and there are no implicit > use of one element from another. > > When this is not the case, use non-mergeable section: > > .section .rodata[.VAR_NAME], "a", @progbits > > This reduces .data by ~15 kbytes: > > textdata bss dec hex filename > 11097415 2705840 2630712 16433967 fac32f vmlinux-prev.o > 2095 2690672 2630712 16433479 fac147 vmlinux.o And at the same time it increases text size by ~15k. The overall change in total size is 488 byte reduction. Weird. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86/crypto: make constants readonly, allow linker to merge them
A lot of asm-optimized routines in arch/x86/crypto/ keep its constants in .data. This is wrong, they should be on .rodata. Mnay of these constants are the same in different modules. For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F exists in at least half a dozen places. There is a way to let linker merge them and use just one copy. The rules are as follows: mergeable objects of different sizes should not share sections. You can't put them all in one .rodata section, they will lose "mergeability". GCC puts its mergeable constants in ".rodata.cstSIZE" sections, or ".rodata.cstSIZE." if -fdata-sections is used. This patch does the same: .section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16 It is important that all data in such section consists of 16-byte elements, not larger ones, and there are no implicit use of one element from another. When this is not the case, use non-mergeable section: .section .rodata[.VAR_NAME], "a", @progbits This reduces .data by ~15 kbytes: textdata bss dec hex filename 11097415 2705840 2630712 16433967 fac32f vmlinux-prev.o 2095 2690672 2630712 16433479 fac147 vmlinux.o Merged objects are visible in System.map: 81a28810 r POLY 81a28810 r POLY 81a28820 r TWOONE 81a28820 r TWOONE 81a28830 r PSHUFFLE_BYTE_FLIP_MASK <- merged regardless of 81a28830 r SHUF_MASK <- the name difference 81a28830 r SHUF_MASK 81a28830 r SHUF_MASK .. 81a28d00 r K512 <- merged three identical 640-byte tables 81a28d00 r K512 81a28d00 r K512 Use of object names in section name suffixes is not strictly necessary, but might help if someday link stage will use garbage collection to eliminate unused sections (ld --gc-sections). Signed-off-by: Denys Vlasenko CC: Herbert Xu CC: Josh Poimboeuf CC: Xiaodong Liu CC: Megha Dey CC: linux-crypto@vger.kernel.org CC: x...@kernel.org CC: linux-ker...@vger.kernel.org --- arch/x86/crypto/aesni-intel_asm.S | 37 +- arch/x86/crypto/aesni-intel_avx-x86_64.S | 32 ++- arch/x86/crypto/camellia-aesni-avx-asm_64.S| 5 ++- arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 12 +-- arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 14 ++-- arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 12 +-- arch/x86/crypto/chacha20-avx2-x86_64.S | 9 -- arch/x86/crypto/chacha20-ssse3-x86_64.S| 7 ++-- arch/x86/crypto/crct10dif-pcl-asm_64.S | 14 ++-- arch/x86/crypto/des3_ede-asm_64.S | 2 +- arch/x86/crypto/ghash-clmulni-intel_asm.S | 3 +- arch/x86/crypto/poly1305-avx2-x86_64.S | 6 ++-- arch/x86/crypto/poly1305-sse2-x86_64.S | 6 ++-- arch/x86/crypto/serpent-avx-x86_64-asm_64.S| 5 +-- arch/x86/crypto/serpent-avx2-asm_64.S | 9 -- arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 6 ++-- arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S | 3 +- arch/x86/crypto/sha1-mb/sha1_x8_avx2.S | 15 +++-- arch/x86/crypto/sha1_ni_asm.S | 8 +++-- arch/x86/crypto/sha256-avx-asm.S | 9 +- arch/x86/crypto/sha256-avx2-asm.S | 9 +- .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S| 6 ++-- .../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S | 3 +- arch/x86/crypto/sha256-mb/sha256_x8_avx2.S | 7 +++- arch/x86/crypto/sha256-ssse3-asm.S | 8 - arch/x86/crypto/sha256_ni_asm.S| 4 ++- arch/x86/crypto/sha512-avx-asm.S | 9 -- arch/x86/crypto/sha512-avx2-asm.S | 10 -- .../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S| 10 -- .../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S | 4 ++- arch/x86/crypto/sha512-mb/sha512_x4_avx2.S | 4 ++- arch/x86/crypto/sha512-ssse3-asm.S | 9 -- arch/x86/crypto/twofish-avx-x86_64-asm_64.S| 6 ++-- 33 files changed, 229 insertions(+), 74 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 383a6f8..3c46518 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -46,28 +46,49 @@ #ifdef __x86_64__ -.data +# constants in mergeable sections, linker can reorder and merge +.section .rodata.cst16.gf128mul_x_ble_mask, "aM", @progbits, 16 .align 16 .Lgf128mul_x_ble_mask: .octa 0x00010087 +.section .rodata.cst16.POLY, "aM", @progbits, 16 +.align 16 POLY: .octa 0xC201 +.section .rodata.cst16.TWOONE, "aM", @progbits, 16 +.align 16 TWOONE: .octa 0x00010001 -# order of these constants should not change. -# more specifically, ALL_F should follow SHIFT_MASK, -# and ZERO should foll
Re: [PATCH] x86/crypto: fix %progbits -> @progbits
On Thu, Jan 19, 2017 at 10:28:05PM +0100, Denys Vlasenko wrote: > %progbits form is used on ARM (where @ is a comment char). > > x86 consistently uses @progbits everywhere else. > > Signed-off-by: Denys Vlasenko Reviewed-by: Josh Poimboeuf -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86/crypto: fix %progbits -> @progbits
%progbits form is used on ARM (where @ is a comment char). x86 consistently uses @progbits everywhere else. Signed-off-by: Denys Vlasenko CC: Herbert Xu CC: Josh Poimboeuf CC: Xiaodong Liu CC: Megha Dey CC: George Spelvin CC: linux-crypto@vger.kernel.org CC: x...@kernel.org CC: linux-ker...@vger.kernel.org --- arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S index dc05f01..7a7de27 100644 --- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S +++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S @@ -312,7 +312,7 @@ do_return: ret ENDPROC(crc_pcl) -.section .rodata, "a", %progbits +.section .rodata, "a", @progbits ## jump tableTable is 129 entries x 2 bytes each -- 2.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Introduce AMD Secure Processor device
Hi Greg, On 01/19/2017 12:21 PM, Greg KH wrote: On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series moves the CCP device driver to the misc directory and creates a framework that allows functional component of the AMD Secure Processor to be initialized and handled appropriately. Why the misc directory? I don't see the justification here... Since this driver is not solely for crypto purposes and do not fit in any of the standard categories hence I thought of moving it into misc directory. I am open to other suggestions unless Herbert is ok with leaving it into crypto and allowing the addition of the Secure Processor support. The patch series allows the CCP driver to support other Secure Processor functions, e.g Secure Encrypted Virtualization (SEV) key management. In past, I tried to add SEV support into existing CCP driver [1] but we quickly learned that CCP driver should be moved outside the crypto directory otherwise will end up adding non crypto code into drivers/crypto directory. Once this cleanup is accepted then I can work to add SEV support inside the CCP driver. [1] http://marc.info/?l=linux-kernel&m=147204118426151&w=2 -Brijesh -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] crypto: move CCP device driver to misc
Hi Greg, On 01/19/2017 12:18 PM, Greg KH wrote: On Thu, Jan 19, 2017 at 01:08:01PM -0500, Brijesh Singh wrote: The CCP device is part of the AMD Secure Processor, which is not dedicated solely to crypto. Move the CCP device driver to the misc directory in prepration for expanding the usage of the AMD Secure Processor. Leaving the CCP cryptographic layer (the ccp-crypto* files) in their current directory. Signed-off-by: Brijesh Singh Signed-off-by: Tom Lendacky --- drivers/crypto/Kconfig | 11 drivers/crypto/Makefile |2 drivers/crypto/ccp/Kconfig | 21 drivers/crypto/ccp/Makefile |9 drivers/crypto/ccp/ccp-dev-v3.c | 574 --- drivers/crypto/ccp/ccp-dev-v5.c | 1021 --- drivers/crypto/ccp/ccp-dev.c| 588 --- drivers/crypto/ccp/ccp-dev.h| 647 drivers/crypto/ccp/ccp-dmaengine.c | 728 -- drivers/crypto/ccp/ccp-ops.c| 1876 --- drivers/crypto/ccp/ccp-pci.c| 354 --- drivers/crypto/ccp/ccp-platform.c | 293 - drivers/misc/Kconfig|1 drivers/misc/Makefile |1 drivers/misc/amd-sp/Kconfig | 14 drivers/misc/amd-sp/Makefile|8 drivers/misc/amd-sp/ccp-dev-v3.c| 574 +++ drivers/misc/amd-sp/ccp-dev-v5.c| 1021 +++ drivers/misc/amd-sp/ccp-dev.c | 588 +++ drivers/misc/amd-sp/ccp-dev.h | 647 drivers/misc/amd-sp/ccp-dmaengine.c | 728 ++ drivers/misc/amd-sp/ccp-ops.c | 1876 +++ drivers/misc/amd-sp/ccp-pci.c | 354 +++ drivers/misc/amd-sp/ccp-platform.c | 293 + include/linux/ccp.h |3 25 files changed, 6111 insertions(+), 6121 deletions(-) delete mode 100644 drivers/crypto/ccp/ccp-dev-v3.c delete mode 100644 drivers/crypto/ccp/ccp-dev-v5.c delete mode 100644 drivers/crypto/ccp/ccp-dev.c delete mode 100644 drivers/crypto/ccp/ccp-dev.h delete mode 100644 drivers/crypto/ccp/ccp-dmaengine.c delete mode 100644 drivers/crypto/ccp/ccp-ops.c delete mode 100644 drivers/crypto/ccp/ccp-pci.c delete mode 100644 drivers/crypto/ccp/ccp-platform.c create mode 100644 drivers/misc/amd-sp/Kconfig create mode 100644 drivers/misc/amd-sp/Makefile create mode 100644 drivers/misc/amd-sp/ccp-dev-v3.c create mode 100644 drivers/misc/amd-sp/ccp-dev-v5.c create mode 100644 drivers/misc/amd-sp/ccp-dev.c create mode 100644 drivers/misc/amd-sp/ccp-dev.h create mode 100644 drivers/misc/amd-sp/ccp-dmaengine.c create mode 100644 drivers/misc/amd-sp/ccp-ops.c create mode 100644 drivers/misc/amd-sp/ccp-pci.c create mode 100644 drivers/misc/amd-sp/ccp-platform.c Please create your patch with -M, to show this is a rename, or a change with a rename. Otherwise this is an impossible patch to review, would you want to try to do it? Thanks for the tip, will re-generate the patches with -M. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] misc: amd-sp: introduce the AMD Secure Processor device
On Thu, Jan 19, 2017 at 01:08:11PM -0500, Brijesh Singh wrote: > The CCP device is part of the AMD Secure Processor. In order to expand the > usage of the AMD Secure Processor, create a framework that allows functional > components of the AMD Secure Processor to be initialized and handled > appropriately. What do you mean by "framework"? What is this for? Who is going to use it? Don't add framework that is not ever used, otherwise we will just delete it. > > Signed-off-by: Brijesh Singh > Signed-off-by: Tom Lendacky > --- > drivers/crypto/ccp/Kconfig|1 > drivers/misc/amd-sp/Kconfig | 16 +- > drivers/misc/amd-sp/Makefile | 11 + > drivers/misc/amd-sp/ccp-dev-v3.c | 86 +- > drivers/misc/amd-sp/ccp-dev-v5.c | 72 > drivers/misc/amd-sp/ccp-dev.c | 137 +--- > drivers/misc/amd-sp/ccp-dev.h | 35 > drivers/misc/amd-sp/sp-dev.c | 309 +++ > drivers/misc/amd-sp/sp-dev.h | 141 > drivers/misc/amd-sp/sp-pci.c | 325 > + > drivers/misc/amd-sp/sp-platform.c | 269 +++ > 11 files changed, 1225 insertions(+), 177 deletions(-) > create mode 100644 drivers/misc/amd-sp/sp-dev.c > create mode 100644 drivers/misc/amd-sp/sp-dev.h > create mode 100644 drivers/misc/amd-sp/sp-pci.c > create mode 100644 drivers/misc/amd-sp/sp-platform.c This patch makes no sense, you need to break it up into "do one logical thing", as that is NOT what is happening here. It's impossible to review as-is, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Introduce AMD Secure Processor device
On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: > The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, > which is not dedicated solely to crypto. The AMD Secure Processor includes > CCP and PSP (Platform Secure Processor) devices. > > This patch series moves the CCP device driver to the misc directory and > creates a framework that allows functional component of the AMD Secure > Processor to be initialized and handled appropriately. Why the misc directory? I don't see the justification here... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] crypto: move CCP device driver to misc
On Thu, Jan 19, 2017 at 01:08:01PM -0500, Brijesh Singh wrote: > The CCP device is part of the AMD Secure Processor, which is not dedicated > solely to crypto. Move the CCP device driver to the misc directory in > prepration for expanding the usage of the AMD Secure Processor. Leaving the > CCP cryptographic layer (the ccp-crypto* files) in their current directory. > > Signed-off-by: Brijesh Singh > Signed-off-by: Tom Lendacky > --- > drivers/crypto/Kconfig | 11 > drivers/crypto/Makefile |2 > drivers/crypto/ccp/Kconfig | 21 > drivers/crypto/ccp/Makefile |9 > drivers/crypto/ccp/ccp-dev-v3.c | 574 --- > drivers/crypto/ccp/ccp-dev-v5.c | 1021 --- > drivers/crypto/ccp/ccp-dev.c| 588 --- > drivers/crypto/ccp/ccp-dev.h| 647 > drivers/crypto/ccp/ccp-dmaengine.c | 728 -- > drivers/crypto/ccp/ccp-ops.c| 1876 > --- > drivers/crypto/ccp/ccp-pci.c| 354 --- > drivers/crypto/ccp/ccp-platform.c | 293 - > drivers/misc/Kconfig|1 > drivers/misc/Makefile |1 > drivers/misc/amd-sp/Kconfig | 14 > drivers/misc/amd-sp/Makefile|8 > drivers/misc/amd-sp/ccp-dev-v3.c| 574 +++ > drivers/misc/amd-sp/ccp-dev-v5.c| 1021 +++ > drivers/misc/amd-sp/ccp-dev.c | 588 +++ > drivers/misc/amd-sp/ccp-dev.h | 647 > drivers/misc/amd-sp/ccp-dmaengine.c | 728 ++ > drivers/misc/amd-sp/ccp-ops.c | 1876 > +++ > drivers/misc/amd-sp/ccp-pci.c | 354 +++ > drivers/misc/amd-sp/ccp-platform.c | 293 + > include/linux/ccp.h |3 > 25 files changed, 6111 insertions(+), 6121 deletions(-) > delete mode 100644 drivers/crypto/ccp/ccp-dev-v3.c > delete mode 100644 drivers/crypto/ccp/ccp-dev-v5.c > delete mode 100644 drivers/crypto/ccp/ccp-dev.c > delete mode 100644 drivers/crypto/ccp/ccp-dev.h > delete mode 100644 drivers/crypto/ccp/ccp-dmaengine.c > delete mode 100644 drivers/crypto/ccp/ccp-ops.c > delete mode 100644 drivers/crypto/ccp/ccp-pci.c > delete mode 100644 drivers/crypto/ccp/ccp-platform.c > create mode 100644 drivers/misc/amd-sp/Kconfig > create mode 100644 drivers/misc/amd-sp/Makefile > create mode 100644 drivers/misc/amd-sp/ccp-dev-v3.c > create mode 100644 drivers/misc/amd-sp/ccp-dev-v5.c > create mode 100644 drivers/misc/amd-sp/ccp-dev.c > create mode 100644 drivers/misc/amd-sp/ccp-dev.h > create mode 100644 drivers/misc/amd-sp/ccp-dmaengine.c > create mode 100644 drivers/misc/amd-sp/ccp-ops.c > create mode 100644 drivers/misc/amd-sp/ccp-pci.c > create mode 100644 drivers/misc/amd-sp/ccp-platform.c Please create your patch with -M, to show this is a rename, or a change with a rename. Otherwise this is an impossible patch to review, would you want to try to do it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Introduce AMD Secure Processor device
The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series moves the CCP device driver to the misc directory and creates a framework that allows functional component of the AMD Secure Processor to be initialized and handled appropriately. The patch series leaves the CCP cryptographic layer (ccp-crypto* files) in their current directory. The new interface will be used to integrate Secure Encrypted Virtualzation [1] key management and Trusted Execution Environment (TEE) services provided by PSP device. http://marc.info/?l=linux-mm&m=147190938124206&w=2 Brijesh Singh (2): crypto: move CCP device driver to misc misc: amd-sp: introduce the AMD Secure Processor device drivers/crypto/Kconfig | 11 drivers/crypto/Makefile |2 drivers/crypto/ccp/Kconfig | 22 drivers/crypto/ccp/Makefile |9 drivers/crypto/ccp/ccp-dev-v3.c | 574 --- drivers/crypto/ccp/ccp-dev-v5.c | 1021 --- drivers/crypto/ccp/ccp-dev.c| 588 --- drivers/crypto/ccp/ccp-dev.h| 647 drivers/crypto/ccp/ccp-dmaengine.c | 728 -- drivers/crypto/ccp/ccp-ops.c| 1876 --- drivers/crypto/ccp/ccp-pci.c| 354 --- drivers/crypto/ccp/ccp-platform.c | 293 - drivers/misc/Kconfig|1 drivers/misc/Makefile |1 drivers/misc/amd-sp/Kconfig | 22 drivers/misc/amd-sp/Makefile|9 drivers/misc/amd-sp/ccp-dev-v3.c| 578 +++ drivers/misc/amd-sp/ccp-dev-v5.c| 1017 +++ drivers/misc/amd-sp/ccp-dev.c | 611 +++ drivers/misc/amd-sp/ccp-dev.h | 618 drivers/misc/amd-sp/ccp-dmaengine.c | 728 ++ drivers/misc/amd-sp/ccp-ops.c | 1876 +++ drivers/misc/amd-sp/ccp-pci.c | 354 +++ drivers/misc/amd-sp/ccp-platform.c | 293 + drivers/misc/amd-sp/sp-dev.c| 309 ++ drivers/misc/amd-sp/sp-dev.h| 141 +++ drivers/misc/amd-sp/sp-pci.c| 325 ++ drivers/misc/amd-sp/sp-platform.c | 269 + include/linux/ccp.h |3 29 files changed, 7159 insertions(+), 6121 deletions(-) delete mode 100644 drivers/crypto/ccp/ccp-dev-v3.c delete mode 100644 drivers/crypto/ccp/ccp-dev-v5.c delete mode 100644 drivers/crypto/ccp/ccp-dev.c delete mode 100644 drivers/crypto/ccp/ccp-dev.h delete mode 100644 drivers/crypto/ccp/ccp-dmaengine.c delete mode 100644 drivers/crypto/ccp/ccp-ops.c delete mode 100644 drivers/crypto/ccp/ccp-pci.c delete mode 100644 drivers/crypto/ccp/ccp-platform.c create mode 100644 drivers/misc/amd-sp/Kconfig create mode 100644 drivers/misc/amd-sp/Makefile create mode 100644 drivers/misc/amd-sp/ccp-dev-v3.c create mode 100644 drivers/misc/amd-sp/ccp-dev-v5.c create mode 100644 drivers/misc/amd-sp/ccp-dev.c create mode 100644 drivers/misc/amd-sp/ccp-dev.h create mode 100644 drivers/misc/amd-sp/ccp-dmaengine.c create mode 100644 drivers/misc/amd-sp/ccp-ops.c create mode 100644 drivers/misc/amd-sp/ccp-pci.c create mode 100644 drivers/misc/amd-sp/ccp-platform.c create mode 100644 drivers/misc/amd-sp/sp-dev.c create mode 100644 drivers/misc/amd-sp/sp-dev.h create mode 100644 drivers/misc/amd-sp/sp-pci.c create mode 100644 drivers/misc/amd-sp/sp-platform.c -- Brijesh Singh -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] misc: amd-sp: introduce the AMD Secure Processor device
The CCP device is part of the AMD Secure Processor. In order to expand the
usage of the AMD Secure Processor, create a framework that allows functional
components of the AMD Secure Processor to be initialized and handled
appropriately.
Signed-off-by: Brijesh Singh
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/Kconfig|1
drivers/misc/amd-sp/Kconfig | 16 +-
drivers/misc/amd-sp/Makefile | 11 +
drivers/misc/amd-sp/ccp-dev-v3.c | 86 +-
drivers/misc/amd-sp/ccp-dev-v5.c | 72
drivers/misc/amd-sp/ccp-dev.c | 137 +---
drivers/misc/amd-sp/ccp-dev.h | 35
drivers/misc/amd-sp/sp-dev.c | 309 +++
drivers/misc/amd-sp/sp-dev.h | 141
drivers/misc/amd-sp/sp-pci.c | 325 +
drivers/misc/amd-sp/sp-platform.c | 269 +++
11 files changed, 1225 insertions(+), 177 deletions(-)
create mode 100644 drivers/misc/amd-sp/sp-dev.c
create mode 100644 drivers/misc/amd-sp/sp-dev.h
create mode 100644 drivers/misc/amd-sp/sp-pci.c
create mode 100644 drivers/misc/amd-sp/sp-platform.c
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 523d0f5..ac9c503 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,6 +1,7 @@
config CRYPTO_DEV_CCP_CRYPTO
tristate "Support for AMD Cryptographic Coprocessor"
default n
+ select AMD_SP
select AMD_CCP
select CRYPTO_HASH
select CRYPTO_BLKCIPHER
diff --git a/drivers/misc/amd-sp/Kconfig b/drivers/misc/amd-sp/Kconfig
index dbf7baa..a35b7f6 100644
--- a/drivers/misc/amd-sp/Kconfig
+++ b/drivers/misc/amd-sp/Kconfig
@@ -1,7 +1,16 @@
-config AMD_CCP
- tristate "Support for AMD Cryptographic Coprocessor"
+config AMD_SP
+ tristate "Support for AMD Secure Processor"
default n
depends on ((X86 && PCI) || (ARM64 && (OF_ADDRESS || ACPI))) &&
HAS_IOMEM
+ help
+ Provides the interface to access the AMD Secure Processor. The
+ AMD Secure Processor supports the AMD Cryptographic Coprocessor.
+ If you choose 'M' here, this module will be call ccp.
+
+config AMD_CCP
+ bool "Support for AMD Cryptographic Coprocessor"
+ depends on AMD_SP
+ default y
select HW_RANDOM
select DMA_ENGINE
select DMADEVICES
@@ -10,5 +19,4 @@ config AMD_CCP
help
Provides the interface to use the AMD Cryptographic Coprocessor
which can be used to offload encryption operations such as SHA,
- AES and more. If you choose 'M' here, this module will be called
- ccp.
+ AES and more.
diff --git a/drivers/misc/amd-sp/Makefile b/drivers/misc/amd-sp/Makefile
index 85991a5..23f0c9f 100644
--- a/drivers/misc/amd-sp/Makefile
+++ b/drivers/misc/amd-sp/Makefile
@@ -1,8 +1,9 @@
-obj-$(CONFIG_AMD_CCP) += ccp.o
-ccp-objs := ccp-dev.o \
- ccp-ops.o \
+obj-$(CONFIG_AMD_SP) += ccp.o
+ccp-objs := sp-dev.o sp-platform.o
+ccp-$(CONFIG_PCI) += sp-pci.o
+
+ccp-$(CONFIG_AMD_CCP) += ccp-dev.o \
ccp-dev-v3.o \
ccp-dev-v5.o \
- ccp-platform.o \
+ ccp-ops.o \
ccp-dmaengine.o
-ccp-$(CONFIG_PCI) += ccp-pci.o
diff --git a/drivers/misc/amd-sp/ccp-dev-v3.c b/drivers/misc/amd-sp/ccp-dev-v3.c
index 7bc0998..5c50d14 100644
--- a/drivers/misc/amd-sp/ccp-dev-v3.c
+++ b/drivers/misc/amd-sp/ccp-dev-v3.c
@@ -315,6 +315,39 @@ static int ccp_perform_ecc(struct ccp_op *op)
return ccp_do_cmd(op, cr, ARRAY_SIZE(cr));
}
+static irqreturn_t ccp_irq_handler(int irq, void *data)
+{
+ struct ccp_device *ccp = data;
+ struct ccp_cmd_queue *cmd_q;
+ u32 q_int, status;
+ unsigned int i;
+
+ status = ioread32(ccp->io_regs + IRQ_STATUS_REG);
+
+ for (i = 0; i < ccp->cmd_q_count; i++) {
+ cmd_q = &ccp->cmd_q[i];
+
+ q_int = status & (cmd_q->int_ok | cmd_q->int_err);
+ if (q_int) {
+ cmd_q->int_status = status;
+ cmd_q->q_status = ioread32(cmd_q->reg_status);
+ cmd_q->q_int_status = ioread32(cmd_q->reg_int_status);
+
+ /* On error, only save the first error value */
+ if ((q_int & cmd_q->int_err) && !cmd_q->cmd_error)
+ cmd_q->cmd_error = CMD_Q_ERROR(cmd_q->q_status);
+
+ cmd_q->int_rcvd = 1;
+
+ /* Acknowledge the interrupt and wake the kthread */
+ iowrite32(q_int, ccp->io_regs + IRQ_STATUS_REG);
+ wake_up_interruptible(&cmd_q->int_queue);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
static int ccp_init(struct ccp_device *ccp)
{
struct device *dev = ccp->dev;
@@ -374,7 +407,7 @@ static int ccp_init(struct ccp_device *ccp)
#ifdef CONFIG_ARM
Re: [RFC PATCH v3] crypto: Add IV generation algorithms
Hi Gilad, On 19 January 2017 at 15:17, Gilad Ben-Yossef wrote: > I tried adding sg_init_table() where I thought it was appropriate and > it didn't resolve the issue. > > For what it's worth, my guess is that the difference between our > setups is not related to Arm but to other options or the storage I'm > using. I was able to reproduce this again on my qemu setup with a 1GB virtual disk. That is the same thing I do with the x86 setup as well. > Are you using cryptd? You mean config CRYPTO_CRYPTD? -Binoy -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt
2017-01-18 5:48 GMT+01:00 Herbert Xu : > I'm open to other proposals. The basic requirement is to be able to > process multiple blocks as one entity at the driver level, potentially > generating the IVs there too. > > It's essentially the equivalent to full IPsec offload. Hm, I just looked at what the IPsec IV generation is actually doing and it seems to me that it's basically a crypto template that just somehow transforms the IV before it is passed to the child cipher... I thought for a while that you were implying that there already is some facility in the crypto API that allows submitting multiple messages + some initial sequence number that is auto-incremented and IVs are generated from the numbers. However, I could not find anything like that in the code, so now I think what you meant was just that I should somehow pull the actual IV generators into the crypto layer so that the IVs can be generated inside the hardware. If all you had in mind is just an equivalent of the current IPsec IV generation (as I understood it), then my bulk request scheme can in fact support it (you'd just pass sector numbers as the IVs). Of course, it would require additional changes over my patchset, specifically the creation of crypto templates for the dm-crypt IV modes, so they can be implemented by drivers. However, I wanted to avoid this until the key management in dm-crypt is simplified... If we also want to let the drivers process an offset+count chunk of sectors while auto-incrementing the sector number, then something like Binoy's approach would indeed be necessary, where the IV generators would be just regular skciphers, taking the initial sector number as the IV (although a disadvantage would be hard-coded sector/message size). Note, though, that the generic implementation of such transform could still use bulk requests on the underlying cipher so that encryption/decryption is performed efficiently even if there are no optimized/HW drivers for the specific IV generator templates. I will now try to focus on the key management simplification and when it is accepted/rejected we can discuss further about the best approach. Cheers, Ondrej > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: arm/aes-neonbs - fix issue with v2.22 and older assembler
The GNU assembler for ARM version 2.22 or older fails to infer the element size from the vmov instructions, and aborts the build in the following way; .../aes-neonbs-core.S: Assembler messages: .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[1],r10' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[0],r9' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[1],r8' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[0],r7' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[1],r10' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[0],r9' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[1],r8' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[0],r7' Fix this by setting the element size explicitly, by replacing vmov with vmov.32. Signed-off-by: Ard Biesheuvel --- Please add to the cryptodev-2.6 queue for v4.11 arch/arm/crypto/aes-neonbs-core.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/crypto/aes-neonbs-core.S b/arch/arm/crypto/aes-neonbs-core.S index c9477044fbba..12da247164d1 100644 --- a/arch/arm/crypto/aes-neonbs-core.S +++ b/arch/arm/crypto/aes-neonbs-core.S @@ -766,13 +766,13 @@ ENTRY(aesbs_cbc_decrypt) ENDPROC(aesbs_cbc_decrypt) .macro next_ctr, q - vmov\q\()h[1], r10 + vmov.32 \q\()h[1], r10 addsr10, r10, #1 - vmov\q\()h[0], r9 + vmov.32 \q\()h[0], r9 adcsr9, r9, #0 - vmov\q\()l[1], r8 + vmov.32 \q\()l[1], r8 adcsr8, r8, #0 - vmov\q\()l[0], r7 + vmov.32 \q\()l[0], r7 adc r7, r7, #0 vrev32.8\q, \q .endm -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] crypto: Add IV generation algorithms
On Thu, Jan 19, 2017 at 6:42 AM, Binoy Jayan wrote: > Hi Gilad, > > On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote: >> I have some review comments and a bug report - > > Thank you very much for testing this on ARM and for the comments. My pleasure. Thanks for writing the code :-) > >>> + rinfo.iv_sector = ctx->cc_sector; >>> + rinfo.nents = nents; >>> + rinfo.iv = iv; >>> + >>> + skcipher_request_set_crypt(req, dmreq->sg_in, dmreq->sg_out, >> >> Also, where do the scatterlist src2 and dst2 that you use >> sg_set_page() get sg_init_table() called on? >> I couldn't figure it out... > > Thank you pointing this out. I missed out to add sg_init_table(src2, 1) > and sg_init_table(dst2, 1), but sg_set_page is used in geniv_iter_block. > This is probably the reason for the panic on ARM platform. However it > ran fine under qemu-x86. May be I should setup an arm platform too > for testing. I tried adding sg_init_table() where I thought it was appropriate and it didn't resolve the issue. For what it's worth, my guess is that the difference between our setups is not related to Arm but to other options or the storage I'm using. Are you using cryptd? Thanks, Gilad > > Regards, > Binoy -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
