summaryrefslogtreecommitdiff
path: root/drivers/bluetooth/Makefile
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@kernel.org>2026-04-21 16:09:17 -0700
committerLuiz Augusto von Dentz <luiz.von.dentz@intel.com>2026-06-11 14:24:38 -0400
commit48788c8de7c8cb36afcf8daa2be4b5160398af40 (patch)
tree3610417f9a567070c3355ea699df662ea404121a /drivers/bluetooth/Makefile
parent73e44a7d605ba7385476633996174f690c2e9a90 (diff)
downloadlinux-next-48788c8de7c8cb36afcf8daa2be4b5160398af40.tar.gz
linux-next-48788c8de7c8cb36afcf8daa2be4b5160398af40.zip
Bluetooth: SMP: Use AES-CMAC library API
Now that AES-CMAC has a library API, convert net/bluetooth/smp.c to use it instead of the "cmac(aes)" crypto_shash. Since the library API doesn't require dynamic memory allocation, we no longer need to pass a crypto_shash object down the call stack and can simply allocate the aes_cmac_key on the stack in smp_aes_cmac() (renamed from aes_cmac()). The result is simpler and faster code that no longer relies on the error-prone loading of algorithms by name. Note that the maximum stack usage actually decreases slightly, despite the expanded AES key being moved to the stack. This is because the old code called crypto_shash_tfm_digest(), which allocates 384 bytes on the stack for a maximally-sized hash descriptor for any algorithm. The new code instead declares a 288-byte aes_cmac_key, then calls aes_cmac() which declares a 32-byte aes_cmac_ctx. Since 288 + 32 < 384, the maximum stack usage decreases. I.e. the entire expanded AES key easily fits in the space that the generic crypto API was wasting before. I didn't add zeroization of the aes_cmac_key, since smp_aes_cmac() already copies the raw key to the stack without zeroizing it. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Diffstat (limited to 'drivers/bluetooth/Makefile')
0 files changed, 0 insertions, 0 deletions