* 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