Re: [PATCH 0/11] crypto: CFI fixes

From: Eric Biggers <ebiggers@kernel.org>
To: "Elliott, Robert (Servers)" <elliott@hpe.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH 0/11] crypto: CFI fixes
Date: Fri, 18 Nov 2022 10:49:32 -0800	[thread overview]
Message-ID: <Y3fTvOKW1txyDOJE@sol.localdomain> (raw)
In-Reply-To: <MW5PR84MB18424C160896BF9081E8CFCAAB099@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>

On Fri, Nov 18, 2022 at 03:43:55PM +0000, Elliott, Robert (Servers) wrote:
> 
> > -----Original Message-----
> > From: Eric Biggers <ebiggers@kernel.org>
> > Sent: Friday, November 18, 2022 3:02 AM
> > To: linux-crypto@vger.kernel.org
> > Cc: x86@kernel.org; linux-arm-kernel@lists.infradead.org; Sami Tolvanen
> > <samitolvanen@google.com>
> > Subject: [PATCH 0/11] crypto: CFI fixes
> > 
> > This series fixes some crashes when CONFIG_CFI_CLANG (Control Flow
> > Integrity) is enabled, with the new CFI implementation that was merged
> > in 6.1 and is supported on x86.  Some of them were unconditional
> > crashes, while others depended on whether the compiler optimized out the
> > indirect calls or not.  This series also simplifies some code that was
> > intended to work around limitations of the old CFI implementation and is
> > unnecessary for the new CFI implementation.
> 
> Some of the x86 modules EXPORT their asm functions. Does that leave them
> at risk of being called indirectly?
> 
> arch/x86/crypto/camellia-aesni-avx-asm_64.S:SYM_FUNC_START(camellia_ecb_dec_16way)
> arch/x86/crypto/camellia-aesni-avx-asm_64.S:SYM_FUNC_START(camellia_ecb_enc_16way)
> arch/x86/crypto/camellia-aesni-avx-asm_64.S:SYM_FUNC_START(camellia_cbc_dec_16way)
> arch/x86/crypto/camellia_aesni_avx_glue.c:asmlinkage void camellia_ecb_enc_16way(const void *ctx, u8 *dst, const u8 *src);
> arch/x86/crypto/camellia_aesni_avx_glue.c:EXPORT_SYMBOL_GPL(camellia_ecb_enc_16way);
> arch/x86/crypto/camellia_aesni_avx_glue.c:asmlinkage void camellia_ecb_dec_16way(const void *ctx, u8 *dst, const u8 *src);
> arch/x86/crypto/camellia_aesni_avx_glue.c:EXPORT_SYMBOL_GPL(camellia_ecb_dec_16way);
> arch/x86/crypto/camellia_aesni_avx_glue.c:asmlinkage void camellia_cbc_dec_16way(const void *ctx, u8 *dst, const u8 *src);
> arch/x86/crypto/camellia_aesni_avx_glue.c:EXPORT_SYMBOL_GPL(camellia_cbc_dec_16way);
> 
> arch/x86/crypto/twofish-x86_64-asm_64-3way.S:SYM_FUNC_START(__twofish_enc_blk_3way)
> arch/x86/crypto/twofish.h:asmlinkage void __twofish_enc_blk_3way(const void *ctx, u8 *dst, const u8 *src,
> arch/x86/crypto/twofish_glue_3way.c:EXPORT_SYMBOL_GPL(__twofish_enc_blk_3way);

No, that doesn't matter at all.  Whether a symbol is exported or not just has to
do with how the code is divided into modules.  It doesn't have anything to do
with indirect calls.

> A few of the x86 asm functions used by C code are not referenced with
> asmlinkage like all the others. They're not EXPORTed, though, so whether
> they're indirectly used can be determined.
> 
> u32 crc32_pclmul_le_16(unsigned char const *buffer, size_t len, u32 crc32);
> 
> void clmul_ghash_mul(char *dst, const u128 *shash);
> 
> void clmul_ghash_update(char *dst, const char *src, unsigned int srclen,
>                         const u128 *shash);

No, the above functions are only called directly.

I did do another search and found that some of the sm4 functions are called
indirectly, though, so I'll send out an updated patchset that fixes those too.

- Eric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel