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: <CALCETrXTAL+2mWL1Dsxy3c7pi3oKb1kVW44HOaRj4X0_agjeEQ@mail.gmail.com>
Date:	Fri, 27 Mar 2015 13:16:14 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 1:09 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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..

Does it matter on 32-bit kernels?  There's no swapgs, so IRQs should
still be safe, and we have a real stack pointer before sysexit.

--Andy

>
>                        Linus



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/