1. 26 Nov, 2014 4 commits
    • Laura Abbott's avatar
      arm64: Move some head.text functions to executable section · 034edabe
      Laura Abbott authored
      The head.text section is intended to be run at early bootup
      before any of the regular kernel mappings have been setup.
      Parts of head.text may be freed back into the buddy allocator
      due to TEXT_OFFSET so for security requirements this memory
      must not be executable. The suspend/resume/hotplug code path
      requires some of these head.S functions to run however which
      means they need to be executable. Support these conflicting
      requirements by moving the few head.text functions that need
      to be executable to the text section which has the appropriate
      page table permissions.
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      034edabe
    • Mark Rutland's avatar
      arm64: jump labels: NOP out NOP -> NOP replacement · 6ddae418
      Mark Rutland authored
      In the arm64 arch_static_branch implementation we place an A64 NOP into
      the instruction stream and log relevant details to a jump_entry in a
      __jump_table section. Later this may be replaced with an immediate
      branch without link to the code for the unlikely case.
      
      At init time, the core calls arch_jump_label_transform_static to
      initialise the NOPs. On x86 this involves inserting the optimal NOP for
      a given microarchitecture, but on arm64 we only use the architectural
      NOP, and hence replace each NOP with the exact same NOP. This is
      somewhat pointless.
      
      Additionally, at module load time we don't call jump_label_apply_nops to
      patch the optimal NOPs in, unlike other architectures, but get away with
      this because we only use the architectural NOP anyway. A later notifier
      will patch NOPs with branches as required.
      
      Similarly to x86 commit 11570da1 (x86/jump-label: Do not bother
      updating NOPs if they are correct), we can avoid patching NOPs with
      identical NOPs. Given that we only use a single NOP encoding, this means
      we can NOP-out the body of arch_jump_label_transform_static entirely. As
      the default __weak arch_jump_label_transform_static implementation
      performs a patch, we must use an empty function to achieve this.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Laura Abbott <lauraa@codeaurora.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6ddae418
    • Laura Abbott's avatar
      arm64: add support to dump the kernel page tables · c9465b4e
      Laura Abbott authored
      In a similar manner to arm, it's useful to be able to dump the page
      tables to verify permissions and memory types. Add a debugfs file
      to check the page tables.
      Acked-by: default avatarSteve Capper <steve.capper@linaro.org>
      Tested-by: default avatarSteve Capper <steve.capper@linaro.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      [will: s/BUFFERABLE/NORMAL-NC/]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c9465b4e
    • Laura Abbott's avatar
      arm64: Add FIX_HOLE to permanent fixed addresses · dab78b6d
      Laura Abbott authored
      Every other architecture with permanent fixed addresses has
      FIX_HOLE as the first entry. This seems to be designed as a
      debugging aid but there are a couple of side effects of not
      having FIX_HOLE:
      
      - If the first fixed address is 0, fix_to_virt -> virt_to_fix
      triggers a BUG_ON for the virtual address being equal to
      FIXADDR_TOP
      - fix_to_virt may return a value outside of FIXADDR_START
      and FIXADDR_TOP which may look like a bug to a developer.
      
      Match up with other architectures and make everything clearer
      by adding FIX_HOLE.
      Signed-off-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      dab78b6d
  2. 25 Nov, 2014 17 commits
  3. 21 Nov, 2014 1 commit
    • Will Deacon's avatar
      arm64: mm: report unhandled level-0 translation faults correctly · 7f73f7ae
      Will Deacon authored
      Translation faults that occur due to the input address being outside
      of the address range mapped by the relevant base register are reported
      as level 0 faults in ESR.DFSC.
      
      If the faulting access cannot be resolved by the kernel (e.g. because
      it is not mapped by a vma), then we report "input address range fault"
      on the console. This was fine until we added support for 48-bit VAs,
      which actually place PGDs at level 0 and can trigger faults for invalid
      addresses that are within the range of the page tables.
      
      This patch changes the string to report "level 0 translation fault",
      which is far less confusing.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7f73f7ae
  4. 20 Nov, 2014 9 commits
  5. 18 Nov, 2014 1 commit
    • Yann Droneaud's avatar
      arm64/mm: Remove hack in mmap randomize layout · d6c763af
      Yann Droneaud authored
      Since commit 8a0a9bd4 ('random: make get_random_int() more
      random'), get_random_int() returns a random value for each call,
      so comment and hack introduced in mmap_rnd() as part of commit
      1d18c47c ('arm64: MMU fault handling and page table management')
      are incorrects.
      
      Commit 1d18c47c seems to use the same hack introduced by
      commit a5adc91a ('powerpc: Ensure random space between stack
      and mmaps'), latter copied in commit 5a0efea0 ('sparc64: Sharpen
      address space randomization calculations.').
      
      But both architectures were cleaned up as part of commit
      fa8cbaaf ('powerpc+sparc64/mm: Remove hack in mmap randomize
      layout') as hack is no more needed since commit 8a0a9bd4.
      
      So the present patch removes the comment and the hack around
      get_random_int() on AArch64's mmap_rnd().
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarDan McGee <dpmcgee@gmail.com>
      Signed-off-by: default avatarYann Droneaud <ydroneaud@opteya.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d6c763af
  6. 17 Nov, 2014 2 commits
    • Catalin Marinas's avatar
      arm64: Add COMPAT_HWCAP_LPAE · 7d57511d
      Catalin Marinas authored
      Commit a469abd0 (ARM: elf: add new hwcap for identifying atomic
      ldrd/strd instructions) introduces HWCAP_ELF for 32-bit ARM
      applications. As LPAE is always present on arm64, report the
      corresponding compat HWCAP to user space.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org> # 3.11+
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7d57511d
    • Will Deacon's avatar
      mmu_gather: move minimal range calculations into generic code · fb7332a9
      Will Deacon authored
      On architectures with hardware broadcasting of TLB invalidation messages
      , it makes sense to reduce the range of the mmu_gather structure when
      unmapping page ranges based on the dirty address information passed to
      tlb_remove_tlb_entry.
      
      arm64 already does this by directly manipulating the start/end fields
      of the gather structure, but this confuses the generic code which
      does not expect these fields to change and can end up calculating
      invalid, negative ranges when forcing a flush in zap_pte_range.
      
      This patch moves the minimal range calculation out of the arm64 code
      and into the generic implementation, simplifying zap_pte_range in the
      process (which no longer needs to care about start/end, since they will
      point to the appropriate ranges already). With the range being tracked
      by core code, the need_flush flag is dropped in favour of checking that
      the end of the range has actually been set.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fb7332a9
  7. 14 Nov, 2014 3 commits
    • Will Deacon's avatar
      arm64: entry: use ldp/stp instead of push/pop when saving/restoring regs · 63648dd2
      Will Deacon authored
      The push/pop instructions can be suboptimal when saving/restoring large
      amounts of data to/from the stack, for example on entry/exit from the
      kernel. This is because:
      
        (1) They act on descending addresses (i.e. the newly decremented sp),
            which may defeat some hardware prefetchers
      
        (2) They introduce an implicit dependency between each instruction, as
            the sp has to be updated in order to resolve the address of the
            next access.
      
      This patch removes the push/pop instructions from our kernel entry/exit
      macros in favour of ldp/stp plus offset.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      63648dd2
    • Will Deacon's avatar
      arm64: entry: avoid writing lr explicitly for constructing return paths · d54e81f9
      Will Deacon authored
      Using an explicit adr instruction to set the link register to point at
      ret_fast_syscall/ret_to_user can defeat branch and return stack predictors.
      
      Instead, use the standard calling instructions (bl, blr) and have an
      unconditional branch as the following instruction.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d54e81f9
    • Mark Rutland's avatar
      arm64: Fix up /proc/cpuinfo · 44b82b77
      Mark Rutland authored
      Commit d7a49086 (arm64: cpuinfo: print info for all CPUs)
      attempted to clean up /proc/cpuinfo, but due to concerns regarding
      further changes was reverted in commit 5e39977e (Revert "arm64:
      cpuinfo: print info for all CPUs").
      
      There are two major issues with the arm64 /proc/cpuinfo format
      currently:
      
      * The "Features" line describes (only) the 64-bit hwcaps, which is
        problematic for some 32-bit applications which attempt to parse it. As
        the same names are used for analogous ISA features (e.g. aes) despite
        these generally being architecturally unrelated, it is not possible to
        simply append the 64-bit and 32-bit hwcaps in a manner that might not
        be misleading to some applications.
      
        Various potential solutions have appeared in vendor kernels. Typically
        the format of the Features line varies depending on whether the task
        is 32-bit.
      
      * Information is only printed regarding a single CPU. This does not
        match the ARM format, and does not provide sufficient information in
        big.LITTLE systems where CPUs are heterogeneous. The CPU information
        printed is queried from the current CPU's registers, which is racy
        w.r.t. cross-cpu migration.
      
      This patch attempts to solve these issues. The following changes are
      made:
      
      * When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
        the "Features" line contains the decoded 32-bit hwcaps, as with the
        arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
        with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
        the absense of compat support, the Features line is empty.
      
        The set of hwcaps injected into a task's auxval are unaffected.
      
      * Properties are printed per-cpu, as with the ARM port. The per-cpu
        information is queried from pre-recorded cpu information (as used by
        the sanity checks).
      
      * As with the previous attempt at fixing up /proc/cpuinfo, the hardware
        field is removed. The only users so far are 32-bit applications tied
        to particular boards, so no portable applications should be affected,
        and this should prevent future tying to particular boards.
      
      The following differences remain:
      
      * No model_name is printed, as this cannot be queried from the hardware
        and cannot be provided in a stable fashion. Use of the CPU
        {implementor,variant,part,revision} fields is sufficient to identify a
        CPU and is portable across arm and arm64.
      
      * The following system-wide properties are not provided, as they are not
        possible to provide generally. Programs relying on these are already
        tied to particular (32-bit only) boards:
        - Hardware
        - Revision
        - Serial
      
      No software has yet been identified for which these remaining
      differences are problematic.
      
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Serban Constantinescu <serban.constantinescu@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cross-distro@lists.linaro.org
      Cc: linux-api@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      44b82b77
  8. 07 Nov, 2014 2 commits
  9. 06 Nov, 2014 1 commit