linux-kernel - Re: ia32_sysenter_target does not preserve EFLAGS

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]

Message-ID: <CA+55aFyJ6SnjhFwk7vgm-FfpXO+L_cgsfFqW1UK1NUgYBtRXYA@mail.gmail.com>
Date:	Fri, 27 Mar 2015 13:09:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>
Subject: Re: ia32_sysenter_target does not preserve EFLAGS

On Fri, Mar 27, 2015 at 11:37 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> User does sysenter.  We end up in native_irq_enable_sysexit.  We do:
>
> swapgs
> sti
>
> <-- NMI here can happen on some (all?) cpus, returns successfully
> *with interrupts unmasked*

I think AMD documented that the sti "interrupt shadow" shadows even
NMI. And for Intel, it definitely does not (but "mov ss" and "pop ss"
masks even NMI for the next instruction - so the interrupt shadow is
different for these cases).

That said, it wasn't 100% clear that the "NMI return to immediate
regular interrupt" can actually happen even on Intel. Iirc, there was
some discussion about when the CPU actually tests the IRQ line after
an 'iret'. It might end up testing the IF only after executing the
instruction it returns to, so it's possible that the sequence

    .. interrupts disabled ..
    sti
    sysexit

can not be interrupted by regular interrupts between the 'sti' and the
'sysexit' even if an NMI were to have happened between the two.

> My preferred fix would be to use sysretl instead of sysexit.  As far
> as I know, there are no 64-bit CPUs at all that don't support sysretl.

That 'sti+sysexit" is used for the native 32-bit case too, not just
the compat mode for x86-64. So I don't necessarily disagree with using
sysretl, but..

                       Linus
--
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/