linux-kernel - Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback with int 0xcc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 May 2011 21:43:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback with
 int 0xcc


* Andrew Lutomirski <luto@....edu> wrote:

> On Sun, May 29, 2011 at 3:10 PM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Andy Lutomirski <luto@....EDU> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/