crypto: Add EIP-93 crypto engine support

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +3 -0

+static int eip93_send_hash_req(struct crypto_async_request *async, u8 *data,
+			       dma_addr_t *data_dma, u32 len, bool last)
+{

Quoted 4 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +3 -0

+static int eip93_send_hash_req(struct crypto_async_request *async, u8 *data,
+                            dma_addr_t *data_dma, u32 len, bool last)
+{

...

drivers/crypto/inside-secure/eip93/eip93-hash.c line 271

Quoted 10 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +10 -0

+again:
+     ret = eip93_put_descriptor(eip93, &cdesc);
+     if (ret) {
+             usleep_range(EIP93_RING_BUSY_DELAY,
+                          EIP93_RING_BUSY_DELAY * 2);
+             goto again;
+     }
+
+     /* Writing new descriptor count starts DMA action */
+     writel(1, eip93->base + EIP93_REG_PE_CD_COUNT);

Why is there no locking here? Shouldn't this be under ring->write_lock?

Il giorno mar 1 apr 2025 alle ore 12:08 Herbert Xu <[email protected]> ha scritto:

Quoted 9 lines · Christian Marangi

Quoted 4 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +3 -0

+static int eip93_send_hash_req(struct crypto_async_request *async, u8 *data,
+                            dma_addr_t *data_dma, u32 len, bool last)
+{

...

Quoted 13 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c line 271

Quoted 10 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +10 -0

+again:
+     ret = eip93_put_descriptor(eip93, &cdesc);
+     if (ret) {
+             usleep_range(EIP93_RING_BUSY_DELAY,
+                          EIP93_RING_BUSY_DELAY * 2);
+             goto again;
+     }
+
+     /* Writing new descriptor count starts DMA action */
+     writel(1, eip93->base + EIP93_REG_PE_CD_COUNT);

Why is there no locking here? Shouldn't this be under ring->write_lock?

Hi Herbert,
this is really to tell DMA that there is new packet to process and gets decreased instantly.
The lock is used to track what descriptor index should be used in the ring in the put and get
functions.

Quoted 25 lines

Il giorno mar 1 apr 2025 alle ore 12:08 Herbert Xu <[email protected]> ha scritto:

Quoted 9 lines · Christian Marangi

Quoted 4 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +3 -0

+static int eip93_send_hash_req(struct crypto_async_request *async, u8 *data,
+                            dma_addr_t *data_dma, u32 len, bool last)
+{

...

Quoted 13 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c line 271

Quoted 10 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +10 -0

+again:
+     ret = eip93_put_descriptor(eip93, &cdesc);
+     if (ret) {
+             usleep_range(EIP93_RING_BUSY_DELAY,
+                          EIP93_RING_BUSY_DELAY * 2);
+             goto again;
+     }
+
+     /* Writing new descriptor count starts DMA action */
+     writel(1, eip93->base + EIP93_REG_PE_CD_COUNT);

Why is there no locking here? Shouldn't this be under ring->write_lock?

Quoted 6 lines

Hi Herbert,
this is really to tell DMA that there is new packet to process and gets decreased instantly.
The lock is used to track what descriptor index should be used in the ring in the put and get
functions.

AFAICS it's not safe to call eip93_put_descriptor simultaneously since it doesn't use atomics. Without locking in eip93_send_hash_req two threads hashing into two separate eip93 requests will be calling eip93_put_descriptor at the same time.

Sorry but isn't it enough to acquire lock before eip93_put_descriptor to prevent 2 thread?

Quoted 3 lines

Sorry but isn't it enough to acquire lock before eip93_put_descriptor to prevent 2 thread?

It would be, but where is the lock? In the other places where the same function is used you take the ring write lock. But not here in the hash function.

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +5 -0

+static void eip93_hash_export_sa_state(struct ahash_request *req,
+				       struct eip93_hash_export_state *state)
+{
+	struct eip93_hash_reqctx *rctx = ahash_request_ctx_dma(req);
+	struct sa_state *sa_state = &rctx->sa_state;

Quoted 11 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +10 -0

+static void eip93_hash_export_sa_state(struct ahash_request *req,
+                                    struct eip93_hash_export_state *state)
+{
+     struct eip93_hash_reqctx *rctx = ahash_request_ctx_dma(req);
+     struct sa_state *sa_state = &rctx->sa_state;
+
+     /*
+      * EIP93 have special handling for state_byte_cnt in sa_state.
+      * Even if a zero packet is passed (and a BADMSG is returned),
+      * state_byte_cnt is incremented to the digest handled (with the hash

drivers/crypto/inside-secure/eip93/eip93-hash.c line 140

Quoted 5 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +5 -0

+      * primitive). This is problematic with export/import as EIP93
+      * expect 0 state_byte_cnt for the very first iteration.
+      */
+     if (!rctx->len)
+             memset(state->state_len, 0, sizeof(u32) * 2);

I don't understand when this can occur. As far as I can see, zero-length packets are never passed to the hardware for hashing.

drivers/crypto/inside-secure/eip93/eip93-hash.c line 143

Quoted 3 lines

drivers/crypto/inside-secure/eip93/eip93-hash.c new file +3 -0

+     else
+             memcpy(state->state_len, sa_state->state_byte_cnt,
+                    sizeof(u32) * 2);

I need to know the endianness of state_byte_cnt, which I presume is the number of bytes that have been hashed into the partial hash state.

I need this because I'm changing the export format of all ahash algorithms to match that of the generic implementation. This is so that you can seamlessly switch between an async ahash and its sync fallback.

If you are ok I can send a patch to drop this (and maybe leave the comment just to document this strange finding)

What do you think?

This small series add support for the Inside Secure EIP-93. This is a predecessor of the current supported EIP197. It doesn't require a firmware but instead it's embedded in the SoC.

First patch extend guard for spinlock_bh.

The other actually implement Documentation and Driver.

The Driver pass all the normal selft test for the supported algo and also pass the EXTRA test with fuzz_iterations set to 10000.

Changes v11:
- Drop any mtk variable reference and use eip93 instead
- Mute smatch warning for context unbalance by using scoped_guard instead of guard cleanup API
Changes v10:
- Use CRYPTO_ALG_ASYNC for eip93_hmac_setkey
Changes v9:
- Rework hash code to alloc DMA only when needed
- Rework hash code to only alloc needed blocks and use
local struct in req for everything else
- Rework hash code to use GFP_ATOMIC
- Simplify hash update function
- Generalize hmac key set function
Changes v8:
- Rework export and update to not sleep on exporting state (consume pending packet in update and return -EINPROGRESS)
Changes v7:
- Fix copypaste error in __eip93_hash_init
- Rework import/export to actually export the partial hash (we actually unmap DMA on export)
- Rename no_finalize variable to better partial_hash
- Rename 3rd commit title and drop Mediatek from title.
- Add Cover Letter
- Add Reviewed-by to DT commit
(cumulative changes from old series that had changelog in each patch) Changes v6:
- Add SoC specific compatible
- Add now supported entry for compatible with no user
Changes v5:
- Add Ack tag to guard patch
- Comment out compatible with no current user
- Fix smatch warning (reported by Dan Carpenter)
Changes v4:
- Out of RFC
- Add missing bitfield.h
- Drop useless header
Changes v3:
- Mute warning from Clang about C23
- Fix not inizialized err
- Drop unused variable
- Add SoC compatible with generic one
Changes v2:
- Rename all variables from mtk to eip93
- Move to inside-secure directory
- Check DMA map errors
- Use guard API for spinlock
- Minor improvements to code
- Add guard patch
- Change to better compatible
- Add description for EIP93 models

Christian Marangi (3):
spinlock: extend guard with spinlock_bh variants
dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
crypto: Add Inside Secure SafeXcel EIP-93 crypto engine support

 .../crypto/inside-secure,safexcel-eip93.yaml  |  67 ++
 MAINTAINERS                                   |   7 +
 drivers/crypto/Kconfig                        |   1 +
 drivers/crypto/Makefile                       |   1 +
 drivers/crypto/inside-secure/eip93/Kconfig    |  20 +
 drivers/crypto/inside-secure/eip93/Makefile   |   5 +
 .../crypto/inside-secure/eip93/eip93-aead.c   | 711 ++++++++++++++
 .../crypto/inside-secure/eip93/eip93-aead.h   |  38 +
 .../crypto/inside-secure/eip93/eip93-aes.h    |  16 +
 .../crypto/inside-secure/eip93/eip93-cipher.c | 413 +++++++++
 .../crypto/inside-secure/eip93/eip93-cipher.h |  60 ++
 .../crypto/inside-secure/eip93/eip93-common.c | 809 ++++++++++++++++
 .../crypto/inside-secure/eip93/eip93-common.h |  24 +
 .../crypto/inside-secure/eip93/eip93-des.h    |  16 +
 .../crypto/inside-secure/eip93/eip93-hash.c   | 866 ++++++++++++++++++
 .../crypto/inside-secure/eip93/eip93-hash.h   |  82 ++
 .../crypto/inside-secure/eip93/eip93-main.c   | 501 ++++++++++
 .../crypto/inside-secure/eip93/eip93-main.h   | 151 +++
 .../crypto/inside-secure/eip93/eip93-regs.h   | 335 +++++++
 include/linux/spinlock.h                      |  13 +
 20 files changed, 4136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml
 create mode 100644 drivers/crypto/inside-secure/eip93/Kconfig
 create mode 100644 drivers/crypto/inside-secure/eip93/Makefile
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aead.c
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aead.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aes.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-cipher.c
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-cipher.h

 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-common.c
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-common.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-des.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-hash.c
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-hash.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-main.c
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-main.h
 create mode 100644 drivers/crypto/inside-secure/eip93/eip93-regs.h

Signature · 1 line

2.45.2