All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.