1. 27 7月, 2016 1 次提交
  2. 03 5月, 2016 1 次提交
    • S
      signals/sigaltstack, x86/signals: Unify the x86 sigaltstack check with other architectures · 0b4521e8
      Stas Sergeev 提交于
      Currently x86's get_sigframe() checks for "current->sas_ss_size"
      to determine whether there is a need to switch to sigaltstack.
      The common practice used by all other arches is to check for
      sas_ss_flags(sp) == 0
      
      This patch makes the code consistent with other architectures.
      
      The slight complexity of the patch is added by the optimization on
      !sigstack check that was requested by Andy Lutomirski: sas_ss_flags(sp)==0
      already implies that we are not on a sigstack, so the code is shuffled
      to avoid the duplicate checking.
      
      This patch should have no user-visible impact.
      Signed-off-by: NStas Sergeev <stsp@list.ru>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.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: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-api@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1460665206-13646-2-git-send-email-stsp@list.ruSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0b4521e8
  3. 19 4月, 2016 1 次提交
  4. 13 4月, 2016 1 次提交
  5. 17 2月, 2016 2 次提交
    • A
      x86/signal/64: Re-add support for SS in the 64-bit signal context · 6c25da5a
      Andy Lutomirski 提交于
      This is a second attempt to make the improvements from c6f20629
      ("x86/signal/64: Fix SS handling for signals delivered to 64-bit
      programs"), which was reverted by 51adbfbba5c6 ("x86/signal/64: Add
      support for SS in the 64-bit signal context").
      
      This adds two new uc_flags flags.  UC_SIGCONTEXT_SS will be set for
      all 64-bit signals (including x32).  It indicates that the saved SS
      field is valid and that the kernel supports the new behavior.
      
      The goal is to fix a problems with signal handling in 64-bit tasks:
      SS wasn't saved in the 64-bit signal context, making it awkward to
      determine what SS was at the time of signal delivery and making it
      impossible to return to a non-flat SS (as calling sigreturn clobbers
      SS).
      
      This also made it extremely difficult for 64-bit tasks to return to
      fully-defined 16-bit contexts, because only the kernel can easily do
      espfix64, but sigreturn was unable to set a non-flag SS:ESP.
      (DOSEMU has a monstrous hack to partially work around this
      limitation.)
      
      If we could go back in time, the correct fix would be to make 64-bit
      signals work just like 32-bit signals with respect to SS: save it
      in signal context, reset it when delivering a signal, and restore
      it in sigreturn.
      
      Unfortunately, doing that (as I tried originally) breaks DOSEMU:
      DOSEMU wouldn't reset the signal context's SS when clearing the LDT
      and changing the saved CS to 64-bit mode, since it predates the SS
      context field existing in the first place.
      
      This patch is a bit more complicated, and it tries to balance a
      bunch of goals.  It makes most cases of changing ucontext->ss during
      signal handling work as expected.
      
      I do this by special-casing the interesting case.  On sigreturn,
      ucontext->ss will be honored by default, unless the ucontext was
      created from scratch by an old program and had a 64-bit CS
      (unfortunately, CRIU can do this) or was the result of changing a
      32-bit signal context to 64-bit without resetting SS (as DOSEMU
      does).
      
      For the benefit of new 64-bit software that uses segmentation (new
      versions of DOSEMU might), the new behavior can be detected with a
      new ucontext flag UC_SIGCONTEXT_SS.
      
      To avoid compilation issues, __pad0 is left as an alias for ss in
      ucontext.
      
      The nitty-gritty details are documented in the header file.
      
      This patch also re-enables the sigreturn_64 and ldt_gdt_64 selftests,
      as the kernel change allows both of them to pass.
      Tested-by: NStas Sergeev <stsp@list.ru>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/749149cbfc3e75cd7fcdad69a854b399d792cc6f.1455664054.git.luto@kernel.org
      [ Small readability edit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      6c25da5a
    • A
      x86/signal/64: Fix SS if needed when delivering a 64-bit signal · 8ff5bd2e
      Andy Lutomirski 提交于
      Signals are always delivered to 64-bit tasks with CS set to a long
      mode segment.  In long mode, SS doesn't matter as long as it's a
      present writable segment.
      
      If SS starts out invalid (this can happen if the signal was caused
      by an IRET fault or was delivered on the way out of set_thread_area
      or modify_ldt), then IRET to the signal handler can fail, eventually
      killing the task.
      
      The straightforward fix would be to simply reset SS when delivering
      a signal.  That breaks DOSEMU, though: 64-bit builds of DOSEMU rely
      on SS being set to the faulting SS when signals are delivered.
      
      As a compromise, this patch leaves SS alone so long as it's valid.
      
      The net effect should be that the behavior of successfully delivered
      signals is unchanged.  Some signals that would previously have
      failed to be delivered will now be delivered successfully.
      
      This has no effect for x32 or 32-bit tasks: their signal handlers
      were already called with SS == __USER_DS.
      
      (On Xen, there's a slight hole: if a task sets SS to a writable
       *kernel* data segment, then we will fail to identify it as invalid
       and we'll still kill the task.  If anyone cares, this could be fixed
       with a new paravirt hook.)
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/163c6e1eacde41388f3ff4d2fe6769be651d7b6e.1455664054.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8ff5bd2e
  6. 19 1月, 2016 1 次提交
  7. 06 12月, 2015 1 次提交
  8. 07 10月, 2015 1 次提交
  9. 01 10月, 2015 1 次提交
  10. 08 9月, 2015 1 次提交
  11. 14 8月, 2015 1 次提交
  12. 31 7月, 2015 2 次提交
    • B
      x86/vm86: Clean up vm86.h includes · ba3e127e
      Brian Gerst 提交于
      vm86.h was being implicitly included in alot of places via
      processor.h, which in turn got it from math_emu.h.  Break that
      chain and explicitly include vm86.h in all files that need it.
      Also remove unused vm86 field from math_emu_info.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      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>
      Link: http://lkml.kernel.org/r/1438148483-11932-7-git-send-email-brgerst@gmail.com
      [ Fixed build failure. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ba3e127e
    • B
      x86/vm86: Use the normal pt_regs area for vm86 · 5ed92a8a
      Brian Gerst 提交于
      Change to use the normal pt_regs area to enter and exit vm86
      mode.  This is done by increasing the padding at the top of the
      stack to make room for the extra vm86 segment slots in the IRET
      frame.  It then saves the 32-bit regs in the off-stack vm86
      data, and copies in the vm86 regs.  Exiting back to 32-bit mode
      does the reverse.  This allows removing the hacks to jump
      directly into the exit asm code due to having to change the
      stack pointer.  Returning normally from the vm86 syscall and the
      exception handlers allows things like ptrace and auditing to work properly.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      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>
      Link: http://lkml.kernel.org/r/1438148483-11932-5-git-send-email-brgerst@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5ed92a8a
  13. 07 7月, 2015 1 次提交
  14. 06 7月, 2015 1 次提交
  15. 19 5月, 2015 12 次提交
    • I
      x86/fpu: Split out fpu/signal.h from fpu/internal.h for signal frame handling functions · fcbc99c4
      Ingo Molnar 提交于
      Most of the FPU does not use them, so split it out and include
      them in signal.c and ia32_signal.c
      
      Also fix header file dependency assumption in fpu/core.c.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      fcbc99c4
    • I
      x86/fpu: Move is_ia32*frame() helpers out of fpu/internal.h · 05012c13
      Ingo Molnar 提交于
      Move them to their only user. This makes the code easier to read,
      the header is less cluttered, and it also speeds up the build a bit.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      05012c13
    • I
      x86/fpu: Merge fpu__reset() and fpu__clear() · fbce7782
      Ingo Molnar 提交于
      With recent cleanups and fixes the fpu__reset() and fpu__clear()
      functions have become almost identical in functionality: the only
      difference is that fpu__reset() assumed that the fpstate
      was already active in the eagerfpu case, while fpu__clear()
      activated it if it was inactive.
      
      This distinction almost never matters, the only case where such
      fpstate activation happens if if the init thread (PID 1) gets exec()-ed
      for the first time.
      
      So keep fpu__clear() and change all fpu__reset() uses to
      fpu__clear() to simpify the logic.
      
      ( In a later patch we'll further simplify fpu__clear() by making
        sure that all contexts it is called on are already active. )
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      fbce7782
    • I
      x86/fpu: Move the signal frame handling code closer to each other · 82c0e45e
      Ingo Molnar 提交于
      Consolidate more signal frame related functions:
      
         text      data    bss     dec       filename
         14108070  2575280 1634304 18317654  vmlinux.before
         14107944  2575344 1634304 18317592  vmlinux.after
      
      Also, while moving it, rename alloc_mathframe() to fpu__alloc_mathframe().
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      82c0e45e
    • I
      x86/fpu: Rename restore_xstate_sig() to fpu__restore_sig() · 9dfe99b7
      Ingo Molnar 提交于
      restore_xstate_sig() is a misnomer: it's not limited to 'xstate' at all,
      it is the high level 'restore FPU state from a signal frame' function
      that works with all legacy FPU formats as well.
      
      Rename it (and its helper) accordingly, and also move it to the
      fpu__*() namespace.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9dfe99b7
    • I
      x86/fpu: Synchronize the naming of drop_fpu() and fpu_reset_state() · 50338615
      Ingo Molnar 提交于
      drop_fpu() and fpu_reset_state() are similar in functionality
      and in scope, yet this is not apparent from their names.
      
      drop_fpu() deactivates FPU contents (both the fpregs and the fpstate),
      but leaves register contents intact in the eager-FPU case, mostly as an
      optimization. It disables fpregs in the lazy FPU case. The drop_fpu()
      method can be used to destroy FPU state in an optimized way, when we
      know that a new state will be loaded before user-space might see
      any remains of the old FPU state:
      
           - such as in sys_exit()'s exit_thread() where we know this task
             won't execute any user-space instructions anymore and the
             next context switch cleans up the FPU. The old FPU state
             might still be around in the eagerfpu case but won't be
             saved.
      
           - in __restore_xstate_sig(), where we use drop_fpu() before
             copying a new state into the fpstate and activating that one.
             No user-pace instructions can execute between those steps.
      
           - in sys_execve()'s fpu__clear(): there we use drop_fpu() in
             the !eagerfpu case, where it's equivalent to a full reinit.
      
      fpu_reset_state() is a stronger version of drop_fpu(): both in
      the eagerfpu and the lazy-FPU case it guarantees that fpregs
      are reinitialized to init state. This method is used in cases
      where we need a full reset:
      
           - handle_signal() uses fpu_reset_state() to reset the FPU state
             to init before executing a user-space signal handler. While we
             have already saved the original FPU state at this point, and
             always restore the original state, the signal handling code
             still has to do this reinit, because signals may interrupt
             any user-space instruction, and the FPU might be in various
             intermediate states (such as an unbalanced x87 stack) that is
             not immediately usable for general C signal handler code.
      
           - __restore_xstate_sig() uses fpu_reset_state() when the signal
             frame has no FP context. Since the signal handler may have
             modified the FPU state, it gets reset back to init state.
      
           - in another branch __restore_xstate_sig() uses fpu_reset_state()
             to handle a restoration error: when restore_user_xstate() fails
             to restore FPU state and we might have inconsistent FPU data,
             fpu_reset_state() is used to reset it back to a known good
             state.
      
           - __kernel_fpu_end() uses fpu_reset_state() in an error branch.
             This is in a 'must not trigger' error branch, so on bug-free
             kernels this never triggers.
      
           - fpu__restore() uses fpu_reset_state() in an error path
             as well: if the fpstate was set up with invalid FPU state
             (via ptrace or via a signal handler), then it's reset back
             to init state.
      
           - likewise, the scheduler's switch_fpu_finish() uses it in a
             restoration error path too.
      
      Move both drop_fpu() and fpu_reset_state() to the fpu__*() namespace
      and harmonize their naming with their function:
      
          fpu__drop()
          fpu__reset()
      
      This clearly shows that both methods operate on the full state of the
      FPU, just like fpu__restore().
      
      Also add comments to explain what each function does.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      50338615
    • I
      x86/fpu: Rename save_xstate_sig() to copy_fpstate_to_sigframe() · c8e14041
      Ingo Molnar 提交于
      Standardize the naming of save_xstate_sig() by renaming it to
      copy_fpstate_to_sigframe(): this tells us at a glance that
      the function copies an FPU fpstate to a signal frame.
      
      This naming also follows the naming of copy_fpregs_to_fpstate().
      
      Don't put 'xstate' into the name: since this is a generic name,
      it's expected that the function is able to handle xstate frames
      as well, beyond legacy frames.
      
      xstate used to be the odd case in the x86 FPU code - now it's the
      common case.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c8e14041
    • I
      x86/fpu: Rename fpu-internal.h to fpu/internal.h · 78f7f1e5
      Ingo Molnar 提交于
      This unifies all the FPU related header files under a unified, hiearchical
      naming scheme:
      
       - asm/fpu/types.h:      FPU related data types, needed for 'struct task_struct',
                               widely included in almost all kernel code, and hence kept
                               as small as possible.
      
       - asm/fpu/api.h:        FPU related 'public' methods exported to other subsystems.
      
       - asm/fpu/internal.h:   FPU subsystem internal methods
      
       - asm/fpu/xsave.h:      XSAVE support internal methods
      
      (Also standardize the header guard in asm/fpu/internal.h.)
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      78f7f1e5
    • I
      x86/fpu: Use 'struct fpu' in fpu_reset_state() · af2d94fd
      Ingo Molnar 提交于
      Migrate this function to pure 'struct fpu' usage.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      af2d94fd
    • I
      x86/fpu: Get rid of PF_USED_MATH usage, convert it to fpu->fpstate_active · c5bedc68
      Ingo Molnar 提交于
      Introduce a simple fpu->fpstate_active flag in the fpu context data structure
      and use that instead of PF_USED_MATH in task->flags.
      
      Testing for this flag byte should be slightly more efficient than
      testing a bit in a bitmask, but the main advantage is that most
      FPU functions can now be performed on a 'struct fpu' alone, they
      don't need access to 'struct task_struct' anymore.
      
      There's a slight linecount increase, mostly due to the 'fpu' local
      variables and due to extra comments. The local variables will go away
      once we move most of the FPU methods to pure 'struct fpu' parameters.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c5bedc68
    • I
      x86/fpu: Open code PF_USED_MATH usages · 4c138410
      Ingo Molnar 提交于
      PF_USED_MATH is used directly, but also in a handful of helper inlines.
      
      To ease the elimination of PF_USED_MATH, convert all inline helpers
      to open-coded PF_USED_MATH usage.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4c138410
    • I
      x86/fpu: Fix header file dependencies of fpu-internal.h · f89e32e0
      Ingo Molnar 提交于
      Fix a minor header file dependency bug in asm/fpu-internal.h: it
      relies on i387.h but does not include it. All users of fpu-internal.h
      included it explicitly.
      
      Also remove unnecessary includes, to reduce compilation time.
      
      This also makes it easier to use it as a standalone header file
      for FPU internals, such as an upcoming C module in arch/x86/kernel/fpu/.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f89e32e0
  16. 16 4月, 2015 1 次提交
    • O
      x86/ptrace: Fix the TIF_FORCED_TF logic in handle_signal() · fd0f86b6
      Oleg Nesterov 提交于
      When the TIF_SINGLESTEP tracee dequeues a signal,
      handle_signal() clears TIF_FORCED_TF and X86_EFLAGS_TF but
      leaves TIF_SINGLESTEP set.
      
      If the tracer does PTRACE_SINGLESTEP again, enable_single_step()
      sets X86_EFLAGS_TF but not TIF_FORCED_TF.  This means that the
      subsequent PTRACE_CONT doesn't not clear X86_EFLAGS_TF, and the
      tracee gets the wrong SIGTRAP.
      
      Test-case (needs -O2 to avoid prologue insns in signal handler):
      
      	#include <unistd.h>
      	#include <stdio.h>
      	#include <sys/ptrace.h>
      	#include <sys/wait.h>
      	#include <sys/user.h>
      	#include <assert.h>
      	#include <stddef.h>
      
      	void handler(int n)
      	{
      		asm("nop");
      	}
      
      	int child(void)
      	{
      		assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
      		signal(SIGALRM, handler);
      		kill(getpid(), SIGALRM);
      		return 0x23;
      	}
      
      	void *getip(int pid)
      	{
      		return (void*)ptrace(PTRACE_PEEKUSER, pid,
      					offsetof(struct user, regs.rip), 0);
      	}
      
      	int main(void)
      	{
      		int pid, status;
      
      		pid = fork();
      		if (!pid)
      			return child();
      
      		assert(wait(&status) == pid);
      		assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGALRM);
      
      		assert(ptrace(PTRACE_SINGLESTEP, pid, 0, SIGALRM) == 0);
      		assert(wait(&status) == pid);
      		assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
      		assert((getip(pid) - (void*)handler) == 0);
      
      		assert(ptrace(PTRACE_SINGLESTEP, pid, 0, SIGALRM) == 0);
      		assert(wait(&status) == pid);
      		assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
      		assert((getip(pid) - (void*)handler) == 1);
      
      		assert(ptrace(PTRACE_CONT, pid, 0,0) == 0);
      		assert(wait(&status) == pid);
      		assert(WIFEXITED(status) && WEXITSTATUS(status) == 0x23);
      
      		return 0;
      	}
      
      The last assert() fails because PTRACE_CONT wrongly triggers
      another single-step and X86_EFLAGS_TF can't be cleared by
      debugger until the tracee does sys_rt_sigreturn().
      
      Change handle_signal() to do user_disable_single_step() if
      stepping, we do not need to preserve TIF_SINGLESTEP because we
      are going to do ptrace_notify(), and it is simply wrong to leak
      this bit.
      
      While at it, change the comment to explain why we also need to
      clear TF unconditionally after setup_rt_frame().
      
      Note: in the longer term we should probably change
      setup_sigcontext() to use get_flags() and then just remove this
      user_disable_single_step().  And, the state of TIF_FORCED_TF can
      be wrong after restore_sigcontext() which can set/clear TF, this
      needs another fix.
      
      This fix fixes the 'single_step_syscall_32' testcase in
      the x86 testsuite:
      
      Before:
      
      	~/linux/tools/testing/selftests/x86> ./single_step_syscall_32
      	[RUN]   Set TF and check nop
      	[OK]    Survived with TF set and 9 traps
      	[RUN]   Set TF and check int80
      	[OK]    Survived with TF set and 9 traps
      	[RUN]   Set TF and check a fast syscall
      	[WARN]  Hit 10000 SIGTRAPs with si_addr 0xf7789cc0, ip 0xf7789cc0
      	Trace/breakpoint trap (core dumped)
      
      After:
      
      	~/linux/linux/tools/testing/selftests/x86> ./single_step_syscall_32
      	[RUN]   Set TF and check nop
      	[OK]    Survived with TF set and 9 traps
      	[RUN]   Set TF and check int80
      	[OK]    Survived with TF set and 9 traps
      	[RUN]   Set TF and check a fast syscall
      	[OK]    Survived with TF set and 39 traps
      	[RUN]   Fast syscall with TF cleared
      	[OK]    Nothing unexpected happened
      Reported-by: NEvan Teran <eteran@alum.rit.edu>
      Reported-by: NPedro Alves <palves@redhat.com>
      Tested-by: NAndres Freund <andres@anarazel.de>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      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: Thomas Gleixner <tglx@linutronix.de>
      [ Added x86 self-test info. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      fd0f86b6
  17. 13 4月, 2015 1 次提交
  18. 06 4月, 2015 1 次提交
  19. 23 3月, 2015 2 次提交
    • B
      x86/fpu: Rename drop_init_fpu() to fpu_reset_state() · b85e67d1
      Borislav Petkov 提交于
      Call it what it does and in accordance with the context where it is
      used: we reset the FPU state either because we were unable to restore it
      from the one saved in the task or because we simply want to reset it.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      b85e67d1
    • B
      x86/asm/entry: Fix execve() and sigreturn() syscalls to always return via IRET · 1daeaa31
      Brian Gerst 提交于
      Both the execve() and sigreturn() family of syscalls have the
      ability to change registers in ways that may not be compatabile
      with the syscall path they were called from.
      
      In particular, SYSRET and SYSEXIT can't handle non-default %cs and %ss,
      and some bits in eflags.
      
      These syscalls have stubs that are hardcoded to jump to the IRET path,
      and not return to the original syscall path.
      
      The following commit:
      
         76f5df43 ("Always allocate a complete "struct pt_regs" on the kernel stack")
      
      recently changed this for some 32-bit compat syscalls, but introduced a bug where
      execve from a 32-bit program to a 64-bit program would fail because it still returned
      via SYSRETL. This caused Wine to fail when built for both 32-bit and 64-bit.
      
      This patch sets TIF_NOTIFY_RESUME for execve() and sigreturn() so
      that the IRET path is always taken on exit to userspace.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1426978461-32089-1-git-send-email-brgerst@gmail.com
      [ Improved the changelog and comments. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1daeaa31
  20. 17 3月, 2015 2 次提交
  21. 13 2月, 2015 1 次提交
    • A
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski 提交于
      If an attacker can cause a controlled kernel stack overflow, overwriting
      the restart block is a very juicy exploit target.  This is because the
      restart_block is held in the same memory allocation as the kernel stack.
      
      Moving the restart block to struct task_struct prevents this exploit by
      making the restart_block harder to locate.
      
      Note that there are other fields in thread_info that are also easy
      targets, at least on some architectures.
      
      It's also a decent simplification, since the restart code is more or less
      identical on all architectures.
      
      [james.hogan@imgtec.com: metag: align thread_info::supervisor_stack]
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NRichard Weinberger <richard@nod.at>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
  22. 07 1月, 2015 1 次提交
  23. 03 9月, 2014 1 次提交
    • O
      x86, fpu: shift drop_init_fpu() from save_xstate_sig() to handle_signal() · 66463db4
      Oleg Nesterov 提交于
      save_xstate_sig()->drop_init_fpu() doesn't look right. setup_rt_frame()
      can fail after that, in this case the next setup_rt_frame() triggered
      by SIGSEGV won't save fpu simply because the old state was lost. This
      obviously mean that fpu won't be restored after sys_rt_sigreturn() from
      SIGSEGV handler.
      
      Shift drop_init_fpu() into !failed branch in handle_signal().
      
      Test-case (needs -O2):
      
      	#include <stdio.h>
      	#include <signal.h>
      	#include <unistd.h>
      	#include <sys/syscall.h>
      	#include <sys/mman.h>
      	#include <pthread.h>
      	#include <assert.h>
      
      	volatile double D;
      
      	void test(double d)
      	{
      		int pid = getpid();
      
      		for (D = d; D == d; ) {
      			/* sys_tkill(pid, SIGHUP); asm to avoid save/reload
      			 * fp regs around "C" call */
      			asm ("" : : "a"(200), "D"(pid), "S"(1));
      			asm ("syscall" : : : "ax");
      		}
      
      		printf("ERR!!\n");
      	}
      
      	void sigh(int sig)
      	{
      	}
      
      	char altstack[4096 * 10] __attribute__((aligned(4096)));
      
      	void *tfunc(void *arg)
      	{
      		for (;;) {
      			mprotect(altstack, sizeof(altstack), PROT_READ);
      			mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE);
      		}
      	}
      
      	int main(void)
      	{
      		stack_t st = {
      			.ss_sp = altstack,
      			.ss_size = sizeof(altstack),
      			.ss_flags = SS_ONSTACK,
      		};
      
      		struct sigaction sa = {
      			.sa_handler = sigh,
      		};
      
      		pthread_t pt;
      
      		sigaction(SIGSEGV, &sa, NULL);
      		sigaltstack(&st, NULL);
      		sa.sa_flags = SA_ONSTACK;
      		sigaction(SIGHUP, &sa, NULL);
      
      		pthread_create(&pt, NULL, tfunc, NULL);
      
      		test(123.456);
      		return 0;
      	}
      Reported-by: NBean Anderson <bean@azulsystems.com>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Link: http://lkml.kernel.org/r/20140902175713.GA21646@redhat.com
      Cc: <stable@kernel.org> # v3.7+
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      66463db4
  24. 24 6月, 2014 1 次提交
  25. 06 5月, 2014 1 次提交
    • A
      x86, vdso: Reimplement vdso.so preparation in build-time C · 6f121e54
      Andy Lutomirski 提交于
      Currently, vdso.so files are prepared and analyzed by a combination
      of objcopy, nm, some linker script tricks, and some simple ELF
      parsers in the kernel.  Replace all of that with plain C code that
      runs at build time.
      
      All five vdso images now generate .c files that are compiled and
      linked in to the kernel image.
      
      This should cause only one userspace-visible change: the loaded vDSO
      images are stripped more heavily than they used to be.  Everything
      outside the loadable segment is dropped.  In particular, this causes
      the section table and section name strings to be missing.  This
      should be fine: real dynamic loaders don't load or inspect these
      tables anyway.  The result is roughly equivalent to eu-strip's
      --strip-sections option.
      
      The purpose of this change is to enable the vvar and hpet mappings
      to be moved to the page following the vDSO load segment.  Currently,
      it is possible for the section table to extend into the page after
      the load segment, so, if we map it, it risks overlapping the vvar or
      hpet page.  This happens whenever the load segment is just under a
      multiple of PAGE_SIZE.
      
      The only real subtlety here is that the old code had a C file with
      inline assembler that did 'call VDSO32_vsyscall' and a linker script
      that defined 'VDSO32_vsyscall = __kernel_vsyscall'.  This most
      likely worked by accident: the linker script entry defines a symbol
      associated with an address as opposed to an alias for the real
      dynamic symbol __kernel_vsyscall.  That caused ld to relocate the
      reference at link time instead of leaving an interposable dynamic
      relocation.  Since the VDSO32_vsyscall hack is no longer needed, I
      now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it
      work.  vdso2c will generate an error and abort the build if the
      resulting image contains any dynamic relocations, so we won't
      silently generate bad vdso images.
      
      (Dynamic relocations are a problem because nothing will even attempt
      to relocate the vdso.)
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Link: http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.luto@amacapital.netSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      6f121e54