search for: noinstr

...native_irq_enable, "sti", .text); +DEFINE_PARAVIRT_ASM(pv_native_read_cr2, "mov %cr2, %rax", .text); #endif DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key); @@ -197,11 +197,6 @@ void paravirt_end_context_switch(struct task_struct *next) arch_enter_lazy_mmu_mode(); } -static noinstr unsigned long pv_native_read_cr2(void) -{ - return native_read_cr2(); -} - static noinstr void pv_native_write_cr2(unsigned long val) { native_write_cr2(val); @@ -222,16 +217,6 @@ noinstr void pv_native_wbinvd(void) native_wbinvd(); } -static noinstr void pv_native_irq_enable(void) -{ - na...

On Wed, Aug 05, 2020 at 03:26:29PM +0200, Marco Elver wrote: > Add missing noinstr to arch_local*() helpers, as they may be called from > noinstr code. > > On a KCSAN config with CONFIG_PARAVIRT=y, syzbot stumbled across corrupt Cute, so I've been working on adding objtool support for this a little: https://lkml.kernel.org/r/20200803143231.GE2674 at hirez.progra...

...y zeroed registers at the call site of the related paravirt functions. Replace the C functions with DEFINE_PARAVIRT_ASM() constructs using the same instructions as the related paravirt calls in the PVOP_ALT_[V]CALLEE*() macros. Signed-off-by: Juergen Gross <jgross at suse.com> --- V2: - use noinstr section (Peter Zijlstra, Andrew Cooper) --- arch/x86/include/asm/paravirt_types.h | 8 +++++++- arch/x86/kernel/paravirt.c | 27 ++++++--------------------- 2 files changed, 13 insertions(+), 22 deletions(-) diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/par...

From: Joerg Roedel <jroedel at suse.de> The get_stack_info functionality is needed in the entry code for the #VC exception handler. Provide a version of it in the .text.noinstr section which can be called safely from there. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-47-joro at 8bytes.org --- arch/x86/include/asm/stacktrace.h | 2 ++ arch/x86/kernel/dumpstack.c | 7 +++--- arch/x86/kernel/dumpstack_6...

...el will forbid setting breakpoints before > instrumentation_begin(), which is necessary here because a break-point > in the #VC handler might cause recursive #VC-exceptions when #DB is > intercepted. > Maybe you can elaborate on why this makes no sense? Kernel avoids breakpoints in any noinstr text, irrespective of instrumentation_begin(). instrumentation_begin() merely allows one to call !noinstr functions.

...el will forbid setting breakpoints before > instrumentation_begin(), which is necessary here because a break-point > in the #VC handler might cause recursive #VC-exceptions when #DB is > intercepted. > Maybe you can elaborate on why this makes no sense? Kernel avoids breakpoints in any noinstr text, irrespective of instrumentation_begin(). instrumentation_begin() merely allows one to call !noinstr functions.

...trumentation_begin(), which is necessary here because a break-point > > > in the #VC handler might cause recursive #VC-exceptions when #DB is > > > intercepted. > > > Maybe you can elaborate on why this makes no sense? > > > > Kernel avoids breakpoints in any noinstr text, irrespective of > > instrumentation_begin(). > > > > instrumentation_begin() merely allows one to call !noinstr functions. > > Right, but the handler calls into various other functions. I actually > started to annotate them all with noinstr, but that was a can of...

...the night, and it's fine without > PARAVIRT (see below). I have sent the patch (need your Signed-off-by > as it's based on your code, thank you!): > https://lkml.kernel.org/r/20200807090031.3506555-1-elver at google.com > >> With CONFIG_PARAVIRT=y (without the notrace->noinstr patch), I still >> get lockdep DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()), although >> it takes longer for syzbot to hit them. But I think that's expected >> because we can still get the recursion that I pointed out, and will >> need that patch. > > Never mi...

...t;>> PARAVIRT (see below). I have sent the patch (need your Signed-off-by >>> as it's based on your code, thank you!): >>> https://lkml.kernel.org/r/20200807090031.3506555-1-elver at google.com >>> >>>> With CONFIG_PARAVIRT=y (without the notrace->noinstr patch), I still >>>> get lockdep DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()), although >>>> it takes longer for syzbot to hit them. But I think that's expected >>>> because we can still get the recursion that I pointed out, and will >>>> need...

...I have sent the patch (need your Signed-off-by >>>>> as it's based on your code, thank you!): >>>>> https://lkml.kernel.org/r/20200807090031.3506555-1-elver at google.com >>>>> >>>>>> With CONFIG_PARAVIRT=y (without the notrace->noinstr patch), I still >>>>>> get lockdep DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()), although >>>>>> it takes longer for syzbot to hit them. But I think that's expected >>>>>> because we can still get the recursion that I pointed out, and wi...

On Tue, Aug 11, 2020 at 09:57:55AM +0200, J?rgen Gro? wrote: > On 11.08.20 09:41, Peter Zijlstra wrote: > > On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote: > > > > > My hypothesis here is simply that kvm_wait() may be called in a place > > > where we get the same case I mentioned to Peter, > > > > > > raw_local_irq_save(); /* or

On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > In case you don't want to do it I can send the patch for the Xen > variants. I might've opened a whole new can of worms here. I'm not sure we can/want to fix the entire fallout this release :/ Let me ponder this a little, because the more I look at things, the more problems I keep finding... bah bah bah.

...644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -78,6 +78,67 @@ static void __init sev_es_setup_vc_stacks(int cpu) > tss->x86_tss.ist[IST_INDEX_VC] = CEA_ESTACK_TOP(&cea->estacks, VC); > } > > +static bool on_vc_stack(unsigned long sp) noinstr or __always_inline > +{ > + return ((sp >= __this_cpu_ist_bot_va(VC)) && (sp < __this_cpu_ist_top_va(VC))); > +} > + > +/* > + * This function handles the case when an NMI or an NMI-like exception > + * like #DB is raised in the #VC exception handler entry code....

...644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -78,6 +78,67 @@ static void __init sev_es_setup_vc_stacks(int cpu) > tss->x86_tss.ist[IST_INDEX_VC] = CEA_ESTACK_TOP(&cea->estacks, VC); > } > > +static bool on_vc_stack(unsigned long sp) noinstr or __always_inline > +{ > + return ((sp >= __this_cpu_ist_bot_va(VC)) && (sp < __this_cpu_ist_top_va(VC))); > +} > + > +/* > + * This function handles the case when an NMI or an NMI-like exception > + * like #DB is raised in the #VC exception handler entry code....

On 11.08.20 09:00, Marco Elver wrote: > On Fri, 7 Aug 2020 at 17:19, Marco Elver <elver at google.com> wrote: >> On Fri, Aug 07, 2020 at 02:08PM +0200, Marco Elver wrote: >>> On Fri, 7 Aug 2020 at 14:04, J?rgen Gro? <jgross at suse.com> wrote: >>>> >>>> On 07.08.20 13:38, Marco Elver wrote: >>>>> On Fri, Aug 07, 2020 at 12:35PM

...| 7 +++++++ arch/x86/include/asm/idtentry.h | 12 +++++++++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c index af0d57ed5e69..e38e4f34c90c 100644 --- a/arch/x86/entry/common.c +++ b/arch/x86/entry/common.c @@ -742,6 +742,13 @@ noinstr void idtentry_exit_nmi(struct pt_regs *regs, bool restore) __nmi_exit(); } +noinstr void idtentry_validate_ist(struct pt_regs *regs) +{ + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == + (_RET_IP_ & ~(EXCEPTION_STKSZ-1))) + die("IST stack recursion", regs, 0); +} + #ifdef...

On Thu, Aug 06, 2020 at 09:47:23AM +0200, Marco Elver wrote: > Testing my hypothesis that raw then nested non-raw > local_irq_save/restore() breaks IRQ state tracking -- see the reproducer > below. This is at least 1 case I can think of that we're bound to hit. Aaargh! > diff --git a/init/main.c b/init/main.c > index 15bd0efff3df..0873319dcff4 100644 > --- a/init/main.c

On 11.08.20 10:12, Peter Zijlstra wrote: > On Tue, Aug 11, 2020 at 09:57:55AM +0200, J?rgen Gro? wrote: >> On 11.08.20 09:41, Peter Zijlstra wrote: >>> On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote: >>> >>>> My hypothesis here is simply that kvm_wait() may be called in a place >>>> where we get the same case I mentioned to Peter,

On 11.08.20 10:12, Peter Zijlstra wrote: > On Tue, Aug 11, 2020 at 09:57:55AM +0200, J?rgen Gro? wrote: >> On 11.08.20 09:41, Peter Zijlstra wrote: >>> On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote: >>> >>>> My hypothesis here is simply that kvm_wait() may be called in a place >>>> where we get the same case I mentioned to Peter,

On Wed, Aug 12, 2020 at 10:06:50AM +0200, Marco Elver wrote: > On Tue, Aug 11, 2020 at 10:17PM +0200, peterz at infradead.org wrote: > > On Tue, Aug 11, 2020 at 11:46:51AM +0200, peterz at infradead.org wrote: > > > > > So let me once again see if I can't find a better solution for this all. > > > Clearly it needs one :/ > > > > So the below boots