Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback withint 0xcc

[Ingo Molnar]

* Andrew Lutomirski <luto@xxxxxxx> wrote:

> On Sun, May 29, 2011 at 3:10 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Andy Lutomirski <luto@xxxxxxx> wrote:
> >
> >> --- a/arch/x86/kernel/entry_64.S
> >> +++ b/arch/x86/kernel/entry_64.S
> >> @@ -1121,6 +1121,8 @@ zeroentry spurious_interrupt_bug do_spurious_interrupt_bug
> >>  zeroentry coprocessor_error do_coprocessor_error
> >>  errorentry alignment_check do_alignment_check
> >>  zeroentry simd_coprocessor_error do_simd_coprocessor_error
> >> +zeroentry intcc do_intcc
> >> +
> >>
> >>       /* Reload gs selector with exception handling */
> >>       /* edi:  new selector */
> >> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> >
> > I forgot to reply to your prior question about zeroentry vs.
> > paranoidzeroentry.
> >
> > That distinction is an undocumented x86-64-ism.
> 
> Is this an erratum or just the undocumented fact that
> swapgs twice puts usergs back and confuses the kernel?

There's no erratum needed for this to be unreliable: if an NMI hits like this:


	SYSENTER

	<=== ... NMI entry ...

	SWAPGS

then the CS check of the entry frame will show 'we interrupted kernel 
mode code', but in reality the SWAPGS has not been done yet.

Regular interrupts (and pagefaults, etc.) can never interrupt the 
above sequence 'in the middle', where the CS check is unreliable.

So yes, it's about not confusing the kernel into the wrong SWAPGS 
state.

I suspect you could trigger badness very quickly: mark the NMI entry 
zeroentry and run some more extreme NMI load like:

        # 100 KHz NMI with precise (no skid) cycles PEBS profiling:

	perf record -a -e cycles:pp -F 100000 sleep 60

and i guess you'll see a nasty crash very quickly.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/