Building linux-next with JUMP_LABEL=n and KASAN=y, I got this objtool warning:
arch/x86/lib/copy_mc.o: warning: objtool: copy_mc_to_user()+0x22: call to __kasan_check_read() with UACCESS enabled What happens here is that copy_mc_to_user() branches on a static key in a UACCESS region: __uaccess_begin(); if (static_branch_unlikely(©_mc_fragile_key)) ret = copy_mc_fragile(to, from, len); ret = copy_mc_generic(to, from, len); __uaccess_end(); and the !CONFIG_JUMP_LABEL version of static_branch_unlikely() uses static_key_enabled(), which uses static_key_count(), which uses atomic_read(), which calls instrument_atomic_read(), which uses kasan_check_read(), which is __kasan_check_read(). Let's permit these KASAN helpers in UACCESS regions - static keys should probably work under UACCESS, I think. Signed-off-by: Jann Horn <[email protected]> --- Calling atomic_read() on a global under UACCESS should probably be fine, right? The alternative to this patch would be to change copy_mc_to_user()... Note that copy_mc_to_user() does not exist in the tip tree yet; it appeared in commit 0a78de3d4b7b1b80e5c1eead24ce11c4b3cc8791 in the nvdimm tree. tools/objtool/check.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index a88fb05242d5..1141a8e26c1e 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -583,6 +583,8 @@ static const char *uaccess_safe_builtin[] = { "__asan_store4_noabort", "__asan_store8_noabort", "__asan_store16_noabort", + "__kasan_check_read", + "__kasan_check_write", /* KASAN in-line */ "__asan_report_load_n_noabort", "__asan_report_load1_noabort", base-commit: 0248dedd12d43035bf53c326633f0610a49d7134 -- 2.28.0.709.gb0816b6eb0-goog
