[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrV8BhaL9MUv9ZroyWwrBKdDXL+ZwY3dELO80N3bcsxi5A@mail.gmail.com>
Date: Mon, 9 Mar 2015 10:45:41 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Oleg Nesterov <oleg@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Alexei Starovoitov <ast@...mgrid.com>,
Will Drewry <wad@...omium.org>,
Kees Cook <keescook@...omium.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)
On Mon, Mar 9, 2015 at 10:42 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 03/09/2015 09:08 AM, Linus Torvalds wrote:
>>
>> Sure, the btl is easier to explain in the source code, but instead of this:
>>
>>> + btl $X86_EFLAGS_VM_BIT,PT_EFLAGS(%esp)
>>
>> you'd have to add a comment, like
>>
>> testb $2, PT_EFLAGS+2(%esp) # X86_EFLAGS_VM_BIT
>>
>> or something.
>>
>
> Maybe:
>
> testb $(X86_EFLAGS_VM-16), PT_EFLAGS+2(%esp)
>
>> Or just at least *partially* do what we used to do, and make it all be
>>
>> movb PT_EFLAGS+2(%esp),%al
>> andb $2,%al
>> orb PT_CS(%esp),%al
>> testb $3,%al
>> je restore_nocheck
>> testb $SEGMENT_TI_MASK,PT_OLDSS(%esp)
>> jne ldt_ss
>>
>> which still avoids looking at SS unless needed, and is smaller and
>> faster than the btl, afaik.
>
> The question is if avoiding looking at a field on the stack matters at all.
It does for silly reasons.
If sp0 is set to the very top of the stack, then an NMI immediately
after sysenter will have OLDSS off the top of the stack, and reading
it can crash. This is why 32-bit kernels have a (buggy!) 8 byte
offset in sp0.
An alternative would be to fix the bug, but I still think it's ugly.
--Andy
--
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/
Powered by blists - more mailing lists