1. 22 8月, 2016 7 次提交
  2. 18 8月, 2016 1 次提交
  3. 13 8月, 2016 3 次提交
    • M
      arm64: hibernate: handle allocation failures · dfbca61a
      Mark Rutland 提交于
      In create_safe_exec_page(), we create a copy of the hibernate exit text,
      along with some page tables to map this via TTBR0. We then install the
      new tables in TTBR0.
      
      In swsusp_arch_resume() we call create_safe_exec_page() before trying a
      number of operations which may fail (e.g. copying the linear map page
      tables). If these fail, we bail out of swsusp_arch_resume() and return
      an error code, but leave TTBR0 as-is. Subsequently, the core hibernate
      code will call free_basic_memory_bitmaps(), which will free all of the
      memory allocations we made, including the page tables installed in
      TTBR0.
      
      Thus, we may have TTBR0 pointing at dangling freed memory for some
      period of time. If the hibernate attempt was triggered by a user
      requesting a hibernate test via the reboot syscall, we may return to
      userspace with the clobbered TTBR0 value.
      
      Avoid these issues by reorganising swsusp_arch_resume() such that we
      have no failure paths after create_safe_exec_page(). We also add a check
      that the zero page allocation succeeded, matching what we have for other
      allocations.
      
      Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJames Morse <james.morse@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org> # 4.7+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      dfbca61a
    • M
      arm64: hibernate: avoid potential TLB conflict · 0194e760
      Mark Rutland 提交于
      In create_safe_exec_page we install a set of global mappings in TTBR0,
      then subsequently invalidate TLBs. While TTBR0 points at the zero page,
      and the TLBs should be free of stale global entries, we may have stale
      ASID-tagged entries (e.g. from the EFI runtime services mappings) for
      the same VAs. Per the ARM ARM these ASID-tagged entries may conflict
      with newly-allocated global entries, and we must follow a
      Break-Before-Make approach to avoid issues resulting from this.
      
      This patch reworks create_safe_exec_page to invalidate TLBs while the
      zero page is still in place, ensuring that there are no potential
      conflicts when the new TTBR0 value is installed. As a single CPU is
      online while this code executes, we do not need to perform broadcast TLB
      maintenance, and can call local_flush_tlb_all(), which also subsumes
      some barriers. The remaining assembly is converted to use write_sysreg()
      and isb().
      
      Other than this, we safely manipulate TTBRs in the hibernate dance. The
      code we install as part of the new TTBR0 mapping (the hibernated
      kernel's swsusp_arch_suspend_exit) installs a zero page into TTBR1,
      invalidates TLBs, then installs its preferred value. Upon being restored
      to the middle of swsusp_arch_suspend, the new image will call
      __cpu_suspend_exit, which will call cpu_uninstall_idmap, installing the
      zero page in TTBR0 and invalidating all TLB entries.
      
      Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJames Morse <james.morse@arm.com>
      Tested-by: NJames Morse <james.morse@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org> # 4.7+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      0194e760
    • L
      arm64: Handle el1 synchronous instruction aborts cleanly · 9adeb8e7
      Laura Abbott 提交于
      Executing from a non-executable area gives an ugly message:
      
      lkdtm: Performing direct entry EXEC_RODATA
      lkdtm: attempting ok execution at ffff0000084c0e08
      lkdtm: attempting bad execution at ffff000008880700
      Bad mode in Synchronous Abort handler detected on CPU2, code 0x8400000e -- IABT (current EL)
      CPU: 2 PID: 998 Comm: sh Not tainted 4.7.0-rc2+ #13
      Hardware name: linux,dummy-virt (DT)
      task: ffff800077e35780 ti: ffff800077970000 task.ti: ffff800077970000
      PC is at lkdtm_rodata_do_nothing+0x0/0x8
      LR is at execute_location+0x74/0x88
      
      The 'IABT (current EL)' indicates the error but it's a bit cryptic
      without knowledge of the ARM ARM. There is also no indication of the
      specific address which triggered the fault. The increase in kernel
      page permissions makes hitting this case more likely as well.
      Handling the case in the vectors gives a much more familiar looking
      error message:
      
      lkdtm: Performing direct entry EXEC_RODATA
      lkdtm: attempting ok execution at ffff0000084c0840
      lkdtm: attempting bad execution at ffff000008880680
      Unable to handle kernel paging request at virtual address ffff000008880680
      pgd = ffff8000089b2000
      [ffff000008880680] *pgd=00000000489b4003, *pud=0000000048904003, *pmd=0000000000000000
      Internal error: Oops: 8400000e [#1] PREEMPT SMP
      Modules linked in:
      CPU: 1 PID: 997 Comm: sh Not tainted 4.7.0-rc1+ #24
      Hardware name: linux,dummy-virt (DT)
      task: ffff800077f9f080 ti: ffff800008a1c000 task.ti: ffff800008a1c000
      PC is at lkdtm_rodata_do_nothing+0x0/0x8
      LR is at execute_location+0x74/0x88
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9adeb8e7
  4. 12 8月, 2016 1 次提交
  5. 09 8月, 2016 1 次提交
  6. 29 7月, 2016 2 次提交
    • A
      arm64: relocatable: suppress R_AARCH64_ABS64 relocations in vmlinux · 08cc55b2
      Ard Biesheuvel 提交于
      The linker routines that we rely on to produce a relocatable PIE binary
      treat it as a shared ELF object in some ways, i.e., it emits symbol based
      R_AARCH64_ABS64 relocations into the final binary since doing so would be
      appropriate when linking a shared library that is subject to symbol
      preemption. (This means that an executable can override certain symbols
      that are exported by a shared library it is linked with, and that the
      shared library *must* update all its internal references as well, and point
      them to the version provided by the executable.)
      
      Symbol preemption does not occur for OS hosted PIE executables, let alone
      for vmlinux, and so we would prefer to get rid of these symbol based
      relocations. This would allow us to simplify the relocation routines, and
      to strip the .dynsym, .dynstr and .hash sections from the binary. (Note
      that these are tiny, and are placed in the .init segment, but they clutter
      up the vmlinux binary.)
      
      Note that these R_AARCH64_ABS64 relocations are only emitted for absolute
      references to symbols defined in the linker script, all other relocatable
      quantities are covered by anonymous R_AARCH64_RELATIVE relocations that
      simply list the offsets to all 64-bit values in the binary that need to be
      fixed up based on the offset between the link time and run time addresses.
      
      Fortunately, GNU ld has a -Bsymbolic option, which is intended for shared
      libraries to allow them to ignore symbol preemption, and unconditionally
      bind all internal symbol references to its own definitions. So set it for
      our PIE binary as well, and get rid of the asoociated sections and the
      relocation code that processes them.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: fixed conflict with __dynsym_offset linker script entry]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      08cc55b2
    • A
      arm64: vmlinux.lds: make __rela_offset and __dynsym_offset ABSOLUTE · d6732fc4
      Ard Biesheuvel 提交于
      Due to the untyped KIMAGE_VADDR constant, the linker may not notice
      that the __rela_offset and __dynsym_offset expressions are absolute
      values (i.e., are not subject to relocation). This does not matter for
      KASLR, but it does confuse kallsyms in relative mode, since it uses
      the lowest non-absolute symbol address as the anchor point, and expects
      all other symbol addresses to be within 4 GB of it.
      
      Fix this by qualifying these expressions as ABSOLUTE() explicitly.
      
      Fixes: 0cd3defe ("arm64: kernel: perform relocation processing from ID map")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d6732fc4
  7. 27 7月, 2016 1 次提交
  8. 22 7月, 2016 2 次提交
  9. 21 7月, 2016 5 次提交
    • S
      arm64: Honor nosmp kernel command line option · e75118a7
      Suzuki K Poulose 提交于
      Passing "nosmp" should boot the kernel with a single processor, without
      provision to enable secondary CPUs even if they are present. "nosmp" is
      implemented by setting maxcpus=0. At the moment we still mark the secondary
      CPUs present even with nosmp, which allows the userspace to bring them
      up. This patch corrects the smp_prepare_cpus() to honor the maxcpus == 0.
      
      Commit 44dbcc93 ("arm64: Fix behavior of maxcpus=N") fixed the
      behavior for maxcpus >= 1, but broke maxcpus = 0.
      
      Fixes: 44dbcc93 ("arm64: Fix behavior of maxcpus=N")
      Cc: <stable@vger.kernel.org> # 4.7+
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      [catalin.marinas@arm.com: updated code comment]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      e75118a7
    • S
      arm64: Fix incorrect per-cpu usage for boot CPU · 9113c2aa
      Suzuki K Poulose 提交于
      In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to  store
      the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for
      the boot CPU. This patch reorders the sequence to make sure we initialise
      the per-cpu offset before accessing the per-cpu area.
      
      Commit 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu") fixed the
      issue where we modified the per-cpu area even before the kernel initialises
      the per-cpu areas, but failed to wait until the boot cpu updated it's
      offset.
      
      Fixes: 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu")
      Cc: <stable@vger.kernel.org> # 4.4+
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9113c2aa
    • C
      arm64: kprobes: Add KASAN instrumentation around stack accesses · f7e35c5b
      Catalin Marinas 提交于
      This patch disables KASAN around the memcpy from/to the kernel or IRQ
      stacks to avoid warnings like below:
      
      BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0xe4/0x170 at addr ffff800935cbbbc0
      Read of size 128 by task swapper/0/1
      page:ffff7e0024d72ec0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x1000000000000000()
      page dumped because: kasan: bad access detected
      CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc4+ #1
      Hardware name: ARM Juno development board (r0) (DT)
      Call trace:
      [<ffff20000808ad88>] dump_backtrace+0x0/0x280
      [<ffff20000808b01c>] show_stack+0x14/0x20
      [<ffff200008563a64>] dump_stack+0xa4/0xc8
      [<ffff20000824a1fc>] kasan_report_error+0x4fc/0x528
      [<ffff20000824a5e8>] kasan_report+0x40/0x48
      [<ffff20000824948c>] check_memory_region+0x144/0x1a0
      [<ffff200008249814>] memcpy+0x34/0x68
      [<ffff200008c3ee2c>] setjmp_pre_handler+0xe4/0x170
      [<ffff200008c3ec5c>] kprobe_breakpoint_handler+0xec/0x1d8
      [<ffff2000080853a4>] brk_handler+0x5c/0xa0
      [<ffff2000080813f0>] do_debug_exception+0xa0/0x138
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f7e35c5b
    • M
      arm64: kprobes: Cleanup jprobe_return · 3b7d14e9
      Marc Zyngier 提交于
      jprobe_return seems to have aged badly. Comments referring to
      non-existent behaviours, and a dangerous habit of messing
      with registers without telling the compiler.
      
      This patches applies the following remedies:
      - Fix the comments to describe the actual behaviour
      - Tidy up the asm sequence to directly assign the
        stack pointer without clobbering extra registers
      - Mark the rest of the function as unreachable() so
        that the compiler knows that there is no need for
        an epilogue
      - Stop making jprobe_return_break a global function
        (you really don't want to call that guy, and it isn't
        even a function).
      
      Tested with tcp_probe.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      3b7d14e9
    • M
      arm64: kprobes: Fix overflow when saving stack · ab4c1325
      Marc Zyngier 提交于
      The MIN_STACK_SIZE macro tries evaluate how much stack space needs
      to be saved in the jprobes_stack array, sized at 128 bytes.
      
      When using the IRQ stack, said macro can happily return up to
      IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
      
      This patch fixes things by getting rid of the crazy macro and
      limiting the copy to be at most the size of the jprobes_stack
      array, no matter which stack we're on.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      ab4c1325
  10. 20 7月, 2016 1 次提交
  11. 19 7月, 2016 11 次提交
  12. 15 7月, 2016 1 次提交
  13. 12 7月, 2016 4 次提交
    • S
      arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs · f8d9f924
      Steve Capper 提交于
      It can be useful for JIT software to be aware of MIDR_EL1 and
      REVIDR_EL1 to ascertain the presence of any core errata that could
      affect code generation.
      
      This patch exposes these registers through sysfs:
      
      /sys/devices/system/cpu/cpu$ID/regs/identification/midr_el1
      /sys/devices/system/cpu/cpu$ID/regs/identification/revidr_el1
      
      where $ID is the cpu number. For big.LITTLE systems, one can have a
      mixture of cores (e.g. Cortex A53 and Cortex A57), thus all CPUs need
      to be enumerated.
      
      If the kernel does not have valid information to populate these entries
      with, an empty string is returned to userspace.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      [suzuki.poulose@arm.com: ABI documentation updates, hotplug notifiers, kobject changes]
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f8d9f924
    • K
      arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO · 49eea433
      Kevin Brodsky 提交于
      So far the arm64 clock_gettime() vDSO implementation only supported
      the following clocks, falling back to the syscall for the others:
      - CLOCK_REALTIME{,_COARSE}
      - CLOCK_MONOTONIC{,_COARSE}
      
      This patch adds support for the CLOCK_MONOTONIC_RAW clock, taking
      advantage of the recent refactoring of the vDSO time functions. Like
      the non-_COARSE clocks, this only works when the "arch_sys_counter"
      clocksource is in use (allowing us to read the current time from the
      virtual counter register), otherwise we also have to fall back to the
      syscall.
      
      Most of the data is shared with CLOCK_MONOTONIC, and the algorithm is
      similar. The reference implementation in kernel/time/timekeeping.c
      shows that:
      - CLOCK_MONOTONIC = tk->wall_to_monotonic + tk->xtime_sec +
        timekeeping_get_ns(&tk->tkr_mono)
      - CLOCK_MONOTONIC_RAW = tk->raw_time + timekeeping_get_ns(&tk->tkr_raw)
      - tkr_mono and tkr_raw are identical (in particular, same
        clocksource), except these members:
        * mult (only mono's multiplier is NTP-adjusted)
        * xtime_nsec (always 0 for raw)
      
      Therefore, tk->raw_time and tkr_raw->mult are now also stored in the
      vDSO data page.
      
      Cc: Ali Saidi <ali.saidi@arm.com>
      Signed-off-by: NKevin Brodsky <kevin.brodsky@arm.com>
      Reviewed-by: NDave Martin <dave.martin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      49eea433
    • K
      arm64: Refactor vDSO time functions · b33f491f
      Kevin Brodsky 提交于
      Time functions are directly implemented in assembly in arm64, and it
      is desirable to keep it this way for performance reasons (everything
      fits in registers, so that the stack is not used at all). However, the
      current implementation is quite difficult to read and understand (even
      considering it's assembly).  Additionally, due to the structure of
      __kernel_clock_gettime, which heavily uses conditional branches to
      share code between the different clocks, it is difficult to support a
      new clock without making the branches even harder to follow.
      
      This commit completely refactors the structure of clock_gettime (and
      gettimeofday along the way) while keeping exactly the same algorithms.
      We no longer try to share code; instead, macros provide common
      operations. This new approach comes with a number of advantages:
      - In clock_gettime, clock implementations are no longer interspersed,
        making them much more readable. Additionally, macros only use
        registers passed as arguments or reserved with .req, this way it is
        easy to make sure that registers are properly allocated. To avoid a
        large number of branches in a given execution path, a jump table is
        used; a normal execution uses 3 unconditional branches.
      - __do_get_tspec has been replaced with 2 macros (get_ts_clock_mono,
        get_clock_shifted_nsec) and explicit loading of data from the vDSO
        page. Consequently, clock_gettime and gettimeofday are now leaf
        functions, and saving x30 (lr) is no longer necessary.
      - Variables protected by tb_seq_count are now loaded all at once,
        allowing to merge the seqcnt_read macro into seqcnt_check.
      - For CLOCK_REALTIME_COARSE, removed an unused load of the wall to
        monotonic timespec.
      - For CLOCK_MONOTONIC_COARSE, removed a few shift instructions.
      
      Obviously, the downside of sharing less code is an increase in code
      size. However since the vDSO has its own code page, this does not
      really matter, as long as the size of the DSO remains below 4 kB. For
      now this should be all right:
                          Before  After
        vdso.so size (B)  2776    3000
      Signed-off-by: NKevin Brodsky <kevin.brodsky@arm.com>
      Reviewed-by: NDave Martin <dave.martin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      b33f491f
    • K
      arm64: fix vdso-offsets.h dependency · a66649da
      Kevin Brodsky 提交于
      arm64/kernel/{vdso,signal}.c include vdso-offsets.h, as well as any
      file that includes asm/vdso.h. Therefore, vdso-offsets.h must be
      generated before these files are compiled.
      
      The current rules in arm64/kernel/Makefile do not actually enforce
      this, because even though $(obj)/vdso is listed as a prerequisite for
      vdso-offsets.h, this does not result in the intended effect of
      building the vdso subdirectory (before all the other objects). As a
      consequence, depending on the order in which the rules are followed,
      vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
      are built. The current rules also impose an unnecessary dependency on
      vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
      rebuilds. This is made obvious when using make -j:
      
        touch arch/arm64/kernel/vdso/gettimeofday.S && make -j$NCPUS arch/arm64/kernel
      
      will sometimes result in none of arm64/kernel/*.o being
      rebuilt, sometimes all of them, or even just some of them.
      
      It is quite difficult to ensure that a header is generated before it
      is used with recursive Makefiles by using normal rules.  Instead,
      arch-specific generated headers are normally built in the archprepare
      recipe in the arch Makefile (see for instance arch/ia64/Makefile).
      Unfortunately, asm-offsets.h is included in gettimeofday.S, and must
      therefore be generated before vdso-offsets.h, which is not the case if
      archprepare is used. For this reason, a rule run after archprepare has
      to be used.
      
      This commit adds rules in arm64/Makefile to build vdso-offsets.h
      during the prepare step, ensuring that vdso-offsets.h is generated
      before building anything. It also removes the now-unnecessary
      dependencies on vdso-offsets.h in arm64/kernel/Makefile. Finally, it
      removes the duplication of asm-offsets.h between arm64/kernel/vdso/
      and include/generated/ and makes include/generated/vdso-offsets.h a
      target in arm64/kernel/vdso/Makefile.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Michal Marek <mmarek@suse.com>
      Signed-off-by: NKevin Brodsky <kevin.brodsky@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      a66649da