• Thomas Gleixner's avatar
    x86/exceptions: Split debug IST stack · 2a594d4c
    Thomas Gleixner authored
    The debug IST stack is actually two separate debug stacks to handle #DB
    recursion. This is required because the CPU starts always at top of stack
    on exception entry, which means on #DB recursion the second #DB would
    overwrite the stack of the first.
    
    The low level entry code therefore adjusts the top of stack on entry so a
    secondary #DB starts from a different stack page. But the stack pages are
    adjacent without a guard page between them.
    
    Split the debug stack into 3 stacks which are separated by guard pages. The
    3rd stack is never mapped into the cpu_entry_area and is only there to
    catch triple #DB nesting:
    
          --- top of DB_stack	<- Initial stack
          --- end of DB_stack
          	  guard page
    
          --- top of DB1_stack	<- Top of stack after entering first #DB
          --- end of DB1_stack
          	  guard page
    
          --- top of DB2_stack	<- Top of stack after entering second #DB
          --- end of DB2_stack
          	  guard page
    
    If DB2 would not act as the final guard hole, a second #DB would point the
    top of #DB stack to the stack below #DB1 which would be valid and not catch
    the not so desired triple nesting.
    
    The backing store does not allocate any memory for DB2 and its guard page
    as it is not going to be mapped into the cpu_entry_area.
    
     - Adjust the low level entry code so it adjusts top of #DB with the offset
       between the stacks instead of exception stack size.
    
     - Make the dumpstack code aware of the new stacks.
    
     - Adjust the in_debug_stack() implementation and move it into the NMI code
       where it belongs. As this is NMI hotpath code, it just checks the full
       area between top of DB_stack and bottom of DB1_stack without checking
       for the guard page. That's correct because the NMI cannot hit a
       stackpointer pointing to the guard page between DB and DB1 stack.  Even
       if it would, then the NMI operation still is unaffected, but the resume
       of the debug exception on the topmost DB stack will crash by touching
       the guard page.
    
      [ bp: Make exception_stack_names static const char * const ]
    Suggested-by: default avatarAndy Lutomirski <luto@kernel.org>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Reviewed-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Joerg Roedel <jroedel@suse.de>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: linux-doc@vger.kernel.org
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Sean Christopherson <sean.j.christopherson@intel.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/20190414160145.439944544@linutronix.de
    2a594d4c
kernel-stacks 6.43 KB