1. 05 Oct, 2018 3 commits
  2. 02 Aug, 2018 1 commit
    • Russell King's avatar
      ARM: vfp: use __copy_from_user() when restoring VFP state · 42019fc5
      Russell King authored
      
      
      __get_user_error() is used as a fast accessor to make copying structure
      members in the signal handling path as efficient as possible.  However,
      with software PAN and the recent Spectre variant 1, the efficiency is
      reduced as these are no longer fast accessors.
      
      In the case of software PAN, it has to switch the domain register around
      each access, and with Spectre variant 1, it would have to repeat the
      access_ok() check for each access.
      
      Use __copy_from_user() rather than __get_user_err() for individual
      members when restoring VFP state.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      42019fc5
  3. 26 Jul, 2018 1 commit
    • Russell King's avatar
      ARM: signal: copy registers using __copy_from_user() · c32cd419
      Russell King authored
      
      
      __get_user_error() is used as a fast accessor to make copying structure
      members in the signal handling path as efficient as possible.  However,
      with software PAN and the recent Spectre variant 1, the efficiency is
      reduced as these are no longer fast accessors.
      
      In the case of software PAN, it has to switch the domain register around
      each access, and with Spectre variant 1, it would have to repeat the
      access_ok() check for each access.
      
      It becomes much more efficient to use __copy_from_user() instead, so
      let's use this for the ARM integer registers.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      c32cd419
  4. 17 Sep, 2017 2 commits
    • Thomas Garnier's avatar
      arm/syscalls: Optimize address limit check · e33f8d32
      Thomas Garnier authored
      
      
      Disable the generic address limit check in favor of an architecture
      specific optimized implementation. The generic implementation using
      pending work flags did not work well with ARM and alignment faults.
      
      The address limit is checked on each syscall return path to user-mode
      path as well as the irq user-mode return function. If the address limit
      was changed, a function is called to report data corruption (stopping
      the kernel or process based on configuration).
      
      The address limit check has to be done before any pending work because
      they can reset the address limit and the process is killed using a
      SIGKILL signal. For example the lkdtm address limit check does not work
      because the signal to kill the process will reset the user-mode address
      limit.
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarLeonard Crestez <leonard.crestez@nxp.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: Yonghong Song <yhs@fb.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1504798247-48833-4-git-send-email-keescook@chromium.org
      e33f8d32
    • Thomas Garnier's avatar
      Revert "arm/syscalls: Check address limit on user-mode return" · 2404269b
      Thomas Garnier authored
      This reverts commit 73ac5d6a
      
      .
      
      The work pending loop can call set_fs after addr_limit_user_check
      removed the _TIF_FSCHECK flag. This may happen at anytime based on how
      ARM handles alignment exceptions. It leads to an infinite loop condition.
      
      After discussion, it has been agreed that the generic approach is not
      tailored to the ARM architecture and any fix might not be complete. This
      patch will be replaced by an architecture specific implementation. The
      work flag approach will be kept for other architectures.
      Reported-by: default avatarLeonard Crestez <leonard.crestez@nxp.com>
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: Yonghong Song <yhs@fb.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1504798247-48833-3-git-send-email-keescook@chromium.org
      2404269b
  5. 10 Sep, 2017 1 commit
    • Nicolas Pitre's avatar
      ARM: signal handling support for FDPIC_FUNCPTRS functions · 5c165953
      Nicolas Pitre authored
      
      
      Signal handlers are not direct function pointers but pointers to function
      descriptor in that case. Therefore we must retrieve the actual function
      address and load the GOT value into r9 from the descriptor before branching
      to the actual handler.
      
      If a restorer is provided, we also have to load its address and GOT from
      its descriptor. That descriptor address and the code to load it is pushed
      onto the stack to be executed as soon as the signal handler returns.
      
      However, to be compatible with NX stacks, the FDPIC bounce code is also
      copied to the signal page along with the other code stubs. Therefore this
      code must get at the descriptor address whether it executes from the stack
      or the signal page. To do so we use the stack pointer which points at the
      signal stack frame where the descriptor address was stored. Because the
      rt signal frame is different from the simpler frame, two versions of the
      bounce code are needed, and two variants (ARM and Thumb) as well. The
      asm-offsets facility is used to determine the actual offset in the signal
      frame for each version, meaning that struct sigframe and rt_sigframe had
      to be moved to a separate file.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarMickael GUENE <mickael.guene@st.com>
      Tested-by: default avatarVincent Abriou <vincent.abriou@st.com>
      Tested-by: default avatarAndras Szemzo <szemzo.andras@gmail.com>
      5c165953
  6. 24 Jul, 2017 2 commits
    • Dave Martin's avatar
      ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[] · ce184a0d
      Dave Martin authored
      
      
      In kernels with CONFIG_IWMMXT=y running on non-iWMMXt hardware, the
      signal frame can be left partially uninitialised in such a way
      that userspace cannot parse uc_regspace[] safely.  In particular,
      this means that the VFP registers cannot be located reliably in the
      signal frame when a multi_v7_defconfig kernel is run on the
      majority of platforms.
      
      The cause is that the uc_regspace[] is laid out statically based on
      the kernel config, but the decision of whether to save/restore the
      iWMMXt registers must be a runtime decision.
      
      To minimise breakage of software that may assume a fixed layout,
      this patch emits a dummy block of the same size as iwmmxt_sigframe,
      for non-iWMMXt threads.  However, the magic and size of this block
      are now filled in to help parsers skip over it.  A new DUMMY_MAGIC
      is defined for this purpose.
      
      It is probably legitimate (if non-portable) for userspace to
      manufacture its own sigframe for sigreturn, and there is no obvious
      reason why userspace should be required to insert a DUMMY_MAGIC
      block when running on non-iWMMXt hardware, when omitting it has
      worked just fine forever in other configurations.  So in this case,
      sigreturn does not require this block to be present.
      Reported-by: default avatarEdmund Grimley-Evans <Edmund.Grimley-Evans@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      ce184a0d
    • Dave Martin's avatar
      ARM: 8686/1: iwmmxt: Add missing __user annotations to sigframe accessors · 26958355
      Dave Martin authored
      
      
      preserve_iwmmxt_context() and restore_iwmmxt_context() lack __user
      accessors on their arguments pointing to the user signal frame.
      
      There does not be appear to be a bug here, but this omission is
      inconsistent with the crunch and vfp sigframe access functions.
      
      This patch adds the annotations, for consistency.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      26958355
  7. 08 Jul, 2017 1 commit
    • Thomas Garnier's avatar
      arm/syscalls: Check address limit on user-mode return · 73ac5d6a
      Thomas Garnier authored
      Ensure the address limit is a user-mode segment before returning to
      user-mode. Otherwise a process can corrupt kernel-mode memory and
      elevate privileges [1].
      
      The set_fs function sets the TIF_SETFS flag to force a slow path on
      return. In the slow path, the address limit is checked to be USER_DS if
      needed.
      
      The TIF_SETFS flag is added to _TIF_WORK_MASK shifting _TIF_SYSCALL_WORK
      for arm instruction immediate support. The global work mask is too big
      to used on a single instruction so adapt ret_fast_syscall.
      
      [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990
      
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: kernel-hardening@lists.openwall.com
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-api@vger.kernel.org
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Link: http://lkml.kernel.org/r/20170615011203.144108-2-thgarnie@google.com
      73ac5d6a
  8. 16 Sep, 2015 2 commits
  9. 25 Aug, 2015 1 commit
  10. 12 Apr, 2015 1 commit
  11. 13 Feb, 2015 1 commit
    • Andy Lutomirski's avatar
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski authored
      
      
      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: default avatarAndy 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: default avatarRichard 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: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
  12. 17 Nov, 2014 1 commit
  13. 18 Mar, 2014 1 commit
  14. 07 Nov, 2013 1 commit
  15. 19 Oct, 2013 1 commit
  16. 03 Aug, 2013 2 commits
  17. 01 Aug, 2013 1 commit
    • Russell King's avatar
      ARM: move signal handlers into a vdso-like page · 48be69a0
      Russell King authored
      
      
      Move the signal handlers into a VDSO page rather than keeping them in
      the vectors page.  This allows us to place them randomly within this
      page, and also map the page at a random location within userspace
      further protecting these code fragments from ROP attacks.  The new
      VDSO page is also poisoned in the same way as the vector page.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      48be69a0
  18. 17 Jun, 2013 1 commit
    • Jonathan Austin's avatar
      ARM: mpu: protect the vectors page with an MPU region · 9dfc28b6
      Jonathan Austin authored
      
      
      Without an MMU it is possible for userspace programs to start executing code
      in places that they have no business executing. The MPU allows some level of
      protection against this.
      
      This patch protects the vectors page from access by userspace processes.
      Userspace tasks that dereference a null pointer are already protected by an
      svc at 0x0 that kills them. However when tasks use an offset from a null
      pointer (eg a function in a null struct) they miss this carefully placed svc
      and enter the exception vectors in user mode, ending up in the kernel.
      
      This patch causes programs that do this to receive a SEGV instead of happily
      entering the kernel in user-mode, and hence avoid a 'Bad Mode' panic.
      
      As part of this change it is necessary to make sigreturn happen via the
      stack when there is not an sa_restorer function. This change is invisible to
      userspace, and irrelevant to code compiled using a uClibc toolchain, which
      always uses an sa_restorer function.
      
      Because we don't get to remap the vectors in !MMU kuser_helpers are not
      in a defined location, and hence aren't usable. This means we don't need to
      worry about keeping them accessible from PL0
      Signed-off-by: default avatarJonathan Austin <jonathan.austin@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      CC: Nicolas Pitre <nico@linaro.org>
      CC: Catalin Marinas <catalin.marinas@arm.com>
      9dfc28b6
  19. 14 Feb, 2013 1 commit
  20. 03 Feb, 2013 3 commits
  21. 01 Oct, 2012 1 commit
  22. 28 Jul, 2012 5 commits
  23. 05 Jul, 2012 2 commits
  24. 01 Jun, 2012 4 commits