Hello!
I have started seeing these objtool warnings from a wide variety of
KASAN-enabled rcutorture-related test scenarios in next-20230125. It has
been awhile since I tested -next, so I am not yet sure where this started.
vmlinux.o: warning: objtool: __asan_memset+0x34: call to __memset() with UACCESS enabled
vmlinux.o: warning: objtool: __asan_memmove+0x4d: call to __memmove() with UACCESS enabled
vmlinux.o: warning: objtool: __asan_memcpy+0x4d: call to __memcpy() with UACCESS enabled
As usual, should I be worried?
Thanx, Paul
On Thu, Jan 26, 2023 at 10:23:02AM -0800, Paul E. McKenney wrote:
> Hello!
>
> I have started seeing these objtool warnings from a wide variety of
> KASAN-enabled rcutorture-related test scenarios in next-20230125. It has
> been awhile since I tested -next, so I am not yet sure where this started.
>
> vmlinux.o: warning: objtool: __asan_memset+0x34: call to __memset() with UACCESS enabled
> vmlinux.o: warning: objtool: __asan_memmove+0x4d: call to __memmove() with UACCESS enabled
> vmlinux.o: warning: objtool: __asan_memcpy+0x4d: call to __memcpy() with UACCESS enabled
>
> As usual, should I be worried?
This apparently came from Peter's
69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
but I have no idea how this is supposed to work. Peter?
--
Josh
On Thu, Jan 26, 2023 at 12:59:54PM -0800, Josh Poimboeuf wrote:
> On Thu, Jan 26, 2023 at 10:23:02AM -0800, Paul E. McKenney wrote:
> > Hello!
> >
> > I have started seeing these objtool warnings from a wide variety of
> > KASAN-enabled rcutorture-related test scenarios in next-20230125. It has
> > been awhile since I tested -next, so I am not yet sure where this started.
> >
> > vmlinux.o: warning: objtool: __asan_memset+0x34: call to __memset() with UACCESS enabled
> > vmlinux.o: warning: objtool: __asan_memmove+0x4d: call to __memmove() with UACCESS enabled
> > vmlinux.o: warning: objtool: __asan_memcpy+0x4d: call to __memcpy() with UACCESS enabled
> >
> > As usual, should I be worried?
>
> This apparently came from Peter's
>
> 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
>
> but I have no idea how this is supposed to work. Peter?
I guess that I am glad that it is not just me, then. ;-)
Thank you for tracking down the relevant commit!
Thanx, Paul
On Thu, Jan 26, 2023 at 12:59:54PM -0800, Josh Poimboeuf wrote:
> On Thu, Jan 26, 2023 at 10:23:02AM -0800, Paul E. McKenney wrote:
> > Hello!
> >
> > I have started seeing these objtool warnings from a wide variety of
> > KASAN-enabled rcutorture-related test scenarios in next-20230125. It has
> > been awhile since I tested -next, so I am not yet sure where this started.
> >
> > vmlinux.o: warning: objtool: __asan_memset+0x34: call to __memset() with UACCESS enabled
> > vmlinux.o: warning: objtool: __asan_memmove+0x4d: call to __memmove() with UACCESS enabled
> > vmlinux.o: warning: objtool: __asan_memcpy+0x4d: call to __memcpy() with UACCESS enabled
> >
> > As usual, should I be worried?
>
> This apparently came from Peter's
>
> 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
>
> but I have no idea how this is supposed to work. Peter?
Durr.. I'm not sure why I put them in the uaccess_safe_builtin[] array.
So yeah, this reproduces using defconfig+KASAN, removing the functions
from the array shuts it up and doesn't generate new ones -- for that
config.
Let me try and build a few more .configs...
On Fri, Jan 27, 2023 at 01:14:47PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 26, 2023 at 12:59:54PM -0800, Josh Poimboeuf wrote:
> > On Thu, Jan 26, 2023 at 10:23:02AM -0800, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I have started seeing these objtool warnings from a wide variety of
> > > KASAN-enabled rcutorture-related test scenarios in next-20230125. It has
> > > been awhile since I tested -next, so I am not yet sure where this started.
> > >
> > > vmlinux.o: warning: objtool: __asan_memset+0x34: call to __memset() with UACCESS enabled
> > > vmlinux.o: warning: objtool: __asan_memmove+0x4d: call to __memmove() with UACCESS enabled
> > > vmlinux.o: warning: objtool: __asan_memcpy+0x4d: call to __memcpy() with UACCESS enabled
> > >
> > > As usual, should I be worried?
> >
> > This apparently came from Peter's
> >
> > 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
> >
> > but I have no idea how this is supposed to work. Peter?
>
> Durr.. I'm not sure why I put them in the uaccess_safe_builtin[] array.
>
> So yeah, this reproduces using defconfig+KASAN, removing the functions
> from the array shuts it up and doesn't generate new ones -- for that
> config.
>
> Let me try and build a few more .configs...
Again, I am glad that it is not just me...
And thank you for digging into this!
Thanx, Paul
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 443ed4c302fff6a26af980300463343a7adc9ee8
Gitweb: https://git.kernel.org/tip/443ed4c302fff6a26af980300463343a7adc9ee8
Author: Peter Zijlstra <[email protected]>
AuthorDate: Mon, 30 Jan 2023 15:21:02 +01:00
Committer: Peter Zijlstra <[email protected]>
CommitterDate: Sat, 11 Feb 2023 11:18:08 +01:00
objtool: mem*() are not uaccess safe
For mysterious raisins I listed the new __asan_mem*() functions as
being uaccess safe, this is giving objtool fails on KASAN builds
because these functions call out to the actual __mem*() functions
which are not marked uaccess safe.
Removing it doesn't make the robots unhappy.
Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
Reported-by: "Paul E. McKenney" <[email protected]>
Bisected-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lkml.kernel.org/r/20230126182302.GA687063@paulmck-ThinkPad-P17-Gen-1
---
tools/objtool/check.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 10b5bb4..b118f58 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1083,9 +1083,6 @@ static const char *uaccess_safe_builtin[] = {
"__asan_store16_noabort",
"__kasan_check_read",
"__kasan_check_write",
- "__asan_memset",
- "__asan_memmove",
- "__asan_memcpy",
/* KASAN in-line */
"__asan_report_load_n_noabort",
"__asan_report_load1_noabort",