1. 15 Jun, 2017 3 commits
  2. 12 Jun, 2017 9 commits
  3. 07 Jun, 2017 2 commits
    • Ard Biesheuvel's avatar
      arm64: ftrace: add support for far branches to dynamic ftrace · e71a4e1b
      Ard Biesheuvel authored
      Currently, dynamic ftrace support in the arm64 kernel assumes that all
      core kernel code is within range of ordinary branch instructions that
      occur in module code, which is usually the case, but is no longer
      guaranteed now that we have support for module PLTs and address space
      randomization.
      
      Since on arm64, all patching of branch instructions involves function
      calls to the same entry point [ftrace_caller()], we can emit the modules
      with a trampoline that has unlimited range, and patch both the trampoline
      itself and the branch instruction to redirect the call via the trampoline.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: minor clarification to smp_wmb() comment]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e71a4e1b
    • Ard Biesheuvel's avatar
      arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() · f8af0b36
      Ard Biesheuvel authored
      When turning branch instructions into NOPs, we attempt to validate the
      action by comparing the old value at the call site with the opcode of
      a direct relative branch instruction pointing at the old target.
      
      However, these call sites are statically initialized to call _mcount(),
      and may be redirected via a PLT entry if the module is loaded far away
      from the kernel text, leading to false negatives and spurious errors.
      
      So skip the validation if CONFIG_ARM64_MODULE_PLTS is configured.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f8af0b36
  4. 06 Jun, 2017 1 commit
  5. 05 Jun, 2017 1 commit
  6. 01 Jun, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: kernel: restrict /dev/mem read() calls to linear region · 1151f838
      Ard Biesheuvel authored
      When running lscpu on an AArch64 system that has SMBIOS version 2.0
      tables, it will segfault in the following way:
      
        Unable to handle kernel paging request at virtual address ffff8000bfff0000
        pgd = ffff8000f9615000
        [ffff8000bfff0000] *pgd=0000000000000000
        Internal error: Oops: 96000007 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
        Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
        task: ffff8000fa78e800 task.stack: ffff8000f9780000
        PC is at __arch_copy_to_user+0x90/0x220
        LR is at read_mem+0xcc/0x140
      
      This is caused by the fact that lspci issues a read() on /dev/mem at the
      offset where it expects to find the SMBIOS structure array. However, this
      region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
      and so it is omitted from the linear mapping.
      
      So let's restrict /dev/mem read/write access to those areas that are
      covered by the linear region.
      Reported-by: default avatarAlexander Graf <agraf@suse.de>
      Fixes: 4dffbfc4 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1151f838
  7. 30 May, 2017 8 commits
    • Lorenzo Pieralisi's avatar
      ARM64/PCI: Set root bus NUMA node on ACPI systems · db46a72b
      Lorenzo Pieralisi authored
      PCI core requires the NUMA node for the struct pci_host_bridge.dev to
      be set by using the pcibus_to_node(struct pci_bus*) API, that on ARM64
      systems relies on the struct pci_host_bridge->bus.dev NUMA node.
      
      The struct pci_host_bridge.dev NUMA node is then propagated through
      the PCI device hierarchy as PCI devices (and bridges) are enumerated
      under it.
      
      Therefore, in order to set-up the PCI NUMA hierarchy appropriately, the
      struct pci_host_bridge->bus.dev NUMA node must be set before core
      code calls pcibus_to_node(struct pci_bus*) on it so that PCI core can
      retrieve the NUMA node for the struct pci_host_bridge.dev device and can
      propagate it through the PCI bus tree.
      
      On ARM64 ACPI based systems the struct pci_host_bridge->bus.dev NUMA
      node can be set-up in pcibios_root_bridge_prepare() by parsing the root
      bridge ACPI device firmware binding.
      
      Add code to the pcibios_root_bridge_prepare() that, when booting with
      ACPI, parse the root bridge ACPI device companion NUMA binding and set
      the corresponding struct pci_host_bridge->bus.dev NUMA node
      appropriately.
      
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarRobert Richter <rrichter@cavium.com>
      Tested-by: default avatarRobert Richter <rrichter@cavium.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      db46a72b
    • Will Deacon's avatar
      arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage · 5f16a046
      Will Deacon authored
      FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg
      field as a shift value, potentially leading to a left shift value that
      is negative or with an absolute value that is significantly larger then
      the size of the type. UBSAN chokes with:
      
      ================================================================================
      UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13
      shift exponent -1 is negative
      CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11
      Hardware name: linux,dummy-virt (DT)
      Call trace:
      [<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73
      [<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
      [<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline]
      [<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52
      [<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164
      [<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421
      [<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline]
      [<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline]
      [<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231
      [<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline]
      [<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249
      [<ffff200008084770>] el0_svc_naked+0x24/0x28
      ================================================================================
      syz-executor1 uses obsolete (PF_INET,SOCK_PACKET)
      sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT
      
      This patch attempts to fix some of this by:
      
        * Making encoded_op an unsigned type, so we can shift it left even if
          the top bit is set.
      
        * Casting to signed prior to shifting right when extracting oparg
          and cmparg
      
        * Consider only the bottom 5 bits of oparg when using it as a left-shift
          value.
      
      Whilst I think this catches all of the issues, I'd much prefer to remove
      this stuff, as I think it's unused and the bugs are copy-pasted between
      a bunch of architectures.
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5f16a046
    • Kefeng Wang's avatar
      arm64: check return value of of_flat_dt_get_machine_name · 690e95dd
      Kefeng Wang authored
      It's useless to print machine name and setup arch-specific system
      identifiers if of_flat_dt_get_machine_name() return NULL, especially
      when ACPI-based boot.
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      690e95dd
    • Will Deacon's avatar
      arm64: cpufeature: Don't dump useless backtrace on CPU_OUT_OF_SPEC · 3fde2999
      Will Deacon authored
      Unfortunately, it turns out that mismatched CPU features in big.LITTLE
      systems are starting to appear in the wild. Whilst we should continue to
      taint the kernel with CPU_OUT_OF_SPEC for features that differ in ways
      that we can't fix up, dumping a useless backtrace out of the cpufeature
      code is pointless and irritating.
      
      This patch removes the backtrace from the taint.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      3fde2999
    • Tobias Klauser's avatar
      arm64: mm: explicity include linux/vmalloc.h · 6efd8499
      Tobias Klauser authored
      arm64's mm/mmu.c uses vm_area_add_early, struct vm_area and other
      definitions  but relies on implict inclusion of linux/vmalloc.h which
      means that changes in other headers could break the build. Thus, add an
      explicit include.
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6efd8499
    • Kefeng Wang's avatar
      arm64: Add dump_backtrace() in show_regs · 1149aad1
      Kefeng Wang authored
      Generic code expects show_regs() to dump the stack, but arm64's
      show_regs() does not. This makes it hard to debug softlockups and
      other issues that result in show_regs() being called.
      
      This patch updates arm64's show_regs() to dump the stack, as common
      code expects.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      [will: folded in bug_handler fix from mrutland]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1149aad1
    • Kefeng Wang's avatar
      arm64: Call __show_regs directly · c07ab957
      Kefeng Wang authored
      Generic code expects show_regs() to also dump the stack, but arm64's
      show_reg() does not do this. Some arm64 callers of show_regs() *only*
      want the registers dumped, without the stack.
      
      To enable generic code to work as expected, we need to make
      show_regs() dump the stack. Where we only want the registers dumped,
      we must use __show_regs().
      
      This patch updates code to use __show_regs() where only registers are
      desired. A subsequent patch will modify show_regs().
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c07ab957
    • Dong Bo's avatar
      arm64: Preventing READ_IMPLIES_EXEC propagation · 48f99c8e
      Dong Bo authored
      Like arch/arm/, we inherit the READ_IMPLIES_EXEC personality flag across
      fork(). This is undesirable for a number of reasons:
      
        * ELF files that don't require executable stack can end up with it
          anyway
      
        * We end up performing un-necessary I-cache maintenance when mapping
          what should be non-executable pages
      
        * Restricting what is executable is generally desirable when defending
          against overflow attacks
      
      This patch clears the personality flag when setting up the personality for
      newly spwaned native tasks. Given that semi-recent AArch64 toolchains emit
      a non-executable PT_GNU_STACK header, userspace applications can already
      not rely on READ_IMPLIES_EXEC so shouldn't be adversely affected by this
      change.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarDong Bo <dongbo4@huawei.com>
      [will: added comment to compat code, rewrote commit message]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      48f99c8e
  8. 29 May, 2017 1 commit
  9. 28 May, 2017 1 commit
  10. 27 May, 2017 13 commits