1. 08 Nov, 2019 12 commits
  2. 15 Jun, 2019 1 commit
    • Arnd Bergmann's avatar
      ARM: prevent tracing IPI_CPU_BACKTRACE · e0c3fc1f
      Arnd Bergmann authored
      [ Upstream commit be167862 ]
      Patch series "compiler: allow all arches to enable
      This patch (of 11):
      When function tracing for IPIs is enabled, we get a warning for an
      overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as
      triggered by raise_nmi():
        arch/arm/kernel/smp.c: In function 'raise_nmi':
        arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
          trace_ipi_raise(target, ipi_types[ipinr]);
      This is a correct warning as we actually overflow the array here.
      This patch raise_nmi() to call __smp_cross_call() instead of
      smp_cross_call(), to avoid calling into ftrace.  For clarification, I'm
      also adding a two new code comments describing how this one is special.
      The warning appears to have shown up after commit e7273ff4 ("ARM:
      8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the
      number assignment from '15' to '8', but as ...
  3. 31 May, 2019 1 commit
  4. 04 May, 2019 1 commit
    • Marc Zyngier's avatar
      KVM: arm/arm64: vgic-its: Take the srcu lock when writing to guest memory · 0371fa03
      Marc Zyngier authored
      [ Upstream commit a6ecfb11 ]
      When halting a guest, QEMU flushes the virtual ITS caches, which
      amounts to writing to the various tables that the guest has allocated.
      When doing this, we fail to take the srcu lock, and the kernel
      shouts loudly if running a lockdep kernel:
      [   69.680416] =============================
      [   69.680819] WARNING: suspicious RCU usage
      [   69.681526] 5.1.0-rc1-00008-g600025238f51-dirty #18 Not tainted
      [   69.682096] -----------------------------
      [   69.682501] ./include/linux/kvm_host.h:605 suspicious rcu_dereference_check() usage!
      [   69.683225]
      [   69.683225] other info that might help us debug this:
      [   69.683225]
      [   69.683975]
      [   69.683975] rcu_scheduler_active = 2, debug_locks = 1
      [   69.684598] 6 locks held by qemu-system-aar/4097:
      [   69.685059]  #0: 0000000034196013 (&kvm->lock){+.+.}, at: vgic_its_set_attr+0x244/0x3a0
      [   69.686087]  #1: 00000000f2ed935e (&its->its_lock){+.+.}, at: vgic_its_set_attr+0x250/0x3a0
      [   69.686919]  #2: 000000005e71ea54 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0
      [   69.687698]  #3: 00000000c17e548d (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0
      [   69.688475]  #4: 00000000ba386017 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0
      [   69.689978]  #5: 00000000c2c3c335 (&vcpu->mutex){+.+.}, at: lock_all_vcpus+0x64/0xd0
      [   69.690729]
      [   69.690729] stack backtrace:
      [   69.691151] CPU: 2 PID: 4097 Comm: qemu-system-aar Not tainted 5.1.0-rc1-00008-g600025238f51-dirty #18
      [   69.691984] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS 2019.04-rc3-00124-g2feec69fb1 03/15/2019
      [   69.692831] Call trace:
      [   69.694072]  lockdep_rcu_suspicious+0xcc/0x110
      [   69.694490]  gfn_to_memslot+0x174/0x190
      [   69.694853]  kvm_write_guest+0x50/0xb0
      [   69.695209]  vgic_its_save_tables_v0+0x248/0x330
      [   69.695639]  vgic_its_set_attr+0x298/0x3a0
      [   69.696024]  kvm_device_ioctl_attr+0x9c/0xd8
      [   69.696424]  kvm_device_ioctl+0x8c/0xf8
      [   69.696788]  do_vfs_ioctl+0xc8/0x960
      [   69.697128]  ksys_ioctl+0x8c/0xa0
      [   69.697445]  __arm64_sys_ioctl+0x28/0x38
      [   69.697817]  el0_svc_common+0xd8/0x138
      [   69.698173]  el0_svc_handler+0x38/0x78
      [   69.698528]  el0_svc+0x8/0xc
      The fix is to obviously take the srcu lock, just like we do on the
      read side of things since bf308242. One wonders why this wasn't
      fixed at the same time, but hey...
      Fixes: bf308242
       ("KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock")
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
  5. 05 Apr, 2019 2 commits
    • Russell King's avatar
      ARM: avoid Cortex-A9 livelock on tight dmb loops · 30d503ba
      Russell King authored
      [ Upstream commit 5388a5b8
      machine_crash_nonpanic_core() does this:
      	while (1)
      because the kernel has crashed, and we have no known safe way to deal
      with the CPU.  So, we place the CPU into an infinite loop which we
      expect it to never exit - at least not until the system as a whole is
      reset by some method.
      In the absence of erratum 754327, this code assembles to:
      	b	.
      In other words, an infinite loop.  When erratum 754327 is enabled,
      this becomes:
      1:	dmb
      	b	1b
      It has been observed that on some systems (eg, OMAP4) where, if a
      crash is triggered, the system tries to kexec into the panic kernel,
      but fails after taking the secondary CPU down - placing it into one
      of these loops.  This causes the system to livelock, and the most
      noticable effect is the system stops after issuing:
      	Loading crashdump kernel...
      to the system console.
      The tested as working solution I came up with was to add wfe() to
      these infinite loops thusly:
      	while (1) {
      which, without 754327 builds to:
      1:	wfe
      	b	1b
      or with 754327 is enabled:
      1:	dmb
      	b	1b
      Adding "wfe" does two things depending on the environment we're running
      - where we're running on bare metal, and the processor implements
        "wfe", it stops us spinning endlessly in a loop where we're never
        going to do any useful work.
      - if we're running in a VM, it allows the CPU to be given back to the
        hypervisor and rescheduled for other purposes (maybe a different VM)
        rather than wasting CPU cycles inside a crashed VM.
      However, in light of erratum 794072, Will Deacon wanted to see 10 nops
      as well - which is reasonable to cover the case where we have erratum
      754327 enabled _and_ we have a processor that doesn't implement the
      wfe hint.
      So, we now end up with:
      1:      wfe
              b       1b
      when erratum 754327 is disabled, or:
      1:      dmb
              b       1b
      when erratum 754327 is enabled.  We also get the dmb + 10 nop
      sequence elsewhere in the kernel, in terminating loops.
      This is reasonable - it means we get the workaround for erratum
      794072 when erratum 754327 is enabled, but still relinquish the dead
      processor - either by placing it in a lower power mode when wfe is
      implemented as such or by returning it to the hypervisior, or in the
      case where wfe is a no-op, we use the workaround specified in erratum
      794072 to avoid the problem.
      These as two entirely orthogonal problems - the 10 nops addresses
      erratum 794072, and the wfe is an optimisation that makes the system
      more efficient when crashed either in terms of power consumption or
      by allowing the host/other VMs to make use of the CPU.
      I don't see any reason not to use kexec() inside a VM - it has the
      potential to provide automated recovery from a failure of the VMs
      kernel with the opportunity for saving a crashdump of the failure.
      A panic() with a reboot timeout won't do that, and reading the
      libvirt documentation, setting on_reboot to "preserve" won't either
      (the documentation states "The preserve action for an on_reboot event
      is treated as a destroy".)  Surely it has to be a good thing to
      avoiding having CPUs spinning inside a VM that is doing no useful
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Vladimir Murzin's avatar
      ARM: 8830/1: NOMMU: Toggle only bits in EXC_RETURN we are really care of · d8945878
      Vladimir Murzin authored
      [ Upstream commit 72cd4064
      ARMv8M introduces support for Security extension to M class, among
      other things it affects exception handling, especially, encoding of
      The new bits have been added:
      Bit [6]	Secure or Non-secure stack
      Bit [5]	Default callee register stacking
      Bit [0]	Exception Secure
      which conflicts with hard-coded value of EXC_RETURN:
      In fact, we only care of few bits:
      Bit [3]	 Mode (0 - Handler, 1 - Thread)
      Bit [2]	 Stack pointer selection (0 - Main, 1 - Process)
      We can toggle only those bits and left other bits as they were on
      exception entry.
      It is basically, what patch does - saves EXC_RETURN when we do
      transition form Thread to Handler mode (it is first svc), so later
      saved value is used instead of EXC_RET_THREADMODE_PROCESSSTACK.
      Signed-off-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  6. 23 Mar, 2019 2 commits
  7. 20 Feb, 2019 8 commits
  8. 29 Dec, 2018 1 commit
  9. 07 Sep, 2018 1 commit
  10. 12 Aug, 2018 1 commit
  11. 03 Aug, 2018 1 commit
    • Palmer Dabbelt's avatar
      ARM: Convert to GENERIC_IRQ_MULTI_HANDLER · 4c301f9b
      Palmer Dabbelt authored
      Converts the ARM interrupt code to use the recently added
      GENERIC_IRQ_MULTI_HANDLER, which is essentially just a copy of ARM's
      existhing MULTI_IRQ_HANDLER.  The only changes are:
      * handle_arch_irq is now defined in a generic C file instead of an
        arm-specific assembly file.
      * handle_arch_irq is now marked as __ro_after_init.
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Link: https://lkml.kernel.org/r/20180622170126.6308-3-palmer@sifive.com
  12. 02 Aug, 2018 4 commits
    • Russell King's avatar
      ARM: spectre-v1: mitigate user accesses · a3c0f847
      Russell King authored
      Spectre variant 1 attacks are about this sequence of pseudo-code:
      	index = load(user-manipulated pointer);
      	access(base + index * stride);
      In order for the cache side-channel to work, the access() must me made
      to memory which userspace can detect whether cache lines have been
      loaded.  On 32-bit ARM, this must be either user accessible memory, or
      a kernel mapping of that same user accessible memory.
      The problem occurs when the load() speculatively loads privileged data,
      and the subsequent access() is made to user accessible memory.
      Any load() which makes use of a user-maniplated pointer is a potential
      problem if the data it has loaded is used in a subsequent access.  This
      also applies for the access() if the data loaded by that access is used
      by a subsequent access.
      Harden the get_user() accessors against Spectre attacks by forcing out
      of bounds addresses to a NULL pointer.  This prevents get_user() being
      used as the load() step above.  As a side effect, put_user() will also
      be affected even though it isn't implicated.
      Also harden copy_from_user() by redoing the bounds check within the
      arm_copy_from_user() code, and NULLing the pointer if out of bounds.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Russell King's avatar
      ARM: spectre-v1: use get_user() for __get_user() · b1cd0a14
      Russell King authored
      Fixing __get_user() for spectre variant 1 is not sane: we would have to
      add address space bounds checking in order to validate that the location
      should be accessed, and then zero the address if found to be invalid.
      Since __get_user() is supposed to avoid the bounds check, and this is
      exactly what get_user() does, there's no point having two different
      implementations that are doing the same thing.  So, when the Spectre
      workarounds are required, make __get_user() an alias of get_user().
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • Russell King's avatar
      ARM: use __inttype() in get_user() · d09fbb32
      Russell King authored
      Borrow the x86 implementation of __inttype() to use in get_user() to
      select an integer type suitable to temporarily hold the result value.
      This is necessary to avoid propagating the volatile nature of the
      result argument, which can cause the following warning:
      lib/iov_iter.c:413:5: warning: optimization may eliminate reads and/or writes to register variables [-Wvolatile-register-var]
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    • 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>
  13. 30 Jul, 2018 1 commit
  14. 25 Jul, 2018 1 commit
    • Anders Roxell's avatar
      arm/asm/tlb.h: Fix build error implicit func declaration · 063daa81
      Anders Roxell authored
      Building on arm 32 with LPAE enabled we don't include asm-generic/tlb.h,
      where we have tlb_flush_remove_tables_local and tlb_flush_remove_tables
      The build fails with:
        mm/memory.c: In function ‘tlb_remove_table_smp_sync’:
        mm/memory.c:339:2: error: implicit declaration of function ‘tlb_flush_remove_tables_local’; did you mean ‘tlb_remove_table’? [-Werror=implicit-function-declaration]
      This bug got introduced in:
       ("x86/mm/tlb: Leave lazy TLB mode at page table free time")
      To fix this issue we define them in arm 32's specific asm/tlb.h file as well.
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: dave.hansen@intel.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux@armlinux.org.uk
      Cc: riel@surriel.com
      Cc: songliubraving@fb.com
      Fixes: 2ff6ddf1 ("x86/mm/tlb: Leave lazy TLB mode at page table free time")
      Link: http://lkml.kernel.org/r/20180725095557.19668-1-anders.roxell@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  15. 22 Jul, 2018 1 commit
  16. 21 Jul, 2018 1 commit
  17. 19 Jul, 2018 1 commit
    • Pavel Tatashin's avatar
      ARM/time: Remove read_boot_clock64() · 227e3958
      Pavel Tatashin authored
      read_boot_clock64() is deleted, and replaced with
      The default implementation of read_persistent_wall_and_boot_offset()
      provides a better fallback than the current stubs for read_boot_clock64()
      that arm has with no users, so remove the old code.
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-19-pasha.tatashin@oracle.com