On Fri, Nov 18, 2022 at 12:10 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Fri, Nov 18, 2022 at 11:44:17AM -0800, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > sm4_aesni_avx_ctr_enc_blk8(), sm4_aesni_avx_cbc_dec_blk8(), > > sm4_aesni_avx_cfb_dec_blk8(), sm4_aesni_avx2_ctr_enc_blk16(), > > sm4_aesni_avx2_cbc_dec_blk16(), and sm4_aesni_avx2_cfb_dec_blk16() are > > called via indirect function calls. Therefore they need to use > > SYM_TYPED_FUNC_START instead of SYM_FUNC_START to cause their type > > hashes to be emitted when the kernel is built with CONFIG_CFI_CLANG=y. > > Otherwise, the code crashes with a CFI failure. > > > > (Or at least that should be the case. For some reason the CFI checks in > > sm4_avx_cbc_decrypt(), sm4_avx_cfb_decrypt(), and sm4_avx_ctr_crypt() > > are not always being generated, using current tip-of-tree clang. > > Anyway, this patch is a good idea anyway.) > > Sami, is it expected that a CFI check isn't being generated for the indirect > call to 'func' in sm4_avx_cbc_decrypt()? I'm using LLVM commit 4a7be42d922af0. If the compiler emits an indirect call, it should also emit a CFI check. What's the assembly code it generates here? Sami
