* objtool warning from next-20230125
@ 2023-01-26 18:23 Paul E. McKenney
2023-01-26 20:59 ` Josh Poimboeuf
2023-02-11 10:30 ` [tip: sched/core] objtool: mem*() are not uaccess safe tip-bot2 for Peter Zijlstra
0 siblings, 2 replies; 6+ messages in thread
From: Paul E. McKenney @ 2023-01-26 18:23 UTC (permalink / raw)
To: jpoimboe, peterz; +Cc: linux-kernel, sfr
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objtool warning from next-20230125
2023-01-26 18:23 objtool warning from next-20230125 Paul E. McKenney
@ 2023-01-26 20:59 ` Josh Poimboeuf
2023-01-26 23:20 ` Paul E. McKenney
2023-01-27 12:14 ` Peter Zijlstra
2023-02-11 10:30 ` [tip: sched/core] objtool: mem*() are not uaccess safe tip-bot2 for Peter Zijlstra
1 sibling, 2 replies; 6+ messages in thread
From: Josh Poimboeuf @ 2023-01-26 20:59 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: peterz, linux-kernel, sfr
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objtool warning from next-20230125
2023-01-26 20:59 ` Josh Poimboeuf
@ 2023-01-26 23:20 ` Paul E. McKenney
2023-01-27 12:14 ` Peter Zijlstra
1 sibling, 0 replies; 6+ messages in thread
From: Paul E. McKenney @ 2023-01-26 23:20 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: peterz, linux-kernel, sfr
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objtool warning from next-20230125
2023-01-26 20:59 ` Josh Poimboeuf
2023-01-26 23:20 ` Paul E. McKenney
@ 2023-01-27 12:14 ` Peter Zijlstra
2023-01-27 19:37 ` Paul E. McKenney
1 sibling, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2023-01-27 12:14 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Paul E. McKenney, linux-kernel, sfr
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...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objtool warning from next-20230125
2023-01-27 12:14 ` Peter Zijlstra
@ 2023-01-27 19:37 ` Paul E. McKenney
0 siblings, 0 replies; 6+ messages in thread
From: Paul E. McKenney @ 2023-01-27 19:37 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Josh Poimboeuf, linux-kernel, sfr
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [tip: sched/core] objtool: mem*() are not uaccess safe
2023-01-26 18:23 objtool warning from next-20230125 Paul E. McKenney
2023-01-26 20:59 ` Josh Poimboeuf
@ 2023-02-11 10:30 ` tip-bot2 for Peter Zijlstra
1 sibling, 0 replies; 6+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2023-02-11 10:30 UTC (permalink / raw)
To: linux-tip-commits
Cc: Paul E. McKenney, Peter Zijlstra (Intel), x86, linux-kernel
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 <peterz@infradead.org>
AuthorDate: Mon, 30 Jan 2023 15:21:02 +01:00
Committer: Peter Zijlstra <peterz@infradead.org>
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" <paulmck@kernel.org>
Bisected-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
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",
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-02-11 10:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-26 18:23 objtool warning from next-20230125 Paul E. McKenney
2023-01-26 20:59 ` Josh Poimboeuf
2023-01-26 23:20 ` Paul E. McKenney
2023-01-27 12:14 ` Peter Zijlstra
2023-01-27 19:37 ` Paul E. McKenney
2023-02-11 10:30 ` [tip: sched/core] objtool: mem*() are not uaccess safe tip-bot2 for Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox