1. 14 6月, 2018 1 次提交
    • L
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds 提交于
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      supported.
      
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      directly.
      
      HOWEVER.
      
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_NONE is not set
        # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_STACKPROTECTOR_AUTO=y
      
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_STACKPROTECTOR=y
        CONFIG_STACKPROTECTOR_STRONG=y
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  2. 05 1月, 2018 1 次提交
    • S
      arm: do not use print_symbol() · 3ea70d7d
      Sergey Senozhatsky 提交于
      print_symbol() is a very old API that has been obsoleted by %pS format
      specifier in a normal printk() call.
      
      Replace print_symbol() with a direct printk("%pS") call.
      
      Link: http://lkml.kernel.org/r/20171211125025.2270-2-sergey.senozhatsky@gmail.com
      To: Andrew Morton <akpm@linux-foundation.org>
      To: Russell King <linux@armlinux.org.uk>
      To: Catalin Marinas <catalin.marinas@arm.com>
      To: Mark Salter <msalter@redhat.com>
      To: Tony Luck <tony.luck@intel.com>
      To: David Howells <dhowells@redhat.com>
      To: Yoshinori Sato <ysato@users.sourceforge.jp>
      To: Guan Xuetao <gxt@mprc.pku.edu.cn>
      To: Borislav Petkov <bp@alien8.de>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      To: Thomas Gleixner <tglx@linutronix.de>
      To: Peter Zijlstra <peterz@infradead.org>
      To: Vineet Gupta <vgupta@synopsys.com>
      To: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-sh@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: x86@kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      [pmladek@suse.com: updated commit message, fixed complication warning]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      3ea70d7d
  3. 21 6月, 2017 1 次提交
    • D
      ARM: 8683/1: ARM32: Support mremap() for sigpage/vDSO · 280e87e9
      Dmitry Safonov 提交于
      CRIU restores application mappings on the same place where they
      were before Checkpoint. That means, that we need to move vDSO
      and sigpage during restore on exactly the same place where
      they were before C/R.
      
      Make mremap() code update mm->context.{sigpage,vdso} pointers
      during VMA move. Sigpage is used for landing after handling
      a signal - if the pointer is not updated during moving, the
      application might crash on any signal after mremap().
      
      vDSO pointer on ARM32 is used only for setting auxv at this moment,
      update it during mremap() in case of future usage.
      
      Without those updates, current work of CRIU on ARM32 is not reliable.
      Historically, we error Checkpointing if we find vDSO page on ARM32
      and suggest user to disable CONFIG_VDSO.
      But that's not correct - it goes from x86 where signal processing
      is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
      with `CONFIG_VDSO=n'.
      
      Looks like C/R was working by luck - because userspace on ARM32 at
      this moment always sets SA_RESTORER.
      Signed-off-by: NDmitry Safonov <dsafonov@virtuozzo.com>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Pavel Emelyanov <xemul@virtuozzo.com>
      Cc: Christopher Covington <cov@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      280e87e9
  4. 24 5月, 2017 1 次提交
    • J
      ARM: 8673/1: Fix __show_regs output timestamps · 801f19b9
      Joe Perches 提交于
      Multiple line formats are not preferred as the second and
      subsequent lines may not have timestamps.
      
      Lacking timestamps makes reading the output a bit difficult.
      This also makes arm/arm64 output more similar.
      
      Previous:
      
      [ 1514.093231] pc : [<bf79c304>]    lr : [<bf79ced8>]    psr: a00f0013
      sp : ecdd7e20  ip : 00000000  fp : ffffffff
      
      New:
      
      [ 1514.093231] pc : [<bf79c304>]    lr : [<bf79ced8>]    psr: a00f0013
      [ 1514.105316] sp : ecdd7e20  ip : 00000000  fp : ffffffff
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      801f19b9
  5. 02 3月, 2017 3 次提交
  6. 12 10月, 2016 1 次提交
  7. 07 7月, 2016 1 次提交
  8. 23 6月, 2016 1 次提交
  9. 24 5月, 2016 1 次提交
  10. 21 5月, 2016 1 次提交
    • J
      exit_thread: accept a task parameter to be exited · e6464694
      Jiri Slaby 提交于
      We need to call exit_thread from copy_process in a fail path.  So make it
      accept task_struct as a parameter.
      
      [v2]
      * s390: exit_thread_runtime_instr doesn't make sense to be called for
        non-current tasks.
      * arm: fix the comment in vfp_thread_copy
      * change 'me' to 'tsk' for task_struct
      * now we can change only archs that actually have exit_thread
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e6464694
  11. 05 12月, 2015 1 次提交
  12. 10 9月, 2015 1 次提交
    • R
      ARM: uaccess: fix undefined instruction on ARMv7M/noMMU · af4cb25d
      Russell King 提交于
      The use of get_domain() in copy_thread() results in an oops on
      ARMv7M/noMMU systems.  The thread cpu_domain value is only used when
      CONFIG_CPU_USE_DOMAINS is enabled, so there's no need to save the
      value in copy_thread() except when this is enabled, and this option
      will never be enabled on these platforms.
      
      Unhandled exception: IPSR = 00000006 LR = fffffff1
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-next-20150909-00001-gb8ec5ad #41
      Hardware name: NXP LPC18xx/43xx (Device Tree)
      task: 2823fbe0 ti: 2823c000 task.ti: 2823c000
      PC is at copy_thread+0x18/0x92
      LR is at copy_thread+0x19/0x92
      pc : [<2800a46e>]    lr : [<2800a46f>]    psr: 4100000b
      sp : 2823df00  ip : 00000000  fp : 287c81c0
      r10: 00000000  r9 : 00800300  r8 : 287c8000
      r7 : 287c8000  r6 : 2818908d  r5 : 00000000  r4 : 287ca000
      r3 : 00000000  r2 : 00000000  r1 : fffffff0  r0 : 287ca048
      xPSR: 4100000b
      Reported-by: NAriel D'Alessandro <ariel@vanguardiasur.com.ar>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      af4cb25d
  13. 27 8月, 2015 1 次提交
    • R
      ARM: software-based priviledged-no-access support · a5e090ac
      Russell King 提交于
      Provide a software-based implementation of the priviledged no access
      support found in ARMv8.1.
      
      Userspace pages are mapped using a different domain number from the
      kernel and IO mappings.  If we switch the user domain to "no access"
      when we enter the kernel, we can prevent the kernel from touching
      userspace.
      
      However, the kernel needs to be able to access userspace via the
      various user accessor functions.  With the wrapping in the previous
      patch, we can temporarily enable access when the kernel needs user
      access, and re-disable it afterwards.
      
      This allows us to trap non-intended accesses to userspace, eg, caused
      by an inadvertent dereference of the LIST_POISON* values, which, with
      appropriate user mappings setup, can be made to succeed.  This in turn
      can allow use-after-free bugs to be further exploited than would
      otherwise be possible.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a5e090ac
  14. 26 8月, 2015 1 次提交
  15. 21 8月, 2015 1 次提交
    • R
      ARM: domains: switch to keeping domain value in register · 1eef5d2f
      Russell King 提交于
      Rather than modifying both the domain access control register and our
      per-thread copy, modify only the domain access control register, and
      use the per-thread copy to save and restore the register over context
      switches.  We can also avoid the explicit initialisation of the
      init thread_info structure.
      
      This allows us to avoid needing to gain access to the thread information
      at the uaccess control sites.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1eef5d2f
  16. 02 4月, 2015 2 次提交
    • R
      ARM: move reboot code to arch/arm/kernel/reboot.c · 045ab94e
      Russell King 提交于
      Move shutdown and reboot related code to a separate file, out of
      process.c.  This helps to avoid polluting process.c with non-process
      related code.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      045ab94e
    • R
      ARM: fix broken hibernation · 767bf7e7
      Russell King 提交于
      Normally, when a CPU wants to clear a cache line to zero in the external
      L2 cache, it would generate bus cycles to write each word as it would do
      with any other data access.
      
      However, a Cortex A9 connected to a L2C-310 has a specific feature where
      the CPU can detect this operation, and signal that it wants to zero an
      entire cache line.  This feature, known as Full Line of Zeros (FLZ),
      involves a non-standard AXI signalling mechanism which only the L2C-310
      can properly interpret.
      
      There are separate enable bits in both the L2C-310 and the Cortex A9 -
      the L2C-310 needs to be enabled and have the FLZ enable bit set in the
      auxiliary control register before the Cortex A9 has this feature
      enabled.
      
      Unfortunately, the suspend code was not respecting this - it's not
      obvious from the code:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image()
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      At this point, we end up with the L2C disabled, but the Cortex A9 with
      FLZ enabled - which means any memset() or zeroing of a full cache line
      will fail to take effect.
      
      A similar issue exists in the resume path, but it's slightly more
      complex:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image() /* image with A9 auxcr saved */
      ...
      swsusp_arch_resume()
       call_with_stack()
        arch_restore_image() /* restores image with A9 auxcr saved above */
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.
      
      There's no need to turn off the L2C in either of these two paths; there
      are benefits from not doing so - for example, the page copies will be
      faster with the L2C enabled.
      
      Hence, fix this by providing a variant of soft_restart() which can be
      used without turning the L2 cache controller off, and use it in both
      of these paths to keep the L2C enabled across the respective resume
      transitions.
      
      Fixes: 8ef418c7 ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
      Reported-by: NSean Cross <xobs@kosagi.com>
      Tested-by: NSean Cross <xobs@kosagi.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      767bf7e7
  17. 28 3月, 2015 1 次提交
    • N
      ARM: 8331/1: VDSO initialization, mapping, and synchronization · ecf99a43
      Nathan Lynch 提交于
      Initialize the VDSO page list at boot, install the VDSO mapping at
      exec time, and update the data page during timer ticks.  This code is
      not built if CONFIG_VDSO is not enabled.
      
      Account for the VDSO length when randomizing the offset from the
      stack.  The [vdso] and [vvar] pages are placed immediately following
      the sigpage with separate _install_special_mapping calls.
      
      We want to "penalize" systems lacking the arch timer as little
      as possible.  Previous versions of this code installed the VDSO
      unconditionally and unmodified, making it a measurably slower way for
      glibc to invoke the real syscalls on such systems.  E.g. calling
      gettimeofday via glibc goes from ~560ns to ~630ns on i.MX6Q.
      
      If we can indicate to glibc that the time-related APIs in the VDSO are
      not accelerated, glibc can continue to invoke the syscalls directly
      instead of dispatching through the VDSO only to fall back to the slow
      path.
      
      Thus, if the architected timer is unusable for whatever reason, patch
      the VDSO at boot time so that symbol lookups for gettimeofday and
      clock_gettime return NULL.  (This is similar to what powerpc does and
      borrows code from there.)  This allows glibc to perform the syscall
      directly instead of passing control to the VDSO, which minimizes the
      penalty.  In my measurements the time taken for a gettimeofday call
      via glibc goes from ~560ns to ~580ns (again on i.MX6Q), and this is
      solely due to adding a test and branch to glibc's gettimeofday syscall
      wrapper.
      
      An alternative to patching the VDSO at boot would be to not install
      the VDSO at all when the arch timer isn't usable.  Another alternative
      is to include a separate "dummy" vdso.so without gettimeofday and
      clock_gettime, which would be selected at boot time.  Either of these
      would get cumbersome if the VDSO were to gain support for an API such
      as getcpu which is unrelated to arch timer support.
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ecf99a43
  18. 04 12月, 2014 1 次提交
  19. 26 9月, 2014 4 次提交
  20. 18 9月, 2014 1 次提交
  21. 16 9月, 2014 1 次提交
  22. 08 4月, 2014 1 次提交
    • R
      ARM: add missing system_misc.h include to process.c · 779dd959
      Russell King 提交于
      arm_pm_restart(), arm_pm_idle() and soft_restart() are all declared in
      system_misc.h, but this file is not included in process.c.  Add this
      missing include.  Found via sparse:
      
      arch/arm/kernel/process.c:98:6: warning: symbol 'soft_restart' was not declared. Should it be static?
      arch/arm/kernel/process.c:127:6: warning: symbol 'arm_pm_restart' was not declared. Should it be static?
      arch/arm/kernel/process.c:134:6: warning: symbol 'arm_pm_idle' was not declared. Should it be static?
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      779dd959
  23. 07 4月, 2014 1 次提交
  24. 11 2月, 2014 1 次提交
  25. 04 2月, 2014 1 次提交
  26. 10 12月, 2013 1 次提交
  27. 07 8月, 2013 1 次提交
  28. 03 8月, 2013 1 次提交
    • R
      ARM: fix a cockup in 48be69a0 (ARM: move signal handlers into a vdso-like page) · e0d40756
      Russell King 提交于
      Unfortunately, I never committed the fix to a nasty oops which can
      occur as a result of that commit:
      
      ------------[ cut here ]------------
      kernel BUG at /home/olof/work/batch/include/linux/mm.h:414!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe03080 #53
      task: e90acac0 ti: e9be8000 task.ti: e9be8000
      PC is at special_mapping_fault+0xa4/0xc4
      LR is at __do_fault+0x68/0x48c
      
      This doesn't show up unless you do quite a bit of testing; a simple
      boot test does not do this, so all my nightly tests were passing fine.
      
      The reason for this is that install_special_mapping() expects the
      page array to stick around, and as this was only inserting one page
      which was stored on the kernel stack, that's why this was blowing up.
      Reported-by: NOlof Johansson <olof@lixom.net>
      Tested-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e0d40756
  29. 01 8月, 2013 3 次提交
  30. 10 7月, 2013 3 次提交