linux-kernel - Re: [PATCH] crypto: x86/aes-ctr - rewrite AES-NI optimized CTR and add VAES support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250128184758.GA662128@google.com>
Date: Tue, 28 Jan 2025 18:47:58 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] crypto: x86/aes-ctr - rewrite AES-NI optimized CTR and
 add VAES support

On Mon, Jan 27, 2025 at 10:31:18PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> Delete aes_ctrby8_avx-x86_64.S and add a new assembly file
> aes-ctr-avx-x86_64.S which follows a similar approach to
> aes-xts-avx-x86_64.S in that it uses a "template" to provide AESNI+AVX,
> VAES+AVX2, VAES+AVX10/256, and VAES+AVX10/512 code, instead of just
> AESNI+AVX.  Wire it up to the crypto API accordingly.

I realized there's a slight oversight in this patch: the existing AES-CTR had
both AVX and non-AVX variants, with the non-AVX assembly located in
aesni-intel_asm.S.  This patch deletes the non-AVX glue code but leaves the
non-AVX assembly, causing it to become unused.

The non-AVX AES-CTR code is x86_64 specific, so it is useful only in x86_64
kernels running on a CPU microarchitecture that supports AES-NI but not AVX:
namely Intel Westmere (2010) and the low-power Intel CPU microarchitectures
Silvermont (2013), Goldmont (2016), Goldmont Plus (2017), and Tremont (2020).
Tremont's successor, Gracemont (2021), supports AVX.

I'd lean towards just deleting the non-AVX AES-CTR code.  AES-CTR is less
important to optimize than AES-XTS and AES-GCM.  But it probably should be a
separate patch.

- Eric