From: Ard Biesheuvel <ardb@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ben Greear <greearb@candelatech.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH 0/5] crypto: Implement cmac based on cbc skcipher
Date: Thu, 20 Aug 2020 09:19:16 +0200 [thread overview]
Message-ID: <CAMj1kXE6QDxjNKSpzTrxe+QU0DF9CYp-W7bGe1AyFzYHOJQ41Q@mail.gmail.com> (raw)
In-Reply-To: <20200820070645.GA21395@gondor.apana.org.au>
On Thu, 20 Aug 2020 at 09:06, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Aug 20, 2020 at 09:04:26AM +0200, Ard Biesheuvel wrote:
> >
> > I don't disagree with that, especially given all the effort that went
> > into optimizing FPU preserve/restore on both arm64 and x86. But the
> > bottom line is that this is what is causing the degradation in Ben's
> > case, so we cannot disregard it.
>
> If he's having problems with the performance when SIMD is in use
> due to preserve/restore, I'd hate to see his numbers when SIMD is
> not available.
>
Actually, I'm not so sure that they will be so much worse. The
expensive FPU preserve/restore occurs for every 16 bytes of data
processed by the AES cipher, which I'd estimate to take ~10 cycles per
byte for an unaccelerated implementation. But table based AES should
be avoided, especially for MAC algorithms where the plaintext may be
known to an attacker who is after the key.
However, the CCMP handling is invoked from softirq context or from
task context, and so SIMD is generally available unless the softirq
happens to be taken over the back of a hardirq that interrupted a task
running in the kernel that was using the SIMD already. IOW, this
happens so rarely in practice that I would not expect it to be
noticeable in the performance stats.
> IOW if this really matters to him, then wireless code needs to switch
> over to ahash.
>
> Solving half of the problem simply makes no sense.
>
My v2 attempt at cbcmac(aesni) implements an ahash, but a synchronous
one. This means we can amortize the FPU preserve/restore over the
entire scatterlist, instead of relying on the ahash walk to present
the data in virtually mapped chunks.
I'd still like to explore this approach, but I simply haven't had the
spare cycles to spend on this.
next prev parent reply other threads:[~2020-08-20 7:19 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-02 9:06 [PATCH] crypto: x86/aesni - implement accelerated CBCMAC, CMAC and XCBC shashes Ard Biesheuvel
2020-08-03 19:11 ` Ben Greear
2020-08-04 12:55 ` Ard Biesheuvel
2020-08-04 13:01 ` Ben Greear
2020-08-04 13:08 ` Ard Biesheuvel
2020-08-04 13:22 ` Ben Greear
2020-08-04 19:45 ` Ben Greear
2020-08-04 20:12 ` Ard Biesheuvel
2020-09-23 11:03 ` Ben Greear
2020-10-29 16:58 ` Ard Biesheuvel
2020-08-18 8:24 ` [PATCH 0/5] crypto: Implement cmac based on cbc skcipher Herbert Xu
2020-08-18 8:25 ` [PATCH 1/6] crypto: skcipher - Add helpers for sync skcipher spawn Herbert Xu
2020-08-18 8:25 ` [PATCH 2/6] crypto: ahash - Add helper to free single spawn instance Herbert Xu
2020-08-18 8:25 ` [PATCH 3/6] crypto: ahash - Add init_tfm/exit_tfm Herbert Xu
2020-08-18 8:25 ` [PATCH 4/6] crypto: ahash - Add ahash_alg_instance Herbert Xu
2020-08-18 8:25 ` [PATCH 5/6] crypto: ahash - Remove AHASH_REQUEST_ON_STACK Herbert Xu
2020-08-26 10:55 ` Ard Biesheuvel
2020-08-18 8:25 ` [PATCH 6/6] crypto: cmac - Use cbc skcipher instead of raw cipher Herbert Xu
2020-08-24 9:47 ` Ard Biesheuvel
2020-08-24 11:20 ` Herbert Xu
2020-08-18 8:31 ` [PATCH 0/5] crypto: Implement cmac based on cbc skcipher Ard Biesheuvel
2020-08-18 13:51 ` Herbert Xu
2020-08-18 13:56 ` Ben Greear
2020-08-18 14:05 ` Herbert Xu
2020-08-18 14:17 ` Ben Greear
2020-08-18 22:15 ` Herbert Xu
2020-08-18 22:27 ` Herbert Xu
2020-08-18 22:31 ` Ben Greear
2020-08-18 22:33 ` Herbert Xu
2020-08-18 22:39 ` Ben Greear
2020-08-20 6:58 ` Ard Biesheuvel
2020-08-20 7:01 ` Herbert Xu
2020-08-20 7:04 ` Ard Biesheuvel
2020-08-20 7:06 ` Herbert Xu
2020-08-20 7:19 ` Ard Biesheuvel [this message]
2020-08-20 7:29 ` Herbert Xu
2020-08-20 7:33 ` Ard Biesheuvel
2020-08-20 7:44 ` Herbert Xu
2020-08-20 7:48 ` Ard Biesheuvel
2020-08-20 7:53 ` Herbert Xu
2020-08-20 7:56 ` Ard Biesheuvel
2020-08-20 13:54 ` Ben Greear
2020-08-20 20:10 ` Herbert Xu
2020-08-20 22:09 ` Ben Greear
2020-08-20 22:12 ` Herbert Xu
2020-08-22 22:35 ` Christian Lamparter
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=CAMj1kXE6QDxjNKSpzTrxe+QU0DF9CYp-W7bGe1AyFzYHOJQ41Q@mail.gmail.com \
--to=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=greearb@candelatech.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).