1. 20 3月, 2015 3 次提交
  2. 19 3月, 2015 1 次提交
  3. 18 3月, 2015 3 次提交
    • M
      arm64: log CPU boot modes · 667f3fd3
      Mark Rutland 提交于
      We currently don't log the boot mode for arm64 as we do for arm, and
      without KVM the user is provided with no indication as to which mode(s)
      CPUs were booted in, which can seriously hinder debugging in some cases.
      
      Add logging to the boot path once all CPUs are up. Where CPUs are
      mismatched in violation of the boot protocol, WARN and set a taint (as
      we do for CPU other CPU feature mismatches) given that the
      firmware/bootloader is buggy and should be fixed.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      667f3fd3
    • M
      arm64: fix hyp mode mismatch detection · 424a3838
      Mark Rutland 提交于
      Commit 828e9834 ("arm64: head: create a new function for setting
      the boot_cpu_mode flag") added BOOT_CPU_MODE_EL1, a nonzero value
      replacing uses of zero. However it failed to update __boot_cpu_mode
      appropriately.
      
      A CPU booted at EL2 writes BOOT_CPU_MODE_EL2 to __boot_cpu_mode[0], and
      a CPU booted at EL1 writes BOOT_CPU_MODE_EL1 to __boot_cpu_mode[1].
      Later is_hyp_mode_mismatched() determines there to be a mismatch if
      __boot_cpu_mode[0] != __boot_cpu_mode[1].
      
      If all CPUs are booted at EL1, __boot_cpu_mode[0] will be set to
      BOOT_CPU_MODE_EL1, but __boot_cpu_mode[1] will retain its initial value
      of zero, and is_hyp_mode_mismatched will erroneously determine that the
      boot modes are mismatched. This hasn't been a problem so far, but later
      patches which will make use of is_hyp_mode_mismatched() expect it to
      work correctly.
      
      This patch initialises __boot_cpu_mode[1] to BOOT_CPU_MODE_EL1, fixing
      the erroneous mismatch detection when all CPUs are booted at EL1.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      424a3838
    • M
      arm64: apply alternatives for !SMP kernels · 137650aa
      Mark Rutland 提交于
      Currently we only perform alternative patching for kernels built with
      CONFIG_SMP, as we call apply_alternatives_all() in smp.c, which is only
      built for CONFIG_SMP. Thus !SMP kernels may not have necessary
      alternatives patched in.
      
      This patch ensures that we call apply_alternatives_all() once all CPUs
      are booted, even for !SMP kernels, by having the smp_init_cpus() stub
      call this for !SMP kernels via up_late_init. A new wrapper,
      do_post_cpus_up_work, is added so we can hook other calls here later
      (e.g. boot mode logging).
      
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Fixes: e039ee4e ("arm64: add alternative runtime patching")
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      137650aa
  4. 14 3月, 2015 2 次提交
  5. 28 2月, 2015 1 次提交
  6. 27 2月, 2015 3 次提交
    • M
      arm64: Fix text patching logic when using fixmap · f6242cac
      Marc Zyngier 提交于
      Patch 2f896d58 ("arm64: use fixmap for text patching") changed
      the way we patch the kernel text, using a fixmap when the kernel or
      modules are flagged as read only.
      
      Unfortunately, a flaw in the logic makes it fall over when patching
      modules without CONFIG_DEBUG_SET_MODULE_RONX enabled:
      
      [...]
      [   32.032636] Call trace:
      [   32.032716] [<fffffe00003da0dc>] __copy_to_user+0x2c/0x60
      [   32.032837] [<fffffe0000099f08>] __aarch64_insn_write+0x94/0xf8
      [   32.033027] [<fffffe000009a0a0>] aarch64_insn_patch_text_nosync+0x18/0x58
      [   32.033200] [<fffffe000009c3ec>] ftrace_modify_code+0x58/0x84
      [   32.033363] [<fffffe000009c4e4>] ftrace_make_nop+0x3c/0x58
      [   32.033532] [<fffffe0000164420>] ftrace_process_locs+0x3d0/0x5c8
      [   32.033709] [<fffffe00001661cc>] ftrace_module_init+0x28/0x34
      [   32.033882] [<fffffe0000135148>] load_module+0xbb8/0xfc4
      [   32.034044] [<fffffe0000135714>] SyS_finit_module+0x94/0xc4
      [...]
      
      This is triggered by the use of virt_to_page() on a module address,
      which ends to pointing to Nowhereland if you're lucky, or corrupt
      your precious data if not.
      
      This patch fixes the logic by mimicking what is done on arm:
      - If we're patching a module and CONFIG_DEBUG_SET_MODULE_RONX is set,
        use vmalloc_to_page().
      - If we're patching the kernel and CONFIG_DEBUG_RODATA is set,
        use virt_to_page().
      - Otherwise, use the provided address, as we can write to it directly.
      
      Tested on 4.0-rc1 as a KVM guest.
      Reported-by: NRichard W.M. Jones <rjones@redhat.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NLaura Abbott <lauraa@codeaurora.org>
      Tested-by: NRichard W.M. Jones <rjones@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f6242cac
    • W
      arm64: psci: move psci firmware calls out of line · f5e0a12c
      Will Deacon 提交于
      An arm64 allmodconfig fails to build with GCC 5 due to __asmeq
      assertions in the PSCI firmware calling code firing due to mcount
      preambles breaking our assumptions about register allocation of function
      arguments:
      
        /tmp/ccDqJsJ6.s: Assembler messages:
        /tmp/ccDqJsJ6.s:60: Error: .err encountered
        /tmp/ccDqJsJ6.s:61: Error: .err encountered
        /tmp/ccDqJsJ6.s:62: Error: .err encountered
        /tmp/ccDqJsJ6.s:99: Error: .err encountered
        /tmp/ccDqJsJ6.s:100: Error: .err encountered
        /tmp/ccDqJsJ6.s:101: Error: .err encountered
      
      This patch fixes the issue by moving the PSCI calls out-of-line into
      their own assembly files, which are safe from the compiler's meddling
      fingers.
      Reported-by: NAndy Whitcroft <apw@canonical.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f5e0a12c
    • N
      arm64: vdso: minor ABI fix for clock_getres · e1b6b6ce
      Nathan Lynch 提交于
      The vdso implementation of clock_getres currently returns 0 (success)
      whenever a null timespec is provided by the caller, regardless of the
      clock id supplied.
      
      This behavior is incorrect.  It should fall back to syscall when an
      unrecognized clock id is passed, even when the timespec argument is
      null.  This ensures that clock_getres always returns an error for
      invalid clock ids.
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      e1b6b6ce
  7. 23 2月, 2015 1 次提交
  8. 14 2月, 2015 1 次提交
    • A
      mm: vmalloc: pass additional vm_flags to __vmalloc_node_range() · cb9e3c29
      Andrey Ryabinin 提交于
      For instrumenting global variables KASan will shadow memory backing memory
      for modules.  So on module loading we will need to allocate memory for
      shadow and map it at address in shadow that corresponds to the address
      allocated in module_alloc().
      
      __vmalloc_node_range() could be used for this purpose, except it puts a
      guard hole after allocated area.  Guard hole in shadow memory should be a
      problem because at some future point we might need to have a shadow memory
      at address occupied by guard hole.  So we could fail to allocate shadow
      for module_alloc().
      
      Now we have VM_NO_GUARD flag disabling guard page, so we need to pass into
      __vmalloc_node_range().  Add new parameter 'vm_flags' to
      __vmalloc_node_range() function.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb9e3c29
  9. 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
  10. 27 1月, 2015 4 次提交
    • L
      arm64: kernel: remove ARM64_CPU_SUSPEND config option · af3cfdbf
      Lorenzo Pieralisi 提交于
      ARM64_CPU_SUSPEND config option was introduced to make code providing
      context save/restore selectable only on platforms requiring power
      management capabilities.
      
      Currently ARM64_CPU_SUSPEND depends on the PM_SLEEP config option which
      in turn is set by the SUSPEND config option.
      
      The introduction of CPU_IDLE for arm64 requires that code configured
      by ARM64_CPU_SUSPEND (context save/restore) should be compiled in
      in order to enable the CPU idle driver to rely on CPU operations
      carrying out context save/restore.
      
      The ARM64_CPUIDLE config option (ARM64 generic idle driver) is therefore
      forced to select ARM64_CPU_SUSPEND, even if there may be (ie PM_SLEEP)
      failed dependencies, which is not a clean way of handling the kernel
      configuration option.
      
      For these reasons, this patch removes the ARM64_CPU_SUSPEND config option
      and makes the context save/restore dependent on CPU_PM, which is selected
      whenever either SUSPEND or CPU_IDLE are configured, cleaning up dependencies
      in the process.
      
      This way, code previously configured through ARM64_CPU_SUSPEND is
      compiled in whenever a power management subsystem requires it to be
      present in the kernel (SUSPEND || CPU_IDLE), which is the behaviour
      expected on ARM64 kernels.
      
      The cpu_suspend and cpu_init_idle CPU operations are added only if
      CPU_IDLE is selected, since they are CPU_IDLE specific methods and
      should be grouped and defined accordingly.
      
      PSCI CPU operations are updated to reflect the introduced changes.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      af3cfdbf
    • M
      arm64: make sys_call_table const · c623b33b
      Mark Rutland 提交于
      As with x86, mark the sys_call_table const such that it will be placed
      in the .rodata section. This will cause attempts to modify the table
      (accidental or deliberate) to fail when strict page permissions are in
      place. In the absence of strict page permissions, there should be no
      functional change.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      c623b33b
    • C
      arm64: Remove asm/syscalls.h · 96486069
      Catalin Marinas 提交于
      This patch moves the sys_rt_sigreturn_wrapper prototype to
      arch/arm64/kernel/sys.c and removes the asm/syscalls.h header.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      96486069
    • C
      arm64: Implement the compat_sys_call_table in C · 0156411b
      Catalin Marinas 提交于
      Unlike the sys_call_table[], the compat one was implemented in sys32.S
      making it impossible to notice discrepancies between the number of
      compat syscalls and the __NR_compat_syscalls macro, the latter having to
      be defined in asm/unistd.h as including asm/unistd32.h would cause
      conflicts on __NR_* definitions. With this patch, incorrect
      __NR_compat_syscalls values will result in a build-time error.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Suggested-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      0156411b
  11. 24 1月, 2015 5 次提交
  12. 22 1月, 2015 3 次提交
  13. 21 1月, 2015 1 次提交
  14. 17 1月, 2015 2 次提交
  15. 16 1月, 2015 1 次提交
    • A
      arm64/efi: efistub: Apply __init annotation · ddeeefe2
      Ard Biesheuvel 提交于
      This ensures all stub component are freed when the kernel proper is
      done booting, by prefixing the names of all ELF sections that have
      the SHF_ALLOC attribute with ".init". This approach ensures that even
      implicitly emitted allocated data (like initializer values and string
      literals) are covered.
      
      At the same time, remove some __init annotations in the stub that have
      now become redundant, and add the __init annotation to handle_kernel_image
      which will now trigger a section mismatch warning without it.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      ddeeefe2
  16. 15 1月, 2015 3 次提交
  17. 13 1月, 2015 3 次提交
  18. 09 1月, 2015 1 次提交
  19. 08 1月, 2015 1 次提交
    • A
      arm64/efi: add missing call to early_ioremap_reset() · 0e63ea48
      Ard Biesheuvel 提交于
      The early ioremap support introduced by patch bf4b558e
      ("arm64: add early_ioremap support") failed to add a call to
      early_ioremap_reset() at an appropriate time. Without this call,
      invocations of early_ioremap etc. that are done too late will go
      unnoticed and may cause corruption.
      
      This is exactly what happened when the first user of this feature
      was added in patch f84d0275 ("arm64: add EFI runtime services").
      The early mapping of the EFI memory map is unmapped during an early
      initcall, at which time the early ioremap support is long gone.
      
      Fix by adding the missing call to early_ioremap_reset() to
      setup_arch(), and move the offending early_memunmap() to right after
      the point where the early mapping of the EFI memory map is last used.
      
      Fixes: f84d0275 ("arm64: add EFI runtime services")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0e63ea48