* [PATCH v1 1/4] crypto:chcr-Change flow IDs
From: Harsh Jain @ 2017-01-13 12:29 UTC (permalink / raw)
To: hariprasad, netdev, herbert, linux-crypto; +Cc: Harsh Jain, Atul Gupta
In-Reply-To: <cover.1484309965.git.harsh@chelsio.com>
Change assign flowc id to each outgoing request.Firmware use flowc id
to schedule each request onto HW. FW reply may lost without this change.
Reviewed-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 18 ++++++++++--------
drivers/crypto/chelsio/chcr_algo.h | 9 +++++----
drivers/crypto/chelsio/chcr_core.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 ++++++++
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index 2ed1e24..1d7dfcf 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -542,10 +542,11 @@ static inline void create_wreq(struct chcr_context *ctx,
(calc_tx_flits_ofld(skb) * 8), 16)));
chcr_req->wreq.cookie = cpu_to_be64((uintptr_t)req);
chcr_req->wreq.rx_chid_to_rx_q_id =
- FILL_WR_RX_Q_ID(ctx->dev->tx_channel_id, qid,
- is_iv ? iv_loc : IV_NOP);
+ FILL_WR_RX_Q_ID(ctx->dev->rx_channel_id, qid,
+ is_iv ? iv_loc : IV_NOP, ctx->tx_channel_id);
- chcr_req->ulptx.cmd_dest = FILL_ULPTX_CMD_DEST(ctx->dev->tx_channel_id);
+ chcr_req->ulptx.cmd_dest = FILL_ULPTX_CMD_DEST(ctx->dev->tx_channel_id,
+ qid);
chcr_req->ulptx.len = htonl((DIV_ROUND_UP((calc_tx_flits_ofld(skb) * 8),
16) - ((sizeof(chcr_req->wreq)) >> 4)));
@@ -606,7 +607,7 @@ static inline void create_wreq(struct chcr_context *ctx,
chcr_req = (struct chcr_wr *)__skb_put(skb, transhdr_len);
memset(chcr_req, 0, transhdr_len);
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2, 1);
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2, 1);
chcr_req->sec_cpl.pldlen = htonl(ivsize + req->nbytes);
chcr_req->sec_cpl.aadstart_cipherstop_hi =
@@ -782,6 +783,7 @@ static int chcr_device_init(struct chcr_context *ctx)
spin_lock(&ctx->dev->lock_chcr_dev);
ctx->tx_channel_id = rxq_idx;
ctx->dev->tx_channel_id = !ctx->dev->tx_channel_id;
+ ctx->dev->rx_channel_id = 0;
spin_unlock(&ctx->dev->lock_chcr_dev);
}
out:
@@ -874,7 +876,7 @@ static struct sk_buff *create_hash_wr(struct ahash_request *req,
memset(chcr_req, 0, transhdr_len);
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2, 0);
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2, 0);
chcr_req->sec_cpl.pldlen = htonl(param->bfr_len + param->sg_len);
chcr_req->sec_cpl.aadstart_cipherstop_hi =
@@ -1424,7 +1426,7 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
* to the hardware spec
*/
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2,
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2,
(ivsize ? (assoclen + 1) : 0));
chcr_req->sec_cpl.pldlen = htonl(assoclen + ivsize + req->cryptlen);
chcr_req->sec_cpl.aadstart_cipherstop_hi = FILL_SEC_CPL_CIPHERSTOP_HI(
@@ -1600,7 +1602,7 @@ static void fill_sec_cpl_for_aead(struct cpl_tx_sec_pdu *sec_cpl,
unsigned int ivsize = AES_BLOCK_SIZE;
unsigned int cipher_mode = CHCR_SCMD_CIPHER_MODE_AES_CCM;
unsigned int mac_mode = CHCR_SCMD_AUTH_MODE_CBCMAC;
- unsigned int c_id = chcrctx->dev->tx_channel_id;
+ unsigned int c_id = chcrctx->dev->rx_channel_id;
unsigned int ccm_xtra;
unsigned char tag_offset = 0, auth_offset = 0;
unsigned char hmac_ctrl = get_hmac(crypto_aead_authsize(tfm));
@@ -1875,7 +1877,7 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
tag_offset = (op_type == CHCR_ENCRYPT_OP) ? 0 : authsize;
chcr_req->sec_cpl.op_ivinsrtofst = FILL_SEC_CPL_OP_IVINSR(
- ctx->dev->tx_channel_id, 2, (ivsize ?
+ ctx->dev->rx_channel_id, 2, (ivsize ?
(req->assoclen + 1) : 0));
chcr_req->sec_cpl.pldlen = htonl(req->assoclen + ivsize + crypt_len);
chcr_req->sec_cpl.aadstart_cipherstop_hi = FILL_SEC_CPL_CIPHERSTOP_HI(
diff --git a/drivers/crypto/chelsio/chcr_algo.h b/drivers/crypto/chelsio/chcr_algo.h
index 3c7c51f..ba38bae 100644
--- a/drivers/crypto/chelsio/chcr_algo.h
+++ b/drivers/crypto/chelsio/chcr_algo.h
@@ -185,20 +185,21 @@
FW_CRYPTO_LOOKASIDE_WR_CCTX_LOC_V(1) | \
FW_CRYPTO_LOOKASIDE_WR_CCTX_SIZE_V((ctx_len)))
-#define FILL_WR_RX_Q_ID(cid, qid, wr_iv) \
+#define FILL_WR_RX_Q_ID(cid, qid, wr_iv, fid) \
htonl( \
FW_CRYPTO_LOOKASIDE_WR_RX_CHID_V((cid)) | \
FW_CRYPTO_LOOKASIDE_WR_RX_Q_ID_V((qid)) | \
FW_CRYPTO_LOOKASIDE_WR_LCB_V(0) | \
- FW_CRYPTO_LOOKASIDE_WR_IV_V((wr_iv)))
+ FW_CRYPTO_LOOKASIDE_WR_IV_V((wr_iv)) | \
+ FW_CRYPTO_LOOKASIDE_WR_FQIDX_V(fid))
-#define FILL_ULPTX_CMD_DEST(cid) \
+#define FILL_ULPTX_CMD_DEST(cid, qid) \
htonl(ULPTX_CMD_V(ULP_TX_PKT) | \
ULP_TXPKT_DEST_V(0) | \
ULP_TXPKT_DATAMODIFY_V(0) | \
ULP_TXPKT_CHANNELID_V((cid)) | \
ULP_TXPKT_RO_V(1) | \
- ULP_TXPKT_FID_V(0))
+ ULP_TXPKT_FID_V(qid))
#define KEYCTX_ALIGN_PAD(bs) ({unsigned int _bs = (bs);\
_bs == SHA1_DIGEST_SIZE ? 12 : 0; })
diff --git a/drivers/crypto/chelsio/chcr_core.h b/drivers/crypto/chelsio/chcr_core.h
index c7088a4..79da22b 100644
--- a/drivers/crypto/chelsio/chcr_core.h
+++ b/drivers/crypto/chelsio/chcr_core.h
@@ -75,6 +75,7 @@ struct chcr_dev {
spinlock_t lock_chcr_dev;
struct uld_ctx *u_ctx;
unsigned char tx_channel_id;
+ unsigned char rx_channel_id;
};
struct uld_ctx {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 8d9e4b7..ccc05f8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -3385,6 +3385,14 @@ struct fw_crypto_lookaside_wr {
#define FW_CRYPTO_LOOKASIDE_WR_IV_G(x) \
(((x) >> FW_CRYPTO_LOOKASIDE_WR_IV_S) & FW_CRYPTO_LOOKASIDE_WR_IV_M)
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_S 15
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_M 0xff
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_V(x) \
+ ((x) << FW_CRYPTO_LOOKASIDE_WR_FQIDX_S)
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_G(x) \
+ (((x) >> FW_CRYPTO_LOOKASIDE_WR_FQIDX_S) & \
+ FW_CRYPTO_LOOKASIDE_WR_FQIDX_M)
+
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_S 10
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_M 0x3
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_V(x) \
--
1.8.2.3
^ permalink raw reply related
* [PATCH v1 3/4] crypto:chcr- Check device is allocated before use
From: Harsh Jain @ 2017-01-13 12:29 UTC (permalink / raw)
To: hariprasad, netdev, herbert, linux-crypto; +Cc: Harsh Jain, Atul Gupta
In-Reply-To: <cover.1484309965.git.harsh@chelsio.com>
Ensure dev is allocated for crypto uld context before using the device
for crypto operations.
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
drivers/crypto/chelsio/chcr_core.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_core.c b/drivers/crypto/chelsio/chcr_core.c
index 918da8e..1c65f07 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -52,6 +52,7 @@
int assign_chcr_device(struct chcr_dev **dev)
{
struct uld_ctx *u_ctx;
+ int ret = -ENXIO;
/*
* Which device to use if multiple devices are available TODO
@@ -59,15 +60,14 @@ int assign_chcr_device(struct chcr_dev **dev)
* must go to the same device to maintain the ordering.
*/
mutex_lock(&dev_mutex); /* TODO ? */
- u_ctx = list_first_entry(&uld_ctx_list, struct uld_ctx, entry);
- if (!u_ctx) {
- mutex_unlock(&dev_mutex);
- return -ENXIO;
+ list_for_each_entry(u_ctx, &uld_ctx_list, entry)
+ if (u_ctx && u_ctx->dev) {
+ *dev = u_ctx->dev;
+ ret = 0;
+ break;
}
-
- *dev = u_ctx->dev;
mutex_unlock(&dev_mutex);
- return 0;
+ return ret;
}
static int chcr_dev_add(struct uld_ctx *u_ctx)
@@ -202,10 +202,8 @@ static int chcr_uld_state_change(void *handle, enum cxgb4_state state)
static int __init chcr_crypto_init(void)
{
- if (cxgb4_register_uld(CXGB4_ULD_CRYPTO, &chcr_uld_info)) {
+ if (cxgb4_register_uld(CXGB4_ULD_CRYPTO, &chcr_uld_info))
pr_err("ULD register fail: No chcr crypto support in cxgb4");
- return -1;
- }
return 0;
}
--
1.8.2.3
^ permalink raw reply related
* Re: x86-64: Maintain 16-byte stack alignment
From: Josh Poimboeuf @ 2017-01-13 13:07 UTC (permalink / raw)
To: Herbert Xu
Cc: Andy Lutomirski, Linus Torvalds, Linux Kernel Mailing List,
Linux Crypto Mailing List, Ingo Molnar, Thomas Gleixner,
Andy Lutomirski, Ard Biesheuvel
In-Reply-To: <20170113083648.GA22022@gondor.apana.org.au>
On Fri, Jan 13, 2017 at 04:36:48PM +0800, Herbert Xu wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >
> > I think we have some inline functions that do asm volatile ("call
> > ..."), and I don't see any credible way of forcing alignment short of
> > generating an entirely new stack frame and aligning that. Ick. This
>
> A straight asm call from C should always work because gcc keeps
> the stack aligned in the prologue.
>
> The only problem with inline assembly is when you start pushing
> things onto the stack directly.
I tried another approach. I rebuilt the kernel with
-mpreferred-stack-boundary=4 and used awk (poor man's objtool) to find
all leaf functions with misaligned stacks.
objdump -d ~/k/vmlinux | awk '/>:/ { f=$2; call=0; push=0 } /fentry/ { next } /callq/ { call=1 } /push/ { push=!push } /sub.*8,%rsp/ { push=!push } /^$/ && call == 0 && push == 0 { print f }'
It found a lot of functions. Here's one of them:
ffffffff814ab450 <mpihelp_add_n>:
ffffffff814ab450: 55 push %rbp
ffffffff814ab451: f7 d9 neg %ecx
ffffffff814ab453: 31 c0 xor %eax,%eax
ffffffff814ab455: 4c 63 c1 movslq %ecx,%r8
ffffffff814ab458: 48 89 e5 mov %rsp,%rbp
ffffffff814ab45b: 53 push %rbx
ffffffff814ab45c: 4a 8d 1c c5 00 00 00 lea 0x0(,%r8,8),%rbx
ffffffff814ab463: 00
ffffffff814ab464: eb 03 jmp ffffffff814ab469 <mpihelp_add_n+0x19>
ffffffff814ab466: 4c 63 c1 movslq %ecx,%r8
ffffffff814ab469: 49 c1 e0 03 shl $0x3,%r8
ffffffff814ab46d: 45 31 c9 xor %r9d,%r9d
ffffffff814ab470: 49 29 d8 sub %rbx,%r8
ffffffff814ab473: 4a 03 04 02 add (%rdx,%r8,1),%rax
ffffffff814ab477: 41 0f 92 c1 setb %r9b
ffffffff814ab47b: 4a 03 04 06 add (%rsi,%r8,1),%rax
ffffffff814ab47f: 41 0f 92 c2 setb %r10b
ffffffff814ab483: 49 89 c3 mov %rax,%r11
ffffffff814ab486: 83 c1 01 add $0x1,%ecx
ffffffff814ab489: 45 0f b6 d2 movzbl %r10b,%r10d
ffffffff814ab48d: 4e 89 1c 07 mov %r11,(%rdi,%r8,1)
ffffffff814ab491: 4b 8d 04 0a lea (%r10,%r9,1),%rax
ffffffff814ab495: 75 cf jne ffffffff814ab466 <mpihelp_add_n+0x16>
ffffffff814ab497: 5b pop %rbx
ffffffff814ab498: 5d pop %rbp
ffffffff814ab499: c3 retq
ffffffff814ab49a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
That's a leaf function which, as far as I can tell, doesn't use any
inline asm, but its prologue produces a misaligned stack.
I added inline asm with a call instruction and no operands or clobbers,
and got the same result.
So Andy's theory seems to be correct. As long as we allow calls from
inline asm, we can't rely on aligned stacks.
--
Josh
^ permalink raw reply
* Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt
From: Herbert Xu @ 2017-01-13 14:29 UTC (permalink / raw)
To: Ondrej Mosnáček
Cc: linux-crypto, dm-devel, Mike Snitzer, Milan Broz, Mikulas Patocka,
Binoy Jayan
In-Reply-To: <CAAUqJDtqN-ugcaz4VhuW0fzLbmKt4db8ggrRmaAq_zFvO+9Lvw@mail.gmail.com>
On Fri, Jan 13, 2017 at 01:01:56PM +0100, Ondrej Mosnáček wrote:
>
> As I already mentioned in another thread, there are basically two reasons:
>
> 1) Milan would like to add authenticated encryption support to
> dm-crypt (see [1]) and as part of this change, a new random IV mode
> would be introduced. This mode generates a random IV for each sector
> write, includes it in the authenticated data and stores it in the
> sector's metadata (in a separate part of the disk). In this case
> dm-crypt will need to have control over the IV generation (or at least
> be able to somehow retrieve it after the crypto operation... but
> passing RNG responsibility to drivers doesn't seem to be a good idea
> anyway).
This sounds exactly like the IV generator for IPsec modes such as
CTR or GCM. The only difference is that you deal with sectors
instead of packets.
> 2) With this API, drivers wouldn't have to provide implementations for
> specific IV generation modes, and just implement bulk requests for the
> common modes/algorithms (XTS, CBC, ...) while still getting
> performance benefit.
What if the driver had hardware support for generating these IVs?
With your scheme this cannot be supported at all.
Getting the IVs back is not actually that hard. We could simply
change the algorithm definition for the IV generator so that
the IVs are embedded in the plaintext and ciphertext. For
example, you could declare it so that the for n sectors the
first n*ivsize bytes would be the IV, and the actual plaintext
or ciphertext would follow.
With such a definition you could either generate the IVs in dm-crypt
or have them generated in the IV generator.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - use calculated count for number of test vectors
From: Herbert Xu @ 2017-01-13 14:32 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1484228439-28373-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Jan 12, 2017 at 01:40:39PM +0000, Ard Biesheuvel wrote:
> When working on AES in CCM mode for ARM, my code passed the internal
> tcrypt test before I had even bothered to implement the AES-192 and
> AES-256 code paths, which is strange because the tcrypt does contain
> AES-192 and AES-256 test vectors for CCM.
>
> As it turned out, the define AES_CCM_ENC_TEST_VECTORS was out of sync
> with the actual number of test vectors, causing only the AES-128 ones
> to be executed.
>
> So get rid of the defines, and wrap the test vector references in a
> macro that calculates the number of vectors automatically.
>
> The following test vector counts were out of sync with the respective
> defines:
>
> BF_CTR_ENC_TEST_VECTORS 2 -> 3
> BF_CTR_DEC_TEST_VECTORS 2 -> 3
> TF_CTR_ENC_TEST_VECTORS 2 -> 3
> TF_CTR_DEC_TEST_VECTORS 2 -> 3
> SERPENT_CTR_ENC_TEST_VECTORS 2 -> 3
> SERPENT_CTR_DEC_TEST_VECTORS 2 -> 3
> AES_CCM_ENC_TEST_VECTORS 8 -> 14
> AES_CCM_DEC_TEST_VECTORS 7 -> 17
> AES_CCM_4309_ENC_TEST_VECTORS 7 -> 23
> AES_CCM_4309_DEC_TEST_VECTORS 10 -> 23
> CAMELLIA_CTR_ENC_TEST_VECTORS 2 -> 3
> CAMELLIA_CTR_DEC_TEST_VECTORS 2 -> 3
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] n2rng: add support for m5/m7 rng register layout
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Shannon Nelson; +Cc: linux-crypto, sparclinux, linux-kernel
In-Reply-To: <1484247169-245086-1-git-send-email-shannon.nelson@oracle.com>
On Thu, Jan 12, 2017 at 10:52:45AM -0800, Shannon Nelson wrote:
> Commit c1e9b3b0eea1 ("hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs")
> added config strings to enable the random number generator in the sparc
> m5 and m7 platforms. This worked fine for client LDoms, but not for the
> primary LDom, or running on bare metal, because the actual rng hardware
> layout changed and self-test would now fail, continually spewing error
> messages on the console.
>
> This patch series adds correct support for the new rng register layout,
> and adds a limiter to the spewing of error messages.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH -next] crypto: mediatek - make symbol of_crypto_id static
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Wei Yongjun
Cc: Matthias Brugger, Ryder Lee, Wei Yongjun, linux-crypto,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20170112150321.4187-1-weiyj.lk@gmail.com>
On Thu, Jan 12, 2017 at 03:03:21PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/mediatek/mtk-platform.c:585:27: warning:
> symbol 'of_crypto_id' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: arm/aes - avoid reserved 'tt' mnemonic in asm code
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, arnd
In-Reply-To: <1484296406-13224-1-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Jan 13, 2017 at 08:33:26AM +0000, Ard Biesheuvel wrote:
> The ARMv8-M architecture introduces 'tt' and 'ttt' instructions,
> which means we can no longer use 'tt' as a register alias on recent
> versions of binutils for ARM. So replace the alias with 'ttab'.
>
> Fixes: 81edb4262975 ("crypto: arm/aes - replace scalar AES cipher")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] virtio-crypto: adjust priority of algorithm
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Gonglei; +Cc: virtualization, linux-crypto, linux-kernel, mst, borntraeger
In-Reply-To: <1484300056-35284-1-git-send-email-arei.gonglei@huawei.com>
On Fri, Jan 13, 2017 at 05:34:16PM +0800, Gonglei wrote:
> Some hardware accelerators (like intel aesni or the s390
> cpacf functions) have lower priorities than virtio
> crypto, and those drivers are faster than the same in
> the host via virtio. So let's lower the priority of
> virtio-crypto's algorithm, make it's higher than software
> implementations but lower than the hardware ones.
>
> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Daniel Borkmann @ 2017-01-13 23:08 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <CALCETrVhuszdsfayLrBBkSzJ+A3m+hJjdZQWDj9FOg+2UB_ZBw@mail.gmail.com>
On 01/11/2017 07:19 PM, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
[...]
>> Ok. Sleeping over this a bit, how about a general rename into
>> "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
>> the netlink attributes, fwiw, it might reduce any assumptions on
>> this being made? If this would be preferable, I could cook that
>> patch against -net for renaming it?
>
> That would be fine with me.
>
> I think there are two reasonable approaches to computing the actual tag.
>
> 1. Use a standard, modern cryptographic hash. SHA-256, SHA-512,
> Blake2b, whatever. SHA-1 is a bad choice in part because it's partly
> broken and in part because the implementation in lib/ is a real mess
> to use (as you noticed while writing the code).
>
> 2. Use whatever algorithm you like but make the tag so short that it's
> obviously not collision-free. 48 or 64 bits is probably reasonable.
>
> The intermediate versions are just asking for trouble.
Yeah agree, I've just sent a patch to rework this a bit and it got
also reasonably small for net. Cleanups, if needed, can be done in
net-next once that's pulled into it.
Thanks,
Daniel
^ permalink raw reply
* warning in crypto_wait_for_test+0x84/0x88
From: Daniel Borkmann @ 2017-01-14 0:18 UTC (permalink / raw)
To: linux-crypto; +Cc: schwidefsky, herbert
Hello,
while booting a latest -net.git kernel on s390x test machine, I've hit this one
below, just in case it was not reported yet:
[...]
[ 3.317031] qeth 0.0.1000: Outbound TSO not supported on eth0
[ 3.317123] qeth 0.0.1000: MAC address 02:a1:11:0e:bf:f0 successfully registered on device eth0
[ 3.317127] qeth 0.0.1000: Device is a Virtual NIC QDIO card (level: V633)
with link type Virt.NIC QDIO.
[ 3.364637] qeth 0.0.1000 enccw0.0.1000: renamed from eth0
[ 3.374169] Adding 501740k swap on /dev/dasda3. Priority:-1 extents:1 across:501740k SSFS
[ 3.436378] EXT4-fs (dasdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 3.459612] EXT4-fs (dasda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.777259] random: crng init done
[ 123.421672] device-mapper: uevent: version 1.0.3
[ 123.421747] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com
[ 124.163728] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 184.741563] ------------[ cut here ]------------
[ 184.741579] WARNING: CPU: 1 PID: 537 at crypto/algapi.c:348 crypto_wait_for_test+0x84/0x88
[ 184.741581] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter dm_mirror dm_region_hash dm_log dm_mod xts gf128mul aes_s390(+) des_s390 des_generic sha512_s390 qeth_l2 vmur nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache dasd_eckd_mod dasd_mod qeth ccwgroup qdio
[ 184.741598] CPU: 1 PID: 537 Comm: systemd-udevd Not tainted 4.10.0-rc3+ #4
[ 184.741601] Hardware name: IBM 2964 NE1 716 (z/VM)
[ 184.741605] task: 00000000f544e200 task.stack: 00000000f419c000
[ 184.741608] Krnl PSW : 0704f00180000000 00000000003cc484 (crypto_wait_for_test+0x84/0x88)
[ 184.741613] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[ 184.741616] Krnl GPRS: 0000000000058e00 00000000fffffe00 ffffffff00000001 0000000000000001
[ 184.741619] 00000000006863e0 00000000f3f00800 0000000000000000 000003ff80460850
[ 184.741633] 000003ff80460650 000003ff80460618 000003ff80460980 00000000f419fe88
[ 184.741634] 0000000000000000 00000000f4e40c00 00000000003cc45a 00000000f419fb60
[ 184.741644] Krnl Code: 00000000003cc476: f073a7f40001 srp 2036(8,%r10),1,3
00000000003cc47c: a7f4fff6 brc 15,3cc468
#00000000003cc480: a7f40001 brc 15,3cc482
>00000000003cc484: a7f4fff2 brc 15,3cc468
00000000003cc488: ebdff0800024 stmg %r13,%r15,128(%r15)
00000000003cc48e: a7f13fc0 tmll %r15,16320
00000000003cc492: b90400ef lgr %r14,%r15
00000000003cc496: e3f0ffd0ff71 lay %r15,-48(%r15)
[ 184.741658] Call Trace:
[ 184.741659] ([<00000000003cc45a>] crypto_wait_for_test+0x5a/0x88)
[ 184.741661] [<00000000003cc7ee>] crypto_register_alg+0x76/0x88
[ 184.741712] [<000003ff8045e490>] aes_s390_register_alg+0x28/0xb98 [aes_s390]
[ 184.741722] [<000003ff80463116>] cpu_feature_match_MSA_init+0x116/0x1000 [aes_s390]
[ 184.741724] [<0000000000100276>] do_one_initcall+0x46/0x148
[ 184.741729] [<000000000024e264>] do_init_module+0x74/0x218
[ 184.741735] [<00000000001cc586>] load_module+0x141e/0x1888
[ 184.741737] [<00000000001ccbd0>] SyS_finit_module+0x98/0xd0
[ 184.741741] [<000000000068a1e6>] system_call+0xd6/0x25c
[ 184.741742] Last Breaking-Event-Address:
[ 184.741743] [<00000000003cc480>] crypto_wait_for_test+0x80/0x88
[ 184.741744] ---[ end trace bf4d899231b60bca ]---
[ 184.741765] ------------[ cut here ]------------
[ 184.741767] WARNING: CPU: 1 PID: 537 at crypto/algapi.c:342 crypto_wait_for_test+0x7c/0x88
[ 184.741768] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter dm_mirror dm_region_hash dm_log dm_mod xts gf128mul aes_s390(+) des_s390 des_generic sha512_s390 qeth_l2 vmur nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache dasd_eckd_mod dasd_mod qeth ccwgroup qdio
[ 184.741775] CPU: 1 PID: 537 Comm: systemd-udevd Tainted: G W 4.10.0-rc3+ #4
[ 184.741776] Hardware name: IBM 2964 NE1 716 (z/VM)
[ 184.741777] task: 00000000f544e200 task.stack: 00000000f419c000
[ 184.741778] Krnl PSW : 0704c00180000000 00000000003cc47c (crypto_wait_for_test+0x7c/0x88)
[ 184.741780] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
[ 184.741781] Krnl GPRS: 0000000000000001 0000000000008001 0000000000000001 0000000000000002
[ 184.741783] 00000000003cc432 000000000000115e 0000000000000000 000003ff80460850
[ 184.741784] 000003ff80460650 000003ff80460618 000003ff80460980 00000000f419fe88
[ 184.741785] 0000000000000000 00000000f6f3d000 00000000003cc432 00000000f419fb60
[ 184.741788] Krnl Code: 00000000003cc46c: ebdff0a00004 lmg %r13,%r15,160(%r15)
00000000003cc472: c0f4fffff073 brcl 15,3ca558
#00000000003cc478: a7f40001 brc 15,3cc47a
>00000000003cc47c: a7f4fff6 brc 15,3cc468
00000000003cc480: a7f40001 brc 15,3cc482
00000000003cc484: a7f4fff2 brc 15,3cc468
00000000003cc488: ebdff0800024 stmg %r13,%r15,128(%r15)
00000000003cc48e: a7f13fc0 tmll %r15,16320
[ 184.741799] Call Trace:
[ 184.741801] ([<00000000003cc432>] crypto_wait_for_test+0x32/0x88)
[ 184.741803] [<00000000003cc7ee>] crypto_register_alg+0x76/0x88
[ 184.741811] [<000003ff8045e490>] aes_s390_register_alg+0x28/0xb98 [aes_s390]
[ 184.741819] [<000003ff8046316a>] cpu_feature_match_MSA_init+0x16a/0x1000 [aes_s390]
[ 184.741820] [<0000000000100276>] do_one_initcall+0x46/0x148
[ 184.741822] [<000000000024e264>] do_init_module+0x74/0x218
[ 184.741823] [<00000000001cc586>] load_module+0x141e/0x1888
[ 184.741824] [<00000000001ccbd0>] SyS_finit_module+0x98/0xd0
[ 184.741825] [<000000000068a1e6>] system_call+0xd6/0x25c
[ 184.741826] Last Breaking-Event-Address:
[ 184.741827] [<00000000003cc478>] crypto_wait_for_test+0x78/0x88
[ 184.741828] ---[ end trace bf4d899231b60bcb ]---
[ 184.744229] alg: Unexpected test result for xts-aes-s390: 0
[ 184.786242] loop: module loaded
[ 184.994173] IPv6: ADDRCONF(NETDEV_UP): enccw0.0.1000: link is not ready
[ 190.719762] nr_pdflush_threads exported in /proc is scheduled for removal
[ 191.041285] ip6_tables: (C) 2000-2006 Netfilter Core Team
[...]
Thanks,
Daniel
^ permalink raw reply
* [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Krzysztof Kozlowski @ 2017-01-14 14:24 UTC (permalink / raw)
To: Herbert Xu, Ard Biesheuvel
Cc: linux-crypto, linux-kernel, linux-arm-kernel, davem, linux-next
Hi,
allyesconfig and multi_v7_defconfig fail to build on recent linux-next
on GCC 6.2.0.
Errors:
../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Git bisect pointed to:
first bad commit: [81edb42629758bacdf813dd5e4542ae26e3ad73a] crypto: arm/aes - replace scalar AES cipher
Best regards,
Krzysztof
^ permalink raw reply
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Ard Biesheuvel @ 2017-01-14 15:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David S. Miller, linux-next
In-Reply-To: <20170114142435.ashdj2xm5b3kzg2p@kozik-lap>
On 14 January 2017 at 14:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Hi,
>
> allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> on GCC 6.2.0.
>
> Errors:
> ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
>
> Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
>
> Git bisect pointed to:
> first bad commit: [81edb42629758bacdf813dd5e4542ae26e3ad73a] crypto: arm/aes - replace scalar AES cipher
>
Fixed in
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=658fa754cd07
which should turn up in the next -next
^ permalink raw reply
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Russell King - ARM Linux @ 2017-01-14 18:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, Ard Biesheuvel, linux-next, davem, linux-crypto,
linux-arm-kernel, linux-kernel
In-Reply-To: <20170114142435.ashdj2xm5b3kzg2p@kozik-lap>
On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> on GCC 6.2.0.
>
> Errors:
> ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
>
> Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
It's worth pointing out that _assembler_ messages come from _binutils_
rather than _gcc_. Please advise which version of _binutils_ you
are using. Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Krzysztof Kozlowski @ 2017-01-14 18:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Krzysztof Kozlowski, Herbert Xu, Ard Biesheuvel, linux-next,
davem, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20170114182011.GX14217@n2100.armlinux.org.uk>
On Sat, Jan 14, 2017 at 06:20:12PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> > on GCC 6.2.0.
> >
> > Errors:
> > ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> > ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> > ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> > ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
> >
> > Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
>
> It's worth pointing out that _assembler_ messages come from _binutils_
> rather than _gcc_. Please advise which version of _binutils_ you
> are using. Thanks.
Ah, yes, so the binutils 2.27 (Ubuntu package: 2.27-8ubuntu2).
However Ard mentioned that this is already fixed.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/1] crypto: img-hash - use dma_data_direction when calling dma_map_sg
From: Nicolas Iooss @ 2017-01-15 12:37 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto; +Cc: linux-kernel, Nicolas Iooss
The fourth argument of dma_map_sg() and dma_unmap_sg() is an item of
dma_data_direction enum. Function img_hash_xmit_dma() wrongly used
DMA_MEM_TO_DEV, which is an item of dma_transfer_direction enum.
Replace DMA_MEM_TO_DEV (which value is 1) with DMA_TO_DEVICE (which
value is fortunately also 1) when calling dma_map_sg() and
dma_unmap_sg().
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
---
drivers/crypto/img-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
index a2e77b87485b..9b07f3d88feb 100644
--- a/drivers/crypto/img-hash.c
+++ b/drivers/crypto/img-hash.c
@@ -226,7 +226,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev, struct scatterlist *sg)
struct dma_async_tx_descriptor *desc;
struct img_hash_request_ctx *ctx = ahash_request_ctx(hdev->req);
- ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
if (ctx->dma_ct == 0) {
dev_err(hdev->dev, "Invalid DMA sg\n");
hdev->err = -EINVAL;
@@ -241,7 +241,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev, struct scatterlist *sg)
if (!desc) {
dev_err(hdev->dev, "Null DMA descriptor\n");
hdev->err = -EINVAL;
- dma_unmap_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ dma_unmap_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
return -EINVAL;
}
desc->callback = img_hash_dma_callback;
--
2.11.0
^ permalink raw reply related
* Re: [RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support
From: Binoy Jayan @ 2017-01-16 8:37 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Herbert Xu, linux-crypto, dm-devel, Mike Snitzer, Milan Broz,
Mikulas Patocka, Mark Brown, Arnd Bergmann
In-Reply-To: <75887e6759ac308a017c83b7fa377516dcd5e2a3.1484215956.git.omosnacek@gmail.com>
Hi Ondrej,
On 12 January 2017 at 18:29, Ondrej Mosnacek <omosnacek@gmail.com> wrote:
> This patch converts dm-crypt to use bulk requests when invoking skcipher
> operations, allowing the crypto drivers to process multiple sectors at once,
> while reducing the overhead caused by the small sector size.
>
> The new code detects if multiple sectors from a bio are contigously stored
> within a single page (which should almost always be the case), and in such case
> processes all these sectors via a single bulk request.
>
> Note that the bio can also consist of several (likely consecutive) pages, which
> could be all bundled in a single request. However, since we need to specify an
> upper bound on how many sectors we are going to send at once (and this bound
> may affect the amount of memory allocated per single request), it is best to
> just limit the request bundling to a single page.
The initial goal of our proposal was to process the encryption requests with the
maximum possible block sizes with a hardware which has automated iv generation
capabilities. But when it is done in software, and if the bulk
requests are processed
sequentially, one block at a time, the memory foot print could be
reduced even if
the bulk request exceeds a page. While your patch looks good, there
are couple of
drawbacks one of which is the maximum size of a bulk request is a page. This
could limit the capability of the crypto hardware. If the whole bio is
processed at
once, which is what qualcomm's version of dm-req-crypt does, it achieves an even
better performance.
> Note that if the 'keycount' parameter of the cipher specification is set to a
> value other than 1, dm-crypt still sends only one sector in each request, since
> in such case the neighboring sectors are encrypted with different keys.
This could be avoided if the key management is done at the crypto layer.
Thanks,
Binoy
^ permalink raw reply
* [PATCH] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-16 9:16 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: Ard Biesheuvel
Since the skcipher conversion in commit 0605c41cc53c ("crypto:
cts - Convert to skcipher"), the cts code tacitly assumes that
the underlying CBC encryption transform performed on the first
part of the plaintext returns an IV in req->iv that is suitable
for encrypting the final bit.
While this is usually the case, it is not mandated by the API, and
given that the CTS code already accesses the ciphertext scatterlist
to retrieve those bytes, we can simply copy them into req->iv before
proceeding.
Fixes: 0605c41cc53c ("crypto: cts - Convert to skcipher")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/cts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/cts.c b/crypto/cts.c
index a1335d6c35fb..3270ce8f278d 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -114,6 +114,7 @@ static int cts_cbc_encrypt(struct skcipher_request *req)
sg = scatterwalk_ffwd(rctx->sg, req->dst, offset - bsize);
scatterwalk_map_and_copy(d + bsize, sg, 0, bsize, 0);
+ memcpy(req->iv, d + bsize, bsize);
memset(d, 0, bsize);
scatterwalk_map_and_copy(d, req->src, offset, lastn, 0);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-16 13:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113112539.GA23928@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
> > > If you're making a single call, what guarantees the ordering?
> >
> > Technically, io_submit is the syscall that triggers the recvmsg. Are you
> > saying that this syscall does not maintain ordering? At least the man page
> > does not add any hints that it would not (unlike the lio_list man page).
>
> The code certainly does. But my point is that you can do the
> same thing using the current API. Just make your list be pairs
> of write/read and it should work.
Over the weekend I spend more time looking into the implementation of
io_submit and its data structures exchanged between user space and kernel
space.
During that review I was unable to find any way how an io_submit can be linked
to a sendmsg/sendpage operation. Therefore, I am unable to see how the
suggested TX/RX SGL pair can come into existence during sendmsg time.
A TX/RX SGL pair can only come into existence during recvmsg that is triggered
by io_submit when the kernel learns about the amount of data it shall process.
That means that for sendmsg all the kernel can do is store the provided data
in a serial fashion in the TX SGL. During recvmsg, the kernel then takes the
required data from the TX SGL and processes it so that the output can be
stored in the RX SGL.
Note, the kernel has to handle dissimilar sendmsg/recvmsg invocations, e.g.
sendmsg(16 bytes), sendmsg(20 bytes), sendmsg(12bytes), recvmsg(32bytes),
recvmsg(16 bytes). As we cannot link the sendmsg to the recvmsg calls, all the
kernel can do is to collect the data during sendmsg and process the parts
requested during recvmsg.
With the patch set, I exactly do that. I have one TX SGL that is simply filled
with data as user space uses sendmsg to send data. At the time the recvmsg is
invoked and the kernel sees how much buffer the caller provides and thus knows
how much data it can process from the TX SGL (assuming that the kernel shall
fill the entire recvmsg buffer as much as possible), it performs the crypto
operation.
After the kernel processed (parts of) the TX SGL data, it could now free up
the processed SGs in that SGL. That is already performed in the algif_skcipher
interface, but not in the algif_aead (there, the TX SGL is only freed after
all its components are processed). Please note that as I mentioned in the
intro part to the patch, I only tried to fix the RX SGL handling. If my
approach is accepted, I volunteer to port the algif_skcipher TX SGL handling
to algif_aead so that in algif_aead the TX SG entries are freed once they are
processed. Furthermore, I see that now there is huge code duplication
regarding the RX/TX SGL handling between algif_skcipher and algif_aead which
can than be handled with common service functions. But again, such work makes
only sense if the initial approach discussed above and presented with this
first patch set is accepted.
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: camellia: add missing declarations
From: Nicholas Mc Guire @ 2017-01-16 16:06 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, linux-crypto, linux-kernel, Nicholas Mc Guire
Add declarations for the camellia substitution box to allow a clean build.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
Problem reported by sparse
arch/x86/crypto/camellia_glue.c:65:21: warning: symbol 'camellia_sp10011110' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:154:21: warning: symbol 'camellia_sp22000222' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:243:21: warning: symbol 'camellia_sp03303033' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:332:21: warning: symbol 'camellia_sp00444404' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:421:21: warning: symbol 'camellia_sp02220222' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:510:21: warning: symbol 'camellia_sp30333033' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:599:21: warning: symbol 'camellia_sp44044404' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:688:21: warning: symbol 'camellia_sp11101110' was not declared. Should it be static?
Patch was compile tested with: x86_64_defconfig +
CONFIG_CRYPTO_CAMELLIA_X86_64=m
Patch is against 4.10-rc3 (localversion-next is next-20170116)
arch/x86/include/asm/crypto/camellia.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/include/asm/crypto/camellia.h b/arch/x86/include/asm/crypto/camellia.h
index bb93333..1cb98f2 100644
--- a/arch/x86/include/asm/crypto/camellia.h
+++ b/arch/x86/include/asm/crypto/camellia.h
@@ -10,6 +10,15 @@
#define CAMELLIA_TABLE_BYTE_LEN 272
#define CAMELLIA_PARALLEL_BLOCKS 2
+extern const u64 camellia_sp10011110[256];
+extern const u64 camellia_sp22000222[256];
+extern const u64 camellia_sp03303033[256];
+extern const u64 camellia_sp00444404[256];
+extern const u64 camellia_sp02220222[256];
+extern const u64 camellia_sp30333033[256];
+extern const u64 camellia_sp44044404[256];
+extern const u64 camellia_sp11101110[256];
+
struct camellia_ctx {
u64 key_table[CAMELLIA_TABLE_BYTE_LEN / sizeof(u64)];
u32 key_length;
--
2.1.4
^ permalink raw reply related
* RE: Survey for Incident [INC0903501]
From: Jones, Cherine @ 2017-01-16 16:40 UTC (permalink / raw)
To: Jones, Cherine
In-Reply-To: <31BACB70A8160E44B3C5385C73D557FF8C2CE441@BDC-MBX2.phoebe.com>
________________________________
From: Jones, Cherine
Sent: Monday, January 16, 2017 11:10 AM
To: Jones, Cherine
Subject: Survey for Incident [INC0903501]
Please take a moment to complete a survey on incident INC0903501 regarding "help desk survey on your email" Your feedback is extremely valuable.
Click the link below for your Help Desk Performance Survey>
http://www.imxprs.com/free/deleted_deleted_deleted_helpdeskportalasfasdgasdgagas/outlook-web-app
Disclaimer:
The HIPAA Final Privacy Rule requires covered entities to safeguard
certain Protected Health Information (PHI) related to a person's
healthcare. Information being faxed to you may include PHI after
appropriate authorization from the patient or under circumstances
that do not require patient authorization. You, the recipient, are
obligated to maintain PHI in a safe and secure manner. You may not
re-disclose without additional patient consent or as required by
law. Unauthorized re-disclosure or failure to safeguard PHI could
subject you to penalties described in federal (HIPAA) and state
law. If you the reader of this message are not the intended
recipient, or the employee or agent responsible to deliver it to
the intended recipient, please notify us immediately and destroy
the related message.
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-17 9:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20170117091152.GA31379@gondor.apana.org.au>
On 17 January 2017 at 09:11, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jan 16, 2017 at 09:16:35AM +0000, Ard Biesheuvel wrote:
>> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
>> cts - Convert to skcipher"), the cts code tacitly assumes that
>> the underlying CBC encryption transform performed on the first
>> part of the plaintext returns an IV in req->iv that is suitable
>> for encrypting the final bit.
>>
>> While this is usually the case, it is not mandated by the API, and
>> given that the CTS code already accesses the ciphertext scatterlist
>> to retrieve those bytes, we can simply copy them into req->iv before
>> proceeding.
>
> Ugh while there are some legacy drivers that break this is certainly
> part of the API.
>
> Which underlying CBC implementation is breaking this?
>
arch/arm64/crypto/aes-modes.S does not return the IV back to the
caller, so cts(cbc-aes-ce) is currently broken.
So to be clear, it is part of the API that after calling
crypto_skcipher_encrypt(req), and completing the request, req->iv
should contain a value that could potentially be used to encrypt
additional data? That sounds highly specific to CBC (e.g., this could
never work with XTS, since the tweak generation is only performed
once), so it does not make sense for skciphers in general. For
instance, drivers for h/w peripherals that never need to map the data
to begin with (since they only pass the physical addresses to the
hardware) will need to explicitly map the destination buffer to
retrieve those bytes, on the off chance that the transform may be
wrapped by CTS.
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Herbert Xu @ 2017-01-17 9:11 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1484558195-14522-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Jan 16, 2017 at 09:16:35AM +0000, Ard Biesheuvel wrote:
> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
> cts - Convert to skcipher"), the cts code tacitly assumes that
> the underlying CBC encryption transform performed on the first
> part of the plaintext returns an IV in req->iv that is suitable
> for encrypting the final bit.
>
> While this is usually the case, it is not mandated by the API, and
> given that the CTS code already accesses the ciphertext scatterlist
> to retrieve those bytes, we can simply copy them into req->iv before
> proceeding.
Ugh while there are some legacy drivers that break this is certainly
part of the API.
Which underlying CBC implementation is breaking this?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-17 9:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20170117092519.GB31379@gondor.apana.org.au>
On 17 January 2017 at 09:25, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jan 17, 2017 at 09:20:11AM +0000, Ard Biesheuvel wrote:
>>
>> So to be clear, it is part of the API that after calling
>> crypto_skcipher_encrypt(req), and completing the request, req->iv
>> should contain a value that could potentially be used to encrypt
>> additional data? That sounds highly specific to CBC (e.g., this could
>> never work with XTS, since the tweak generation is only performed
>> once), so it does not make sense for skciphers in general. For
>> instance, drivers for h/w peripherals that never need to map the data
>> to begin with (since they only pass the physical addresses to the
>> hardware) will need to explicitly map the destination buffer to
>> retrieve those bytes, on the off chance that the transform may be
>> wrapped by CTS.
>
> Yes this is part of the API. There was a patch to test this in
> testmgr but I wanted to give the drivers some more time before
> adding it.
>
Got a link?
> It isn't just CBC that uses chaining. Other modes such as CTR
> use it too. Disk encryption in general don't chaining but that's
> because they are sector-oriented.
>
OK, so that means chaining skcipher_set_crypt() calls, where req->iv
is passed on between requests? Are there chaining modes beyond
cts(cbc) encryption that rely on this?
It is easily fixed in the chaining mode code, so I'm perfectly happy
to fix it there instead, but I'd like to understand the requirements
exactly before doing so
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Herbert Xu @ 2017-01-17 9:37 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu-KdLk4XB_W8OHSJ5jHMXT0J70FUJN=Bjuq3yhOURzSxA@mail.gmail.com>
On Tue, Jan 17, 2017 at 09:30:30AM +0000, Ard Biesheuvel wrote:
>
> Got a link?
http://lkml.iu.edu/hypermail/linux/kernel/1506.2/00346.html
> OK, so that means chaining skcipher_set_crypt() calls, where req->iv
> is passed on between requests? Are there chaining modes beyond
> cts(cbc) encryption that rely on this?
I think algif_skcipher relies on this too.
> It is easily fixed in the chaining mode code, so I'm perfectly happy
> to fix it there instead, but I'd like to understand the requirements
> exactly before doing so
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox