CALL arch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'bcmp' referenced from prom_init.c
make[2]: *** [arch/powerpc/kernel/Makefile:196: prom_init_check] Error 1
https://elixir.bootlin.com/linux/v5.3-rc7/source/arch/powerpc/kernel/prom_init_check.sh
# This script checks prom_init.o to see what external symbols it
# is using, if it finds symbols not in the whitelist it returns
# an error. The point of this is to discourage people from
# intentionally or accidentally adding new code to prom_init.c
# which has side effects on other parts of the kernel.
# If you really need to reference something from prom_init.o add
# it to the list below:
grep "^CONFIG_KASAN=y$" .config >/dev/null
if [ $? -eq 0 ]
then
MEM_FUNCS="__memcpy __memset"
else
MEM_FUNCS="memcpy memset"
fi
WHITELIST="add_reloc_offset __bss_start __bss_stop copy_and_flush
_end enter_prom $MEM_FUNCS reloc_offset __secondary_hold
__secondary_hold_acknowledge __secondary_hold_spinloop __start
logo_linux_clut224 btext_prepare_BAT
reloc_got2 kernstart_addr memstart_addr linux_banner _stext
__prom_init_toc_start __prom_init_toc_end btext_setup_display TOC."
So $MEM_FUNCS allows calls memcpy and memset via $WHITELIST. bcmp needs to be added to the list of $MEM_FUNCS.
cc @ramosian-glider if recent bcmp optimizations in LLVM have implications for KASAN, ie, the double underscored prefixed versions of these functions.
Fair enough, wasn't sure if there was any reason not to do that. I can send along a patch that adds bcmp to the whitelist (I'll try to do this tomorrow).
Looking into this further, it looks like prom_init.c has its own set of mem* and str* functions (including a version of memcmp): https://github.com/torvalds/linux/commit/450e7dd4001f22f796e22422dd1d2cbd5bda21fc
I am not sure that allowing a reference to the generic bcmp function in lib/string.c will be allowed (although prom_memcmp is the same as the generic memcmp so it should be fine)...? It appears in prom_strstr according to the disassembly, I assume because of the looping with memcmp; however, this type of transformation does not seem beneficial for the kernel at all because our bcmp is just a wrapper around memcmp (so we are going to go from memcmp to bcmp back to memcmp but I might be misunderstanding this whole transformation thing).
This could be solved tangentially by adding -ffreestanding to arch/powerpc, which was potentially suggested as a solution for #625: https://lore.kernel.org/linuxppc-dev/[email protected]/
problem is that the compiler is going to insert calls to bcmp, so you can't define prom_bcmp. (Compiler will also insert calls to memset/memcpy, too). So -ffreestanding is probably a better fix (at least for prom).
Looks like the problematic LLVM commit was reverted almost a week ago so it doesn't appear to be a high priority to fix this right away: https://github.com/llvm/llvm-project/commit/bdd65351d3f39d38d3ed64cd9849d54aaac904c3
Bug: https://bugs.llvm.org/show_bug.cgi?id=43206.
Let's close this bug and reopen should the problem come back. Since it sounds like the problematic commit to llvm has been reverted, I'm not sure there's more to track here just yet.
Roman is right: https://bugs.llvm.org/show_bug.cgi?id=43206#c5
I can probably draft up a patch (already tentatively have one: https://gist.github.com/nathanchance/0472b44f1403e98c4a10bdc5e46d2d0b) but I feel like my PowerPC patches end up going nowhere...
but I feel like my PowerPC patches end up going nowhere...
Life is meaningless, so don't sweat the small stuff. 馃懝
That patch LGTM (I'd sign off when posted to the list)
Patch sent: https://lore.kernel.org/lkml/[email protected]/
Sorry, didn't track this issue here, it is good that a retroactive fix was attempted.
Merged into mainline: https://git.kernel.org/linus/8dcd71b45df34d9b903450fab147ee8c1e6c16b5