On Tue, May 28, 2024 at 8:36 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Mon, May 6, 2024, at 15:35, Masahiro Yamada wrote: > > The objtool, sanitizers (KASAN, UBSAN, etc.), and profilers (GCOV, etc.) > > are intended for kernel space objects. To exclude objects from their > > coverage, you need to set variables such as OBJECT_FILES_NON_STNDARD=y, > > KASAN_SANITIZE=n, etc. > > > > For instance, the following are not kernel objects, and therefore should > > opt out of coverage: > > > > - vDSO > > - purgatory > > - bootloader (arch/*/boot/) > > > > Kbuild can detect these cases without relying on such variables because > > objects not directly linked to vmlinux or modules are considered > > "non-standard objects". > > > > Detecting objects linked to vmlinux or modules is straightforward: > > > > - objects added to obj-y are linked to vmlinux > > - objects added to lib-y are linked to vmlinux > > - objects added to obj-m are linked to modules > > > > I noticed new randconfig build warnings and bisected them > down to this patch: > > warning: unsafe memchr_inv() usage lacked '__read_overflow' symbol in lib/test_fortify/read_overflow-memchr_inv.c > warning: unsafe memchr() usage lacked '__read_overflow' warning in lib/test_fortify/read_overflow-memchr.c > warning: unsafe memscan() usage lacked '__read_overflow' symbol in lib/test_fortify/read_overflow-memscan.c > warning: unsafe memcmp() usage lacked '__read_overflow' warning in lib/test_fortify/read_overflow-memcmp.c > warning: unsafe memcpy() usage lacked '__read_overflow2' symbol in lib/test_fortify/read_overflow2-memcpy.c > warning: unsafe memcmp() usage lacked '__read_overflow2' warning in lib/test_fortify/read_overflow2-memcmp.c > warning: unsafe memmove() usage lacked '__read_overflow2' symbol in lib/test_fortify/read_overflow2-memmove.c > warning: unsafe memcpy() usage lacked '__read_overflow2_field' symbol in lib/test_fortify/read_overflow2_field-memcpy.c > warning: unsafe memmove() usage lacked '__read_overflow2_field' symbol in lib/test_fortify/read_overflow2_field-memmove.c > warning: unsafe memcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-memcpy.c > warning: unsafe memmove() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-memmove.c > warning: unsafe memset() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-memset.c > warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy-lit.c > warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy.c > warning: unsafe strncpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strncpy-src.c > warning: unsafe strncpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strncpy.c > warning: unsafe strscpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strscpy.c > warning: unsafe memcpy() usage lacked '__write_overflow_field' symbol in lib/test_fortify/write_overflow_field-memcpy.c > warning: unsafe memmove() usage lacked '__write_overflow_field' symbol in lib/test_fortify/write_overflow_field-memmove.c > warning: unsafe memset() usage lacked '__write_overflow_field' symbol in lib/test_fortify/write_overflow_field-memset.c > > I don't understand the nature of this warning, but I see > that your patch ended up dropping -fsanitize=kernel-address > from the compiler flags because the lib/test_fortify/*.c files > don't match the $(is-kernel-object) rule. Adding back > -fsanitize=kernel-address shuts up these warnings. In my understanding, fortify-string is independent of KASAN. I do not understand why -fsanitize=kernel-address matters. > I've applied a local workaround in my randconfig tree > > diff --git a/lib/Makefile b/lib/Makefile > index ddcb76b294b5..d7b8fab64068 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -425,5 +425,7 @@ $(obj)/$(TEST_FORTIFY_LOG): $(addprefix $(obj)/, $(TEST_FORTIFY_LOGS)) FORCE > > # Fake dependency to trigger the fortify tests. > ifeq ($(CONFIG_FORTIFY_SOURCE),y) > +ifndef CONFIG_KASAN > $(obj)/string.o: $(obj)/$(TEST_FORTIFY_LOG) > +endif > endif > > > which I don't think we want upstream. Can you and Kees come > up with a proper fix instead? > I set CONFIG_FORTIFY_SOURCE=y and CONFIG_KASAN=y, but I did not observe such warnings. Is this arch or compiler-specific? Could you provide me with the steps to reproduce it? -- Best Regards Masahiro Yamada