Re: [PATCH] lib/crypto: blake2s: fix a CFI failure
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2022-01-19 10:20:27
Also in:
linux-crypto, linux-mediatek, lkml
On 1/19/22, Ard Biesheuvel [off-list ref] wrote:
On Wed, 19 Jan 2022 at 11:06, Miles Chen [off-list ref] wrote:quoted
Hi,quoted
Hi Miles, I'm actually not able to reproduce your oops. I'm using vanilla clang 13, cross compiling for arm64, with thin LTO enabled and CFI enabled. Kernel seems to run fine. Are there other settings that are needed to trigger this? Do you see it in upstream clang or just the Android fork of clang?I will try another clang (the previous version I use). I am using Android fork of clang and there is a clang upgrade in this merge.One thing that could be worth a try is to make __blake2s_update() and __blake2s_final() __always_inline rather than just inline, which by itself does not appear to be sufficient for the code to get inlined. (If it were, the indirect call should have disappeared as well) Given that indirect calls suck on x86, we should probably apply that change in any case, regardless of CFI.
Had the same thought at first, but then looking at the original stack trace, it looks like the __ function is inlined: [ 0.000000][ T0] __cfi_slowpath_diag+0x354/0x4b0 [ 0.000000][ T0] blake2s_update+0x14c/0x178 [ 0.000000][ T0] _extract_entropy+0xf4/0x29c So that makes me think that the issue really does involve calling through the weak alias. But why should weak alias calling trigger CFI? Compiler bug? Some other subtlety we're missing? Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel