All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Alexander Potapenko <glider@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH -tip v3 1/2] kcov: Make runtime functions noinstr-compatible
Date: Mon, 15 Jun 2020 16:53:36 +0200	[thread overview]
Message-ID: <20200615145336.GA220132@google.com> (raw)
In-Reply-To: <20200615142949.GT2531@hirez.programming.kicks-ass.net>

On Mon, 15 Jun 2020, Peter Zijlstra wrote:

> On Mon, Jun 15, 2020 at 09:53:06AM +0200, Marco Elver wrote:
> > 
> > Disabling KCOV for smp_processor_id now moves the crash elsewhere. In
> > the case of KASAN into its 'memcpy' wrapper, called after
> > __this_cpu_read in fixup_bad_iret. This is making me suspicious,
> > because it shouldn't be called from the noinstr functions.
> 
> With your .config, objtool complains about exactly that though:
> 
> vmlinux.o: warning: objtool: fixup_bad_iret()+0x8e: call to memcpy() leaves .noinstr.text section
> 
> The utterly gruesome thing below 'cures' that.

Is __memcpy() generally available? I think that bypasses KASAN and
whatever else.

> > For KCSAN the crash still happens in check_preemption_disabled, in the
> > inlined native_save_fl function (apparently on its 'pushf'). If I turn
> > fixup_bad_iret's __this_cpu_read into a raw_cpu_read (to bypass
> > check_preemption_disabled), no more crash with KCSAN.
> 
> vmlinux.o: warning: objtool: debug_smp_processor_id()+0x0: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section
> vmlinux.o: warning: objtool: check_preemption_disabled()+0x1f: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section
> vmlinux.o: warning: objtool: __this_cpu_preempt_check()+0x4: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section
> 
> That could be either of those I suppose, did you have the NOP patches
> on? Let me try... those seem to placate objtool at least.
> 
> I do see a fair amount of __kasan_check*() crud though:
> 
> vmlinux.o: warning: objtool: rcu_nmi_exit()+0x44: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x1c: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: rcu_nmi_enter()+0x46: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0x21: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: __rcu_is_watching()+0x1c: call to __kasan_check_read() leaves .noinstr.text section
> vmlinux.o: warning: objtool: debug_locks_off()+0x1b: call to __kasan_check_write() leaves .noinstr.text section
> 
> That wasn't supported to happen with the __no_sanitize patches on (which
> I didn't forget). Aah, I think we've lost a bunch of patches.. /me goes
> rummage.
> 
> This:
> 
>   https://lkml.kernel.org/r/20200603114051.896465666@infradead.org
> 
> that cures the rcu part of that.
> 
> Let me go look at your KCSAN thing now...

I tried to find the stack that is used by the crashing code -- which led
me to entry_stack? So I tried this:

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -370,7 +370,7 @@ struct x86_hw_tss {
 #define IO_BITMAP_OFFSET_INVALID	(__KERNEL_TSS_LIMIT + 1)
 
 struct entry_stack {
-	unsigned long		words[64];
+	unsigned long		words[128];
 };
 
 struct entry_stack_page {

No more crash. But that's probably not what we want. Just a datapoint.

> ---
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index af75109485c26..031a21fb5a741 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -675,6 +675,14 @@ struct bad_iret_stack {
>  	struct pt_regs regs;
>  };
>  
> +void __always_inline __badcpy(void *dst, void *src, int nr)
> +{
> +	unsigned long *d = dst, *s = src;
> +	nr /= sizeof(unsigned long);
> +	while (nr--)
> +		*(d++) = *(s++);
> +}
> +

If we can use __memcpy() here, that would probably solve that.

Thanks,
-- Marco

  parent reply	other threads:[~2020-06-15 14:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05  8:28 [PATCH -tip v3 1/2] kcov: Make runtime functions noinstr-compatible Marco Elver
2020-06-05  8:28 ` [PATCH -tip v3 2/2] kcov: Unconditionally add -fno-stack-protector to compiler options Marco Elver
2020-06-05 16:50   ` Nick Desaulniers
2020-06-05 10:57 ` [PATCH -tip v3 1/2] kcov: Make runtime functions noinstr-compatible Dmitry Vyukov
2020-06-05 12:03   ` Peter Zijlstra
2020-06-05 13:25     ` Andrey Konovalov
2020-06-07  9:37       ` Dmitry Vyukov
2020-06-08  7:48         ` Marco Elver
2020-06-08  7:57           ` Dmitry Vyukov
2020-06-08 11:01             ` Peter Zijlstra
2020-06-11 21:55               ` Peter Zijlstra
2020-06-11 21:58                 ` Peter Zijlstra
2020-06-12 11:34                   ` Peter Zijlstra
2020-06-12  4:04                 ` Dmitry Vyukov
2020-06-12 11:49                   ` Marco Elver
2020-06-13 17:24                     ` Dmitry Vyukov
2020-06-15  7:53                       ` Marco Elver
2020-06-15 14:29                         ` Peter Zijlstra
2020-06-15 14:35                           ` Peter Zijlstra
2020-06-15 14:53                           ` Marco Elver [this message]
2020-06-15 15:03                             ` Peter Zijlstra
2020-06-15 15:20                               ` Peter Zijlstra
2020-06-17 14:32                                 ` Marco Elver
2020-06-17 14:49                                   ` Peter Zijlstra
2020-06-17 15:19                                     ` Peter Zijlstra
2020-06-17 15:19                                     ` Marco Elver
2020-06-17 15:55                                       ` Peter Zijlstra
2020-06-17 16:36                                         ` Peter Zijlstra
2020-06-17 18:06                                           ` Marco Elver
2020-06-15 14:54                         ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200615145336.GA220132@google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=bp@alien8.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.