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: <ecccf06a-5791-f105-c080-01af351c0bc4@linux.intel.com>
Date:   Thu, 23 Nov 2017 07:37:33 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        moritz.lipp@...k.tugraz.at,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH 11/23] x86, kaiser: map entry stack variables

On 11/22/2017 07:31 PM, Andy Lutomirski wrote:
> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen
> <dave.hansen@...ux.intel.com> wrote:
>>
>> From: Dave Hansen <dave.hansen@...ux.intel.com>
>>
>> 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@...ux.intel.com>
>> Cc: Moritz Lipp <moritz.lipp@...k.tugraz.at>
>> Cc: Daniel Gruss <daniel.gruss@...k.tugraz.at>
>> Cc: Michael Schwarz <michael.schwarz@...k.tugraz.at>
>> Cc: Richard Fellner <richard.fellner@...dent.tugraz.at>
>> Cc: Andy Lutomirski <luto@...nel.org>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Kees Cook <keescook@...gle.com>
>> Cc: Hugh Dickins <hughd@...gle.com>
>> Cc: x86@...nel.org
>> ---
>>
>>  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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ