On July 14, 2024 10:04:32 AM PDT, Masahiro Yamada <[email protected]> wrote:
>When a software KASAN mode is enabled, the fortify tests emit warnings
>on some architectures.
>
>For example, for ARCH=arm, the combination of CONFIG_FORTIFY_SOURCE=y
>and CONFIG_KASAN=y produces the following warnings:
>
>    TEST    lib/test_fortify/read_overflow-memchr.log
>  warning: unsafe memchr() usage lacked '__read_overflow' warning in 
> lib/test_fortify/read_overflow-memchr.c
>    TEST    lib/test_fortify/read_overflow-memchr_inv.log
>  warning: unsafe memchr_inv() usage lacked '__read_overflow' symbol in 
> lib/test_fortify/read_overflow-memchr_inv.c
>    TEST    lib/test_fortify/read_overflow-memcmp.log
>  warning: unsafe memcmp() usage lacked '__read_overflow' warning in 
> lib/test_fortify/read_overflow-memcmp.c
>    TEST    lib/test_fortify/read_overflow-memscan.log
>  warning: unsafe memscan() usage lacked '__read_overflow' symbol in 
> lib/test_fortify/read_overflow-memscan.c
>    TEST    lib/test_fortify/read_overflow2-memcmp.log
>  warning: unsafe memcmp() usage lacked '__read_overflow2' warning in 
> lib/test_fortify/read_overflow2-memcmp.c
>     [ more and more similar warnings... ]
>
>Commit 9c2d1328f88a ("kbuild: provide reasonable defaults for tool
>coverage") removed KASAN flags from non-kernel objects by default.
>It was an intended behavior because lib/test_fortify/*.c are unit
>tests that are not linked to the kernel.
>
>As it turns out, some architectures require -fsanitize=kernel-(hw)address
>to define __SANITIZE_ADDRESS__ for the fortify tests.
>
>Without __SANITIZE_ADDRESS__ defined, arch/arm/include/asm/string.h
>defines __NO_FORTIFY, thus excluding <linux/fortify-string.h>.
>
>This issue does not occur on x86 thanks to commit 4ec4190be4cf
>("kasan, x86: don't rename memintrinsics in uninstrumented files"),
>but there are still some architectures that define __NO_FORTIFY
>in such a situation.
>
>Set KASAN_SANITIZE=y explicitly to the fortify tests.
>
>Fixes: 9c2d1328f88a ("kbuild: provide reasonable defaults for tool coverage")
>Reported-by: Arnd Bergmann <[email protected]>
>Closes: 
>https://lore.kernel.org/all/[email protected]/
>Signed-off-by: Masahiro Yamada <[email protected]>
>---
>
>Kees Cook said "I'll try to figure this out", but I have not seen a patch so 
>far,
>so I decided to do this myself.
>(https://lore.kernel.org/all/202405310908.A5733DF@keescook/)
>
>I will send a pull req with this and some other fixes.
>I need to fix this, as v6.10 will be released soon.

Awesome! Thanks for figuring this out; I hadn't had time yet. 

Acked-by: Kees Cook<[email protected]>


-- 
Kees Cook

Reply via email to