From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org
Subject: Re: [BUG] More issues with arm/aes-neonbs
Date: Fri, 9 Aug 2024 18:27:39 +0000 [thread overview]
Message-ID: <20240809182739.GA3897645@google.com> (raw)
In-Reply-To: <ZrRjDHKHUheXkYTH@gondor.apana.org.au>
On Thu, Aug 08, 2024 at 02:17:48PM +0800, Herbert Xu wrote:
> IOW we're loading aes-arm-bs which provides cbc(aes). However, this
> needs a fallback of cbc(aes) to operate, which is made out of the
> generic cbc module + any implementation of aes, or ecb(aes). The
> latter happens to also be provided by aes-arm-cb so that's why it
> tries to load the same module again.
IMO, for CBC encryption aes-neonbs should just implement it itself on top of the
assembly function __aes_arm_encrypt(), which is actually what it did originally
before commit b56f5cbc7e08 ("crypto: arm/aes-neonbs - resolve fallback cipher at
runtime"). I don't find the motivation of that commit particularly convincing,
since aes-arm has a higher priority than aes-fixed-time anyway. Also since
commit 913a3aa07d16, aes-arm is partially hardened against cache-timing attacks.
- Eric
prev parent reply other threads:[~2024-08-09 18:27 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 21:42 [BUG] More issues with arm/aes-neonbs Russell King (Oracle)
2024-08-06 10:35 ` Herbert Xu
2024-08-08 6:17 ` Herbert Xu
2024-08-08 17:14 ` Linus Torvalds
2024-08-08 18:35 ` Linus Torvalds
2024-08-08 19:54 ` Linus Torvalds
2024-08-09 4:40 ` Herbert Xu
2024-08-09 5:19 ` Linus Torvalds
2024-08-09 16:25 ` Linus Torvalds
2024-08-09 7:50 ` Russell King (Oracle)
2024-08-10 2:41 ` [PATCH 1/3] crypto: api - Remove instance larval fulfilment Herbert Xu
2024-08-16 8:45 ` kernel test robot
2024-08-16 8:45 ` [LTP] " kernel test robot
2024-08-17 6:56 ` [v3 PATCH " Herbert Xu
2024-08-17 6:56 ` [LTP] " Herbert Xu via ltp
2024-08-17 6:57 ` [v3 PATCH 2/3] crypto: api - Do not wait for tests during registration Herbert Xu
2024-08-17 6:57 ` [LTP] " Herbert Xu via ltp
2024-08-17 6:58 ` [v3 PATCH 3/3] crypto: simd - Do not call crypto_alloc_tfm " Herbert Xu
2024-08-17 6:58 ` [LTP] " Herbert Xu via ltp
2024-08-27 18:48 ` Eric Biggers
2024-08-27 18:48 ` [LTP] " Eric Biggers via ltp
2024-08-28 2:59 ` Herbert Xu
2024-08-28 2:59 ` [LTP] " Herbert Xu via ltp
2024-08-30 17:51 ` Eric Biggers
2024-08-30 17:51 ` [LTP] " Eric Biggers via ltp
2024-09-01 8:05 ` [PATCH] crypto: api - Fix generic algorithm self-test races Herbert Xu
2024-09-01 8:05 ` [LTP] " Herbert Xu via ltp
2024-09-02 17:05 ` Eric Biggers
2024-09-02 17:05 ` [LTP] " Eric Biggers via ltp
2024-09-02 23:07 ` Herbert Xu
2024-10-05 22:24 ` Eric Biggers
2024-10-05 22:24 ` [LTP] " Eric Biggers via ltp
2024-10-06 0:53 ` Herbert Xu
2024-10-06 0:53 ` [LTP] " Herbert Xu via ltp
2024-10-06 3:06 ` Eric Biggers
2024-10-06 3:06 ` [LTP] " Eric Biggers via ltp
2024-10-07 4:32 ` Herbert Xu
2024-10-07 4:32 ` [LTP] " Herbert Xu via ltp
2024-10-07 7:58 ` Herbert Xu
2024-10-07 7:58 ` [LTP] " Herbert Xu via ltp
2024-10-07 8:31 ` Herbert Xu
2024-10-07 8:31 ` [LTP] " Herbert Xu via ltp
2024-08-10 2:42 ` [PATCH 2/3] crypto: api - Do not wait for tests during registration Herbert Xu
2024-08-11 13:30 ` Dan Carpenter
2024-08-12 10:33 ` Herbert Xu
2024-08-12 10:34 ` [v2 PATCH 1/3] crypto: api - Remove instance larval fulfilment Herbert Xu
2024-08-12 10:35 ` [v2 PATCH 2/3] crypto: api - Do not wait for tests during registration Herbert Xu
2024-08-12 10:36 ` [v2 PATCH 3/3] crypto: simd - Do not call crypto_alloc_tfm " Herbert Xu
2024-08-10 2:43 ` [PATCH " Herbert Xu
2024-08-09 18:27 ` Eric Biggers [this message]
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=20240809182739.GA3897645@google.com \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.