1. 09 Jul, 2016 1 commit
  2. 05 Jul, 2016 1 commit
  3. 28 Mar, 2016 1 commit
  4. 24 Mar, 2016 1 commit
  5. 13 Mar, 2016 1 commit
  6. 28 Feb, 2016 6 commits
  7. 06 May, 2015 1 commit
  8. 03 May, 2015 1 commit
  9. 22 Apr, 2015 1 commit
    • André Przywara's avatar
      KVM: arm/arm64: check IRQ number on userland injection · fd1d0ddf
      André Przywara authored
      
      
      When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently
      only check it against a fixed limit, which historically is set
      to 127. With the new dynamic IRQ allocation the effective limit may
      actually be smaller (64).
      So when now a malicious or buggy userland injects a SPI in that
      range, we spill over on our VGIC bitmaps and bytemaps memory.
      I could trigger a host kernel NULL pointer dereference with current
      mainline by injecting some bogus IRQ number from a hacked kvmtool:
      -----------------
      ....
      DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1)
      DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1)
      DEBUG: IRQ #114 still in the game, writing to bytemap now...
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = ffffffc07652e000
      [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000
      Internal error: Oops: 96000006 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027
      Hardware name: FVP Base (DT)
      task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000
      PC is at kvm_vgic_inject_irq+0x234/0x310
      LR is at kvm_vgic_inject_irq+0x30c/0x310
      pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145
      .....
      
      So this patch fixes this by checking the SPI number against the
      actual limit. Also we remove the former legacy hard limit of
      127 in the ioctl code.
      Signed-off-by: André Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18
      [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__,
      as suggested by Christopher Covington]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      fd1d0ddf
  10. 17 Apr, 2015 1 commit
  11. 14 Apr, 2015 2 commits
    • Kees Cook's avatar
      mm: fold arch_randomize_brk into ARCH_HAS_ELF_RANDOMIZE · 204db6ed
      Kees Cook authored
      
      
      The arch_randomize_brk() function is used on several architectures,
      even those that don't support ET_DYN ASLR. To avoid bulky extern/#define
      tricks, consolidate the support under CONFIG_ARCH_HAS_ELF_RANDOMIZE for
      the architectures that support it, while still handling CONFIG_COMPAT_BRK.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      204db6ed
    • Russell King's avatar
      ARM: allow 16-bit instructions in ALT_UP() · 89c6bc58
      Russell King authored
      
      
      Allow ALT_UP() to cope with a 16-bit Thumb instruction by automatically
      inserting a following nop instruction.  This allows us to care less
      about getting the assembler to emit a 32-bit thumb instruction.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      89c6bc58
  12. 12 Apr, 2015 1 commit
  13. 10 Apr, 2015 1 commit
  14. 09 Apr, 2015 1 commit
    • Anton Blanchard's avatar
      jump_label: Allow asm/jump_label.h to be included in assembly · 55dd0df7
      Anton Blanchard authored
      
      
      Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
      Since these are kernel only headers, we don't need #ifdef
      __KERNEL__ so can simplify things a bit.
      
      If an architecture wants to use jump labels in assembly, it
      will still need to define a macro to create the __jump_table
      entries (see ARCH_STATIC_BRANCH in the powerpc asm/jump_label.h
      for an example).
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: benh@kernel.crashing.org
      Cc: catalin.marinas@arm.com
      Cc: davem@davemloft.net
      Cc: heiko.carstens@de.ibm.com
      Cc: jbaron@akamai.com
      Cc: linux@arm.linux.org.uk
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: liuj97@gmail.com
      Cc: mgorman@suse.de
      Cc: mmarek@suse.cz
      Cc: mpe@ellerman.id.au
      Cc: paulus@samba.org
      Cc: ralf@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: schwidefsky@de.ibm.com
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1428551492-21977-1-git-send-email-anton@samba.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      55dd0df7
  15. 03 Apr, 2015 2 commits
  16. 02 Apr, 2015 1 commit
    • Geert Uytterhoeven's avatar
      ARM: 8338/1: kexec: Relax SMP validation to improve DT compatibility · fee3fd4f
      Geert Uytterhoeven authored
      When trying to kexec into a new kernel on a platform where multiple CPU
      cores are present, but no SMP bringup code is available yet, the
      kexec_load system call fails with:
      
          kexec_load failed: Invalid argument
      
      The SMP test added to machine_kexec_prepare() in commit 2103f6cb
      
      
      ("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
      kexec on SMP platforms where it cannot disable secondary CPUs.
      However, this test is too strict: if the secondary CPUs couldn't be
      enabled in the first place, there's no need to disable them later at
      kexec time.  Hence skip the test in the absence of SMP bringup code.
      
      This allows to add all CPU cores to the DTS from the beginning, without
      having to implement SMP bringup first, improving DT compatibility.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fee3fd4f
  17. 30 Mar, 2015 1 commit
    • André Przywara's avatar
      KVM: arm/arm64: rework MMIO abort handling to use KVM MMIO bus · 950324ab
      André Przywara authored
      
      
      Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
      data to be passed on from syndrome decoding all the way down to the
      VGIC register handlers. Now as we switch the MMIO handling to be
      routed through the KVM MMIO bus, it does not make sense anymore to
      use that structure already from the beginning. So we keep the data in
      local variables until we put them into the kvm_io_bus framework.
      Then we fill kvm_exit_mmio in the VGIC only, making it a VGIC private
      structure. On that way we replace the data buffer in that structure
      with a pointer pointing to a single location in a local variable, so
      we get rid of some copying on the way.
      With all of the virtual GIC emulation code now being registered with
      the kvm_io_bus, we can remove all of the old MMIO handling code and
      its dispatching functionality.
      
      I didn't bother to rename kvm_exit_mmio (to vgic_mmio or something),
      because that touches a lot of code lines without any good reason.
      
      This is based on an original patch by Nikolay.
      Signed-off-by: André Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Cc: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      950324ab
  18. 29 Mar, 2015 1 commit
  19. 28 Mar, 2015 3 commits
  20. 27 Mar, 2015 3 commits
    • Nathan Lynch's avatar
      ARM: 8329/1: miscellaneous vdso infrastructure, preparation · 1713ce7c
      Nathan Lynch authored
      
      
      Define the layout of the data structure shared between kernel and
      userspace.
      
      Track the vdso address in the mm_context; needed for communicating
      AT_SYSINFO_EHDR to the ELF loader.
      
      Add declarations for arm_install_vdso; implementation is in a
      following patch.
      
      Define AT_SYSINFO_EHDR, and, if CONFIG_VDSO=y, report the vdso shared
      object address via the ELF auxiliary vector.
      
      Note - this adds the AT_SYSINFO_EHDR in a new user-visible header
      asm/auxvec.h; this is consistent with other architectures.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      1713ce7c
    • Stephen Boyd's avatar
      ARM: Remove mach-msm and associated ARM architecture code · c0c89faf
      Stephen Boyd authored
      The maintainers for mach-msm no longer have any plans to support
      or test the platforms supported by this architecture[1]. Most likely
      there aren't any active users of this code anyway, so let's
      delete it.
      
      [1] http://lkml.kernel.org/r/20150307031212.GA8434@fifo99.com
      
      
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarKumar Gala <galak@codeaurora.org>
      c0c89faf
    • Suzuki K. Poulose's avatar
      arm-cci: Get rid of secure transactions for PMU driver · 772742a6
      Suzuki K. Poulose authored
      
      
      Avoid secure transactions while probing the CCI PMU. The
      existing code makes use of the Peripheral ID2 (PID2) register
      to determine the revision of the CCI400, which requires a
      secure transaction. This puts a limitation on the usage of the
      driver on systems running non-secure Linux(e.g, ARM64).
      
      Updated the device-tree binding for cci pmu node to add the explicit
      revision number for the compatible field.
      
      The supported strings are :
      	arm,cci-400-pmu,r0
      	arm,cci-400-pmu,r1
      	arm,cci-400-pmu - DEPRECATED. See NOTE below
      
      NOTE: If the revision is not mentioned, we need to probe the cci revision,
      which could be fatal on a platform running non-secure. We need a reliable way
      to know if we can poke the CCI registers at runtime on ARM32. We depend on
      'mcpm_is_available()' when it is available. mcpm_is_available() returns true
      only when there is a registered driver for mcpm. Otherwise, we assume that we
      don't have secure access, and skips probing the revision number(ARM64 case).
      
      The MCPM should figure out if it is safe to access the CCI. Unfortunately
      there isn't a reliable way to indicate the same via dtb. This patch doesn't
      address/change the current situation. It only deals with the CCI-PMU, leaving
      the assumptions about the secure access as it has been, prior to this patch.
      
      Cc: devicetree@vger.kernel.org
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Tested-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      772742a6
  21. 24 Mar, 2015 2 commits
    • Will Deacon's avatar
      ARM: pmu: add support for interrupt-affinity property · 9fd85eb5
      Will Deacon authored
      
      
      Historically, the PMU devicetree bindings have expected SPIs to be
      listed in order of *logical* CPU number. This is problematic for
      bootloaders, especially when the boot CPU (logical ID 0) isn't listed
      first in the devicetree.
      
      This patch adds a new optional property, interrupt-affinity, to the
      PMU node which allows the interrupt affinity to be described using
      a list of phandled to CPU nodes, with each entry in the list
      corresponding to the SPI at the same index in the interrupts property.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      9fd85eb5
    • Daniel Lezcano's avatar
      ARM: cpuidle: Add a cpuidle ops structure to be used for DT · 449e056c
      Daniel Lezcano authored
      
      
      The current state of the different cpuidle drivers is the different PM
      operations are passed via the platform_data using the platform driver
      paradigm.
      
      This approach allowed to split the low level PM code from the arch specific
      and the generic cpuidle code.
      
      Unfortunately there are complaints about this approach as, in the context of the
      single kernel image, we have multiple drivers loaded in memory for nothing and
      the platform driver is not adequate for cpuidle.
      
      This patch provides a common interface via cpuidle ops for all new cpuidle
      driver and a definition for the device tree.
      
      It will allow with the next patches to a have a common definition with ARM64
      and share the same cpuidle driver.
      
      The code is optimized to use the __init section intensively in order to reduce
      the memory footprint after the driver is initialized and unify the function
      names with ARM64.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: default avatarKevin Hilman <khilman@linaro.org>
      Acked-by: default avatarRob Herring <robherring2@gmail.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      449e056c
  22. 23 Mar, 2015 2 commits
  23. 12 Mar, 2015 3 commits
  24. 11 Mar, 2015 2 commits
    • Marc Zyngier's avatar
      arm64: KVM: Do not use pgd_index to index stage-2 pgd · 04b8dc85
      Marc Zyngier authored
      
      
      The kernel's pgd_index macro is designed to index a normal, page
      sized array. KVM is a bit diffferent, as we can use concatenated
      pages to have a bigger address space (for example 40bit IPA with
      4kB pages gives us an 8kB PGD.
      
      In the above case, the use of pgd_index will always return an index
      inside the first 4kB, which makes a guest that has memory above
      0x8000000000 rather unhappy, as it spins forever in a page fault,
      whist the host happilly corrupts the lower pgd.
      
      The obvious fix is to get our own kvm_pgd_index that does the right
      thing(tm).
      
      Tested on X-Gene with a hacked kvmtool that put memory at a stupidly
      high address.
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      04b8dc85
    • Marc Zyngier's avatar
      arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting · a987370f
      Marc Zyngier authored
      
      
      We're using __get_free_pages with to allocate the guest's stage-2
      PGD. The standard behaviour of this function is to return a set of
      pages where only the head page has a valid refcount.
      
      This behaviour gets us into trouble when we're trying to increment
      the refcount on a non-head page:
      
      page:ffff7c00cfb693c0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x4000000000000000()
      page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0)
      BUG: failure at include/linux/mm.h:548/get_page()!
      Kernel panic - not syncing: BUG!
      CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825
      Hardware name: APM X-Gene Mustang board (DT)
      Call trace:
      [<ffff80000008a09c>] dump_backtrace+0x0/0x13c
      [<ffff80000008a1e8>] show_stack+0x10/0x1c
      [<ffff800000691da8>] dump_stack+0x74/0x94
      [<ffff800000690d78>] panic+0x100/0x240
      [<ffff8000000a0bc4>] stage2_get_pmd+0x17c/0x2bc
      [<ffff8000000a1dc4>] kvm_handle_guest_abort+0x4b4/0x6b0
      [<ffff8000000a420c>] handle_exit+0x58/0x180
      [<ffff80000009e7a4>] kvm_arch_vcpu_ioctl_run+0x114/0x45c
      [<ffff800000099df4>] kvm_vcpu_ioctl+0x2e0/0x754
      [<ffff8000001c0a18>] do_vfs_ioctl+0x424/0x5c8
      [<ffff8000001c0bfc>] SyS_ioctl+0x40/0x78
      CPU0: stopping
      
      A possible approach for this is to split the compound page using
      split_page() at allocation time, and change the teardown path to
      free one page at a time.  It turns out that alloc_pages_exact() and
      free_pages_exact() does exactly that.
      
      While we're at it, the PGD allocation code is reworked to reduce
      duplication.
      
      This has been tested on an X-Gene platform with a 4kB/48bit-VA host
      kernel, and kvmtool hacked to place memory in the second page of
      the hardware PGD (PUD for the host kernel). Also regression-tested
      on a Cubietruck (Cortex-A7).
      
       [ Reworked to use alloc_pages_exact() and free_pages_exact() and to
         return pointers directly instead of by reference as arguments
          - Christoffer ]
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      a987370f