From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70EF4C4332F for ; Fri, 18 Nov 2022 18:50:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0ST5BrmXcuNS9NBfi4f3PDvTonDvoIib4ibG4LVcPNM=; b=JGRBv3Ts3XHtRF J2uHxSZhE56uz71jajPAJ0rlTBnar682tkFo8dval+hnjig8hWabjP7vSt1ou7Ljk664vjBzjfTck 1JMPavH0TGWcTRSRYTvs16IF6rcLOzmHw2dWGLJVFsUPMBOc6AV5XuAOsesnVeuV0xLh43yZG5YwZ lC9DaAUxFyEkIhD3Ttm3KiesSwss6ORPfTaTLl3BhlcCsinwpxT//Pc3UuTyw3juZrZAiWWGkq/wM 79Jq31dXa0oP+zhElua7XK1+QZ3rUCnlTATbbKSGcbBtZmwaCpfSp/L8yTFHWP9FLp+1IJupuf/WE l4h1K2qdMRY8+W9uuaqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ow6Qm-007Imp-Q9; Fri, 18 Nov 2022 18:49:40 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ow6Qj-007IlF-2s for linux-arm-kernel@lists.infradead.org; Fri, 18 Nov 2022 18:49:38 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 83AAEB824C7; Fri, 18 Nov 2022 18:49:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D46BC433D6; Fri, 18 Nov 2022 18:49:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668797374; bh=Q96OIlQHZc6beG3N9u+m/eFfBbPlUi1pB02JIeAD/dI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Oafyf24NKJ43CU+tXfOrvCLNSwWbfipVIkoTIZFwuegSdVr5tiZZCtutZYpbuaM4W ucmJB75jqHW80dfc58NH4haoK7VVvm9BE9qEkeNjoMxQb7htVQQ/LpPukJSW2Y0XSg PPtCNWUzTtlzdJFgtP4eiEkzR+yxb0hEU1uBBNBsbV95EmrYU4ONEydT+2zYQ9Othq YqMX0N8TzA3+mgA2i49cW+X72DMUzzCpGdDiQOKDx/rN+3eVRSwRTTF1swztwRXeYv 9dS7F0YMUIbg2el/OtSC+DXX3tcMUnaL0CnuG8tQwXmepdnxbmbIsf+Kvio0r5uq2y 1APAWfJpUFuhQ== Date: Fri, 18 Nov 2022 10:49:32 -0800 From: Eric Biggers To: "Elliott, Robert (Servers)" Cc: "linux-crypto@vger.kernel.org" , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Sami Tolvanen Subject: Re: [PATCH 0/11] crypto: CFI fixes Message-ID: References: <20221118090220.398819-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221118_104937_436637_49B21C57 X-CRM114-Status: GOOD ( 22.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Nov 18, 2022 at 03:43:55PM +0000, Elliott, Robert (Servers) wrote: > > > -----Original Message----- > > From: Eric Biggers > > 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 > > > > 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