• Dave Hansen's avatar
    x86/fpu: Fix 32-bit signal frame handling · 2d08f031
    Dave Hansen authored
    commit ab6b5294 upstream.
    
    (This should have gone to LKML originally. Sorry for the extra
     noise, folks on the cc.)
    
    Background:
    
    Signal frames on x86 have two formats:
    
      1. For 32-bit executables (whether on a real 32-bit kernel or
         under 32-bit emulation on a 64-bit kernel) we have a
        'fpregset_t' that includes the "FSAVE" registers.
    
      2. For 64-bit executables (on 64-bit kernels obviously), the
         'fpregset_t' is smaller and does not contain the "FSAVE"
         state.
    
    When creating the signal frame, we have to be aware of whether
    we are running a 32 or 64-bit executable so we create the
    correct format signal frame.
    
    Problem:
    
    save_xstate_epilog() uses 'fx_sw_reserved_ia32' whenever it is
    called for a 32-bit executable.  This is for real 32-bit and
    ia32 emulation.
    
    But, fpu__init_prepare_fx_sw_frame() only initializes
    'fx_sw_reserved_ia32' when emulation is enabled, *NOT* for real
    32-bit kernels.
    
    This leads to really wierd situations where 32-bit programs
    lose their extended state when returning from a signal handler.
    The kernel copies the uninitialized (zero) 'fx_sw_reserved_ia32'
    out to userspace in save_xstate_epilog().  But when returning
    from the signal, the kernel errors out in check_for_xstate()
    when it does not see FP_XSTATE_MAGIC1 present (because it was
    zeroed).  This leads to the FPU/XSAVE state being initialized.
    
    For MPX, this leads to the most permissive state and means we
    silently lose bounds violations.  I think this would also mean
    that we could lose *ANY* FPU/SSE/AVX state.  I'm not sure why
    no one has spotted this bug.
    
    I believe this was broken by:
    
    	72a671ce ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels")
    
    way back in 2012.
    Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: dave@sr71.net
    Cc: fenghua.yu@intel.com
    Cc: yu-cheng.yu@intel.com
    Link: http://lkml.kernel.org/r/20151111002354.A0799571@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    [ luis: backported to 3.16:
      - file and function rename:
        * arch/x86/kernel/fpu/signal.c -> arch/x86/kernel/xsave.c
        * fpu__init_prepare_fx_sw_frame() -> prepare_fx_sw_frame()
      - use 'i387_fsave_struct' instead of 'fregs_state'
      - adjusted context ]
    Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
    Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
    2d08f031
xsave.c 15.9 KB