From: Eric Biggers <ebiggers@kernel.org>
To: Nathan Huckleberry <nhuck@google.com>
Cc: linux-crypto@vger.kernel.org,
linux-fscrypt.vger.kernel.org@google.com,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org,
Paul Crowley <paulcrowley@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v5 7/8] crypto: arm64/polyval: Add PMULL accelerated implementation of POLYVAL
Date: Mon, 2 May 2022 11:11:32 -0700 [thread overview]
Message-ID: <YnAe1DTtpLDUPwSc@sol.localdomain> (raw)
In-Reply-To: <Ym7r1vt4G1xX58Kv@sol.localdomain>
On Sun, May 01, 2022 at 01:21:52PM -0700, Eric Biggers wrote:
> > +static int polyval_arm64_update(struct shash_desc *desc,
> > + const u8 *src, unsigned int srclen)
> > +{
> > + struct polyval_desc_ctx *dctx = shash_desc_ctx(desc);
> > + struct polyval_tfm_ctx *ctx = crypto_shash_ctx(desc->tfm);
> > + u8 *pos;
> > + unsigned int nblocks;
> > + unsigned int n;
> > +
> > + if (dctx->bytes) {
> > + n = min(srclen, dctx->bytes);
> > + pos = dctx->buffer + POLYVAL_BLOCK_SIZE - dctx->bytes;
> > +
> > + dctx->bytes -= n;
> > + srclen -= n;
> > +
> > + while (n--)
> > + *pos++ ^= *src++;
> > +
> > + if (!dctx->bytes)
> > + internal_polyval_mul(dctx->buffer,
> > + ctx->key_powers[NUM_KEY_POWERS-1]);
> > + }
> > +
> > + nblocks = srclen/POLYVAL_BLOCK_SIZE;
> > + internal_polyval_update(ctx, src, nblocks, dctx->buffer);
> > + srclen -= nblocks*POLYVAL_BLOCK_SIZE;
>
> This is executing a kernel_neon_begin()/kernel_neon_end() section of unbounded
> length. To allow the task to be preempted occasionally, it needs to handle the
> input in chunks, e.g. 4K at a time, like the existing code for other algorithms
> does. Something like the following would work:
>
> @@ -122,13 +118,16 @@ static int polyval_arm64_update(struct shash_desc *desc,
> ctx->key_powers[NUM_KEY_POWERS-1]);
> }
>
> - nblocks = srclen/POLYVAL_BLOCK_SIZE;
> - internal_polyval_update(ctx, src, nblocks, dctx->buffer);
> - srclen -= nblocks*POLYVAL_BLOCK_SIZE;
> + while (srclen >= POLYVAL_BLOCK_SIZE) {
> + /* Allow rescheduling every 4K bytes. */
> + nblocks = min(srclen, 4096U) / POLYVAL_BLOCK_SIZE;
> + internal_polyval_update(ctx, src, nblocks, dctx->buffer);
> + srclen -= nblocks * POLYVAL_BLOCK_SIZE;
> + src += nblocks * POLYVAL_BLOCK_SIZE;
> + }
>
> if (srclen) {
> dctx->bytes = POLYVAL_BLOCK_SIZE - srclen;
> - src += nblocks*POLYVAL_BLOCK_SIZE;
> pos = dctx->buffer;
> while (srclen--)
> *pos++ ^= *src++;
>
Also to be clear, this problem is specific to the "shash" API. You don't need
to worry about it for "skcipher" algorithms such as xctr(*), as they have to
walk a scatterlist to get their data, and that happens a page at a time.
- Eric
next prev parent reply other threads:[~2022-05-02 18:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 0:37 [PATCH v5 0/8] crypto: HCTR2 support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 1/8] crypto: xctr - Add XCTR support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 2/8] crypto: polyval - Add POLYVAL support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 3/8] crypto: hctr2 - Add HCTR2 support Nathan Huckleberry
2022-05-01 18:33 ` Eric Biggers
2022-05-02 18:25 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 4/8] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR Nathan Huckleberry
2022-05-01 21:31 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 5/8] crypto: arm64/aes-xctr: " Nathan Huckleberry
2022-05-01 22:08 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 6/8] crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of POLYVAL Nathan Huckleberry
2022-05-01 20:43 ` Eric Biggers
2022-05-02 18:08 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 7/8] crypto: arm64/polyval: Add PMULL " Nathan Huckleberry
2022-05-01 20:21 ` Eric Biggers
2022-05-02 18:11 ` Eric Biggers [this message]
2022-04-27 0:37 ` [PATCH v5 8/8] fscrypt: Add HCTR2 support for filename encryption Nathan Huckleberry
2022-05-01 18:37 ` Eric Biggers
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=YnAe1DTtpLDUPwSc@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt.vger.kernel.org@google.com \
--cc=nhuck@google.com \
--cc=paulcrowley@google.com \
--cc=samitolvanen@google.com \
/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).