linux-kernel - Re: [PATCH 19/36] Bluetooth: SMP: Use new AES library API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260106065817.GB2630@sol>
Date: Mon, 5 Jan 2026 22:58:17 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, Jason@...c4.com,
	ardb@...nel.org, dengler@...ux.ibm.com, freude@...ux.ibm.com,
	herbert@...dor.apana.org.au, linux-arm-kernel@...ts.infradead.org,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH 19/36] Bluetooth: SMP: Use new AES library API

On Mon, Jan 05, 2026 at 07:05:03PM +0000, David Laight wrote:
> On Mon, 5 Jan 2026 15:40:22 +0000
> Andrew Cooper <andrew.cooper3@...rix.com> wrote:
> 
> > >  	/* Most significant octet of plaintextData corresponds to data[0] */
> > >  	swap_buf(r, data, 16);
> > >  
> > > - aes_encrypt(&ctx, data, data); + aes_encrypt_new(&aes, data, data);  
> > 
> > One thing you might want to consider, which reduces the churn in the series.
> > 
> > You can use _Generic() to do type-based dispatch on the first pointer. 
> > Something like this:
> > 
> > void aes_encrypt(const struct crypto_aes_ctx *ctx, u8 *out, const u8 *in);
> > void aes_encrypt_new(aes_encrypt_arg key, u8 out[at_least AES_BLOCK_SIZE],
> >              const u8 in[at_least AES_BLOCK_SIZE]);
> > 
> > #define aes_encrypt(ctx, out, in)                                       \
> >     _Generic(ctx,                                                       \
> >              const struct crypto_aes_ctx *: aes_encrypt(ctx, out, in),  \
> >              aes_encrypt_arg: aes_encrypt_new(ctx, out, in))
> > 
> > 
> > i.e. it keeps the _new()-ism in a single header, without needing to
> > change the drivers a second time.
> 
> You'll need to cast the 'ctx' argument in both calls.
> All the code in an _Generic() must compile cleanly in all the cases.
> (Totally annoying....)
> 
> 	David

It seems it would actually have to be:

#define aes_encrypt(key, out, in) \
_Generic(key, \
	 struct crypto_aes_ctx *: aes_encrypt_old((const struct crypto_aes_ctx *)key, out, in), \
	 const struct crypto_aes_ctx *: aes_encrypt_old((const struct crypto_aes_ctx *)key, out, in), \
	 struct aes_enckey *: aes_encrypt_new((const struct aes_enckey *)key, out, in), \
	 const struct aes_enckey *: aes_encrypt_new((const struct aes_enckey *)key, out, in), \
	 struct aes_key *: aes_encrypt_new((const struct aes_key *)key, out, in), \
	 const struct aes_key *: aes_encrypt_new((const struct aes_key *)key, out, in))

#define aes_decrypt(key, out, in) \
_Generic(key, \
	 struct crypto_aes_ctx *: aes_decrypt_old((const struct crypto_aes_ctx *)key, out, in), \
	 const struct crypto_aes_ctx *: aes_decrypt_old((const struct crypto_aes_ctx *)key, out, in), \
	 struct aes_key *: aes_decrypt_new((const struct aes_key *)key, out, in), \
	 const struct aes_key *: aes_decrypt_new((const struct aes_key *)key, out, in))

Note that both const and non-const args need to be handled.

It also doesn't work for any callers passing a 'void *' or
'const void *' and relying on an implicit cast.  I didn't notice any,
but that needs to be considered too.

I guess maybe it would still be worth it to avoid the "*_new" name
temporarily leaking into too many files.  (It goes away by the end of
the series anyway.)  It's just not quite as simple as you're suggesting,
and all the callers have to be checked for compatibility with it.

- Eric