Re: [PATCH 11/23] x86, kaiser: map entry stack variables

[Andy Lutomirski]

On Thu, Nov 23, 2017 at 7:37 AM, Dave Hansen
<dave.hansen@xxxxxxxxxxxxxxx> wrote:
> On 11/22/2017 07:31 PM, Andy Lutomirski wrote:
>> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen
>> <dave.hansen@xxxxxxxxxxxxxxx> wrote:
>>>
>>> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
>>>
>>> There are times where the kernel is entered but there is not a
>>> safe stack, like at SYSCALL entry.  To obtain a safe stack, the
>>> per-cpu variables 'rsp_scratch' and 'cpu_current_top_of_stack'
>>> are used to save the old %rsp value and to find where the kernel
>>> stack should start.
>>>
>>> You can not directly manipulate the CR3 register.  You can only
>>> 'MOV' to it from another register, which means a register must be
>>> clobbered in order to do any CR3 manipulation.  User-mapping
>>> these variables allows us to obtain a safe stack and use it for
>>> temporary storage *before* CR3 is switched.
>>>
>>> Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
>>> Cc: Moritz Lipp <moritz.lipp@xxxxxxxxxxxxxx>
>>> Cc: Daniel Gruss <daniel.gruss@xxxxxxxxxxxxxx>
>>> Cc: Michael Schwarz <michael.schwarz@xxxxxxxxxxxxxx>
>>> Cc: Richard Fellner <richard.fellner@xxxxxxxxxxxxxxxxx>
>>> Cc: Andy Lutomirski <luto@xxxxxxxxxx>
>>> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>>> Cc: Kees Cook <keescook@xxxxxxxxxx>
>>> Cc: Hugh Dickins <hughd@xxxxxxxxxx>
>>> Cc: x86@xxxxxxxxxx
>>> ---
>>>
>>>  b/arch/x86/kernel/cpu/common.c |    2 +-
>>>  b/arch/x86/kernel/process_64.c |    2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff -puN arch/x86/kernel/cpu/common.c~kaiser-user-map-stack-helper-vars arch/x86/kernel/cpu/common.c
>>> --- a/arch/x86/kernel/cpu/common.c~kaiser-user-map-stack-helper-vars    2017-11-22 15:45:50.128619736 -0800
>>> +++ b/arch/x86/kernel/cpu/common.c      2017-11-22 15:45:50.134619736 -0800
>>> @@ -1524,7 +1524,7 @@ EXPORT_PER_CPU_SYMBOL(__preempt_count);
>>>   * the top of the kernel stack.  Use an extra percpu variable to track the
>>>   * top of the kernel stack directly.
>>>   */
>>> -DEFINE_PER_CPU(unsigned long, cpu_current_top_of_stack) =
>>> +DEFINE_PER_CPU_USER_MAPPED(unsigned long, cpu_current_top_of_stack) =
>>>         (unsigned long)&init_thread_union + THREAD_SIZE;
>>
>> This is in an x86_32-only section and should be dropped, I think.
>
> It's used in entry_SYSCALL_64 (see below).  But I do think it's safe to
> drop now.  We switch before we use it.
>
>>> diff -puN arch/x86/kernel/process_64.c~kaiser-user-map-stack-helper-vars arch/x86/kernel/process_64.c
>>> --- a/arch/x86/kernel/process_64.c~kaiser-user-map-stack-helper-vars    2017-11-22 15:45:50.130619736 -0800
>>> +++ b/arch/x86/kernel/process_64.c      2017-11-22 15:45:50.134619736 -0800
>>> @@ -59,7 +59,7 @@
>>>  #include <asm/unistd_32_ia32.h>
>>>  #endif
>>>
>>> -__visible DEFINE_PER_CPU(unsigned long, rsp_scratch);
>>> +__visible DEFINE_PER_CPU_USER_MAPPED(unsigned long, rsp_scratch);
>>>
>> This shouldn't be needed any more either.
>
> What about this hunk?  It touches rsp_scratch before switching:
>
> @@ -207,9 +210,16 @@ ENTRY(entry_SYSCALL_64)
>
>         swapgs
>         movq    %rsp, PER_CPU_VAR(rsp_scratch)
> -       movq    PER_CPU_VAR(cpu_current_top_of_stack), %rsp
>
> -       TRACE_IRQS_OFF
> +       /*
> +        * The kernel CR3 is needed to map the process stack, but we
> +        * need a scratch register to be able to load CR3.  %rsp is
> +        * clobberable right now, so use it as a scratch register.
> +        * %rsp will be look crazy here for a couple instructions.
> +        */
> +       SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
> +
> +       movq    PER_CPU_VAR(cpu_current_top_of_stack), %rsp
>
>

I'm surprised that boots, since that hunk won't execute at all.  I
think you should move that code into the trampoline.  (Check my latest
tree -- I think it's a bit off in Ingo's tree.)  I've effectively
split SYSCALL64 into two separate paths: entry_SYSCALL_64 (with stack
switching off) and entry_SYSCALL_64_trampoline (with stack switching
on).  The entire point of the trampoline was to get a way to access
some data that varies per cpu without needing access to traditional
%gs-based percpu data.

--Andy