linux-kernel - Re: [tip:x86/urgent] x86/entry/32: Add an ASM_CLAC to entry_SYSENTER

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: <CAMzpN2jqP74br2+pSP-X_WCpRTgK4Q6eV4N2_ZWCLkw9u4symQ@mail.gmail.com>
Date:	Thu, 25 Feb 2016 14:49:46 -0500
From:	Brian Gerst <brgerst@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: [tip:x86/urgent] x86/entry/32: Add an ASM_CLAC to entry_SYSENTER_32

On Thu, Feb 25, 2016 at 2:39 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Thu, Feb 25, 2016 at 11:31 AM, Brian Gerst <brgerst@...il.com> wrote:
>> On Thu, Feb 25, 2016 at 1:30 PM, Linus Torvalds
>> <torvalds@...ux-foundation.org> wrote:
>>> On Thu, Feb 25, 2016 at 10:20 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>>>
>>>> Ideally we'd fix this up and restore flags on sysexit.  At least
>>>> failing to restore arithmetic flags isn't an info leak because the
>>>> exit code clobbers them with entirely predictable data.  I doubt
>>>> anyone cares all that much if we clobber AC.
>>>
>>> As long as the "clobber AC" is purely about clearing it, it's probably fine.
>>>
>>> Although there may be programs that set AC in order to actually get
>>> notified about alignment issues (perhaps for portability reasons,
>>> perhaps for small performance reasons). Clearing it will make those
>>> programs still work, but they lose the checking.
>>>
>>>> I wrote a test for NT and the test fails for a different reason: our
>>>> TF handling appears broken as well.  (Our sysenter TF handling is
>>>> *crap*, but it seems to work on 64-bit kernels at least.)
>>>
>>> TF should be entirely immaterial for system calls. Why would we care?
>>> We need it for correct handling of real traps, but not for the system
>>> call case afaik. Returning with TF clear is the right thing, since
>>> we're not returning *to* the system call instruction, but the
>>> instruction after.
>>>
>>>> My personal preference would be to add the missing popf.
>>>
>>> I don't mind adding the popf, but it won't help for iopl. Only iret
>>> restores iopl, if I recall correctly (but maybe I don't, and I'm too
>>> lazy to take the 30 seconds to look it up).
>>>
>>>                Linus
>>
>> According to the SDM, popf will change IOPL only at CPL0, which is why
>> Xen (which runs at CPL1 on 32-bit) has a paravirt hook for it.
>
> But maybe we can ditch that paravirt hook and just modify regs->flags
> in sys_iopl.  Xen never uses sysexit at all:
>
>     /* XEN PV guests always use IRET path */
>     ALTERNATIVE "testl %eax, %eax; jz .Lsyscall_32_done", \
>             "jmp .Lsyscall_32_done", X86_FEATURE_XENPV
>
> and if we add the missing popf, we should be good to go.

IRET won't change IOPL either at CPL != 0, so Xen still needs that hook.

--
Brian Gerst