Messages in this thread Patch in this message | | | Date | Tue, 29 Sep 2020 00:49:16 +0200 | Subject | [PATCH] objtool: Permit __kasan_check_{read,write} under UACCESS | From | Jann Horn <> |
| |
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 <jannh@google.com> --- 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
| |