From: Eric Biggers <ebiggers@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 4/16] crypto: xts - Convert to skcipher
Date: Sun, 13 Nov 2016 18:10:29 -0800 [thread overview]
Message-ID: <20161114021029.GC4778@google.com> (raw)
In-Reply-To: <E1c5tE7-00029P-L0@gondolin.me.apana.org.au>
On Sun, Nov 13, 2016 at 07:45:35PM +0800, Herbert Xu wrote:
> +static int do_encrypt(struct skcipher_request *req, int err)
> +{
> + struct rctx *rctx = skcipher_request_ctx(req);
> + struct skcipher_request *subreq;
> +
> + subreq = &rctx->subreq;
> +
> + while (!err && rctx->left) {
> + err = pre_crypt(req) ?:
> + crypto_skcipher_encrypt(subreq) ?:
> + post_crypt(req);
> +
> + if (err == -EINPROGRESS ||
> + (err == -EBUSY &&
> + req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
> + return err;
> + }
> +
> + exit_crypt(req);
> + return err;
> +}
> +
> +static void encrypt_done(struct crypto_async_request *areq, int err)
> +{
> + struct skcipher_request *req = areq->data;
> + struct skcipher_request *subreq;
> + struct rctx *rctx;
> +
> + rctx = skcipher_request_ctx(req);
> + subreq = &rctx->subreq;
> + subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
> +
> + err = do_encrypt(req, err ?: post_crypt(req));
> + if (rctx->left)
> + return;
> +
> + skcipher_request_complete(req, err);
> +}
> +
> +static int encrypt(struct skcipher_request *req)
> +{
> + return do_encrypt(req, init_crypt(req, encrypt_done));
> +}
> +
> +static int do_decrypt(struct skcipher_request *req, int err)
> +{
> + struct rctx *rctx = skcipher_request_ctx(req);
> + struct skcipher_request *subreq;
> +
> + subreq = &rctx->subreq;
> +
> + while (!err && rctx->left) {
> + err = pre_crypt(req) ?:
> + crypto_skcipher_decrypt(subreq) ?:
> + post_crypt(req);
> +
> + if (err == -EINPROGRESS ||
> + (err == -EBUSY &&
> + req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
> + return err;
> + }
> +
> + exit_crypt(req);
> + return err;
> +}
> +
> +static void decrypt_done(struct crypto_async_request *areq, int err)
> +{
> + struct skcipher_request *req = areq->data;
> + struct skcipher_request *subreq;
> + struct rctx *rctx;
> +
> + rctx = skcipher_request_ctx(req);
> + subreq = &rctx->subreq;
> + subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
> +
> + err = do_decrypt(req, err ?: post_crypt(req));
> + if (rctx->left)
> + return;
> +
> + skcipher_request_complete(req, err);
> +}
> +
> +static int decrypt(struct skcipher_request *req)
> +{
> + return do_decrypt(req, init_crypt(req, decrypt_done));
> }
There's duplicated code for encryption and decryption here. AFAICS, the only
difference between XTS encryption and decryption is whether the block cipher is
used in encryption or decryption mode for the ECB step. So I suggest storing a
function pointer in 'struct rctx' to either crypto_skcipher_encrypt or
crypto_skcipher_decrypt, then calling through it for the ECB step. Then this
code can be shared. In other words I'd like the top-level functions to look
like this:
static int encrypt(struct skcipher_request *req)
{
struct rctx *rctx = skcipher_request_ctx(req);
rctx->crypt = crypto_skcipher_encrypt;
return do_crypt(req);
}
static int decrypt(struct skcipher_request *req)
{
struct rctx *rctx = skcipher_request_ctx(req);
rctx->crypt = crypto_skcipher_decrypt;
return do_crypt(req);
}
I'm also wondering about the line which does
'subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;'.
Is the real intent of that to clear the CRYPTO_TFM_REQ_MAY_SLEEP flag because
the completion callback may be called in an atomic context, and if so shouldn't
it just clear that flag only, rather than all flags except
CRYPTO_TFM_REQ_MAY_BACKLOG?
> + if (req->cryptlen > XTS_BUFFER_SIZE) {
> + subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
> + rctx->ext = kmalloc(subreq->cryptlen, gfp);
> + }
There's no check for failure to allocate the 'rctx->ext' memory.
> + /* Alas we screwed up the naming so we have to mangle the
> + * cipher name.
> + */
> + if (!strncmp(cipher_name, "ecb(", 4)) {
> + unsigned len;
>
> - inst->alg.cra_ctxsize = sizeof(struct priv);
> + len = strlcpy(ctx->name, cipher_name + 4, sizeof(ctx->name));
> + if (len < 2 || len >= sizeof(ctx->name))
> + goto err_drop_spawn;
>
> - inst->alg.cra_init = init_tfm;
> - inst->alg.cra_exit = exit_tfm;
> + if (ctx->name[len - 1] != ')')
> + goto err_drop_spawn;
>
> - inst->alg.cra_blkcipher.setkey = setkey;
> - inst->alg.cra_blkcipher.encrypt = encrypt;
> - inst->alg.cra_blkcipher.decrypt = decrypt;
> + ctx->name[len - 1] = 0;
>
> -out_put_alg:
> - crypto_mod_put(alg);
> - return inst;
> -}
> + if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME,
> + "xts(%s)", ctx->name) >= CRYPTO_MAX_ALG_NAME)
> + return -ENAMETOOLONG;
> + } else
> + goto err_drop_spawn;
There should be a line which sets 'err = -EINVAL' before here.
> +static int init_crypt(struct skcipher_request *req, crypto_completion_t done)
> {
> - struct priv *ctx = crypto_blkcipher_ctx(desc->tfm);
> - struct blkcipher_walk w;
> + struct priv *ctx = crypto_skcipher_ctx(crypto_skcipher_reqtfm(req));
> + struct rctx *rctx = skcipher_request_ctx(req);
> + struct skcipher_request *subreq;
> + be128 *buf;
...
> + /* calculate first value of T */
> + buf = rctx->ext ?: rctx->buf;
> + crypto_cipher_encrypt_one(ctx->tweak, (u8 *)&rctx->t, req->iv);
> +
> + return 0;
The 'buf' variable is assigned to but never used.
> int xts_crypt(struct blkcipher_desc *desc, struct scatterlist *sdst,
> @@ -233,112 +416,167 @@ int xts_crypt(struct blkcipher_desc *desc, struct scatterlist *sdst,
> }
> EXPORT_SYMBOL_GPL(xts_crypt);
xts_crypt() is still here. Is there a plan for its removal, since now the
generic XTS algorithm can use an accelerated ECB algorithm?
next prev parent reply other threads:[~2016-11-14 2:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-13 11:43 [v2 PATCH 0/16] crypto: skcipher - skcipher algorithm conversion part 3 Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 1/16] crypto: skcipher - Add skcipher walk interface Herbert Xu
2016-11-14 1:35 ` Eric Biggers
2016-11-15 13:58 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 2/16] crypto: aes-ce-ccm - Use " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 3/16] crypto: lrw - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 4/16] crypto: xts " Herbert Xu
2016-11-14 2:10 ` Eric Biggers [this message]
2016-11-15 14:41 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 5/16] crypto: api - Do not clear type bits in crypto_larval_lookup Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 6/16] crypto: cryptd - Add support for skcipher Herbert Xu
2016-11-14 1:45 ` Eric Biggers
2016-11-13 11:45 ` [v2 PATCH 7/16] crypto: simd - Add simd skcipher helper Herbert Xu
2016-11-14 2:27 ` Eric Biggers
2016-11-15 14:55 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 8/16] crypto: pcbc - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 9/16] crypto: glue_helper - Add skcipher xts helpers Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 10/16] crypto: testmgr - Do not test internal algorithms Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 11/16] crypto: aesni - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 12/16] crypto: arm64/aes " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 13/16] crypto: aes-ce " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 14/16] crypto: cbc " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 15/16] crypto: cbc - Export CBC implementation Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 16/16] crypto: aesbs - Convert to skcipher Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161114021029.GC4778@google.com \
--to=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).