1. 02 Mar, 2017 2 commits
  2. 28 Feb, 2017 3 commits
  3. 25 Feb, 2017 1 commit
  4. 24 Feb, 2017 3 commits
    • Mark Rutland's avatar
      arm64/cpufeature: check correct field width when updating sys_val · 638f863d
      Mark Rutland authored
      
      
      When we're updating a register's sys_val, we use arm64_ftr_value() to
      find the new field value. We use cpuid_feature_extract_field() to find
      the new value, but this implicitly assumes a 4-bit field, so we may
      extract more bits than we mean to for fields like CTR_EL0.L1ip.
      
      This affects update_cpu_ftr_reg(), where we may extract erroneous values
      for ftr_cur and ftr_new. Depending on the additional bits extracted in
      either case, we may erroneously detect that the value is mismatched, and
      we'll try to compute a new safe value.
      
      Dependent on these extra bits and feature type, arm64_ftr_safe_value()
      may pessimistically select the always-safe value, or may erroneously
      choose either the extracted cur or new value as the safe option. The
      extra bits will subsequently be masked out in arm64_ftr_set_value(), so
      we may choose a higher value, yet write back a lower one.
      
      Fix this by passing the width down explicitly in arm64_ftr_value(), so
      we always extract the correct amount.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      638f863d
    • Mark Rutland's avatar
      Revert "arm64: mm: set the contiguous bit for kernel mappings where appropriate" · d81bbe6d
      Mark Rutland authored
      This reverts commit 0bfc445d.
      
      When we change the permissions of regions mapped using contiguous
      entries, the architecture requires us to follow a Break-Before-Make
      strategy, breaking *all* associated entries before we can change any of
      the following properties from the entries:
      
       - presence of the contiguous bit
       - output address
       - attributes
       - permissiones
      
      Failure to do so can result in a number of problems (e.g. TLB conflict
      aborts and/or erroneous results from TLB lookups).
      
      See ARM DDI 0487A.k_iss10775, "Misprogramming of the Contiguous bit",
      page D4-1762.
      
      We do not take this into account when altering the permissions of kernel
      segments in mark_rodata_ro(), where we change the permissions of live
      contiguous entires one-by-one, leaving them transiently inconsistent.
      This has been observed to result in failures on some fast model
      configurations.
      
      Unfortunately, we cannot follow Break-Before-Make here as we'd have to
      unmap kernel text and data used to perform the sequence.
      
      For the timebeing, revert commit 0bfc445d
      
       so as to avoid issues
      resulting from this misuse of the contiguous bit.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <Will.Deacon@arm.com>
      Cc: stable@vger.kernel.org # v4.10
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d81bbe6d
    • Shanker Donthineni's avatar
      arm64: Avoid clobbering mm in erratum workaround on QDF2400 · ea6eac90
      Shanker Donthineni authored
      Commit 38fd94b0 ("arm64: Work around Falkor erratum 1003") tried to
      work around a hardware erratum, but actually caused a system crash of
      its own during switch_mm:
      
       cpu_do_switch_mm+0x20/0x40
       efi_virtmap_load+0x34/0x40
       virt_efi_get_next_variable+0x64/0xc8
       efivar_init+0x8c/0x348
       efisubsys_init+0xd4/0x270
       do_one_initcall+0x80/0x110
       kernel_init_freeable+0x19c/0x240
       kernel_init+0x10/0x100
       ret_from_fork+0x10/0x50
      
       Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      
      In cpu_do_switch_mm, x1 contains the mm_struct pointer, which needs to
      be preserved by the pre_ttbr0_update_workaround macro rather than passed
      as a temporary.
      
      This patch clobbers x2 and x3 instead, keeping the mm_struct intact
      after the workaround has run.
      
      Fixes: 38fd94b0
      
       ("arm64: Work around Falkor erratum 1003")
      Tested-by: default avatarManoj Iyer <manoj.iyer@canonical.com>
      Signed-off-by: default avatarShanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ea6eac90
  5. 21 Feb, 2017 2 commits
  6. 17 Feb, 2017 2 commits
    • Daniel Borkmann's avatar
      bpf: make jited programs visible in traces · 74451e66
      Daniel Borkmann authored
      Long standing issue with JITed programs is that stack traces from
      function tracing check whether a given address is kernel code
      through {__,}kernel_text_address(), which checks for code in core
      kernel, modules and dynamically allocated ftrace trampolines. But
      what is still missing is BPF JITed programs (interpreted programs
      are not an issue as __bpf_prog_run() will be attributed to them),
      thus when a stack trace is triggered, the code walking the stack
      won't see any of the JITed ones. The same for address correlation
      done from user space via reading /proc/kallsyms. This is read by
      tools like perf, but the latter is also useful for permanent live
      tracing with eBPF itself in combination with stack maps when other
      eBPF types are part of the callchain. See offwaketime example on
      dumping stack from a map.
      
      This work tries to tackle that issue by making the addresses and
      symbols known to the kernel. The lookup from *kernel_text_address()
      is implemented through a latche...
      74451e66
    • Daniel Borkmann's avatar
      bpf: remove stubs for cBPF from arch code · 9383191d
      Daniel Borkmann authored
      
      
      Remove the dummy bpf_jit_compile() stubs for eBPF JITs and make
      that a single __weak function in the core that can be overridden
      similarly to the eBPF one. Also remove stale pr_err() mentions
      of bpf_jit_compile.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9383191d
  7. 15 Feb, 2017 6 commits
    • Mark Rutland's avatar
      arm64/kprobes: consistently handle MRS/MSR with XZR · ffe7afd1
      Mark Rutland authored
      
      
      Now that we have XZR-safe helpers for fiddling with registers, use these
      in the arm64 kprobes code rather than open-coding the logic.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ffe7afd1
    • Mark Rutland's avatar
      arm64: cpufeature: correctly handle MRS to XZR · 521c6461
      Mark Rutland authored
      
      
      In emulate_mrs() we may erroneously write back to the user SP rather
      than XZR if we trap an MRS instruction where Xt == 31.
      
      Use the new pt_regs_write_reg() helper to handle this correctly.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 77c97b4e
      
       ("arm64: cpufeature: Expose CPUID registers by emulation")
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      521c6461
    • Mark Rutland's avatar
      arm64: traps: correctly handle MRS/MSR with XZR · 8b6e70fc
      Mark Rutland authored
      
      
      Currently we hand-roll XZR-safe register handling in
      user_cache_maint_handler(), though we forget to do the same in
      ctr_read_handler(), and may erroneously write back to the user SP rather
      than XZR.
      
      Use the new helpers to handle these cases correctly and consistently.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 116c81f4
      
       ("arm64: Work around systems with mismatched cache line sizes")
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8b6e70fc
    • Mark Rutland's avatar
      arm64: ptrace: add XZR-safe regs accessors · 6c23e2ff
      Mark Rutland authored
      
      
      In A64, XZR and the SP share the same encoding (31), and whether an
      instruction accesses XZR or SP for a particular register parameter
      depends on the definition of the instruction.
      
      We store the SP in pt_regs::regs[31], and thus when emulating
      instructions, we must be careful to not erroneously read from or write
      back to the saved SP. Unfortunately, we often fail to be this careful.
      
      In all cases, instructions using a transfer register parameter Xt use
      this to refer to XZR rather than SP. This patch adds helpers so that we
      can more easily and consistently handle these cases.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6c23e2ff
    • Arnd Bergmann's avatar
      arm64: include asm/assembler.h in entry-ftrace.S · f705d954
      Arnd Bergmann authored
      In a randconfig build I ran into this build error:
      
      arch/arm64/kernel/entry-ftrace.S: Assembler messages:
      arch/arm64/kernel/entry-ftrace.S:101: Error: unknown mnemonic `ldr_l' -- `ldr_l x2,ftrace_trace_function'
      
      The macro is defined in asm/assembler.h, so we should include that file.
      
      Fixes: 829d2bd1
      
       ("arm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l")
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f705d954
    • Arnd Bergmann's avatar
      arm64: fix warning about swapper_pg_dir overflow · 12f043ff
      Arnd Bergmann authored
      
      
      With 4 levels of 16KB pages, we get this warning about the fact that we are
      copying a whole page into an array that is declared as having only two pointers
      for the top level of the page table:
      
      arch/arm64/mm/mmu.c: In function 'paging_init':
      arch/arm64/mm/mmu.c:528:2: error: 'memcpy' writing 16384 bytes into a region of size 16 overflows the destination [-Werror=stringop-overflow=]
      
      This is harmless since we actually reserve a whole page in the definition of the
      array that comes from, and just the extern declaration is short. The pgdir
      is initialized to zero either way, so copying the actual entries here seems
      like the best solution.
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      12f043ff
  8. 14 Feb, 2017 1 commit
  9. 11 Feb, 2017 2 commits
  10. 10 Feb, 2017 1 commit
    • Christopher Covington's avatar
      arm64: Work around Falkor erratum 1003 · 38fd94b0
      Christopher Covington authored
      
      
      The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
      using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
      is triggered, page table entries using the new translation table base
      address (BADDR) will be allocated into the TLB using the old ASID. All
      circumstances leading to the incorrect ASID being cached in the TLB arise
      when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
      operation is in the process of performing a translation using the specific
      TTBRx_EL1 being written, and the memory operation uses a translation table
      descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
      ASID is not subject to this erratum because hardware is prohibited from
      performing translations from an out-of-context translation regime.
      
      Consider the following pseudo code.
      
        write new BADDR and ASID values to TTBRx_EL1
      
      Replacing the above sequence with the one below will ensure that no TLB
      entries with an incorrect ASID are used by software.
      
        write reserved value to TTBRx_EL1[ASID]
        ISB
        write new value to TTBRx_EL1[BADDR]
        ISB
        write new value to TTBRx_EL1[ASID]
        ISB
      
      When the above sequence is used, page table entries using the new BADDR
      value may still be incorrectly allocated into the TLB using the reserved
      ASID. Yet this will not reduce functionality, since TLB entries incorrectly
      tagged with the reserved ASID will never be hit by a later instruction.
      
      Based on work by Shanker Donthineni <shankerd@codeaurora.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarChristopher Covington <cov@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      38fd94b0
  11. 09 Feb, 2017 5 commits
  12. 08 Feb, 2017 7 commits
  13. 07 Feb, 2017 4 commits
  14. 06 Feb, 2017 1 commit