1. 03 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: update stale PAGE_OFFSET comment · a13e3a5b
      Mark Rutland authored
      Commit ab893fb9 ("arm64: introduce KIMAGE_VADDR as the virtual
      base of the kernel region") logically split KIMAGE_VADDR from
      PAGE_OFFSET, and since commit f9040773 ("arm64: move kernel
      image to base of vmalloc area") the two have been distinct values.
      Unfortunately, neither commit updated the comment above these
      definitions, which now erroneously states that PAGE_OFFSET is the start
      of the kernel image rather than the start of the linear mapping.
      This patch fixes said comment, and introduces an explanation of
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  2. 28 Apr, 2016 1 commit
  3. 14 Apr, 2016 2 commits
  4. 29 Feb, 2016 1 commit
    • Ard Biesheuvel's avatar
      arm64: mm: treat memstart_addr as a signed quantity · 020d044f
      Ard Biesheuvel authored
      Commit c031a421 ("arm64: kaslr: randomize the linear region")
      implements randomization of the linear region, by subtracting a random
      multiple of PUD_SIZE from memstart_addr. This causes the virtual mapping
      of system RAM to move upwards in the linear region, and at the same time
      causes memstart_addr to assume a value which may be negative if the offset
      of system RAM in the physical space is smaller than its offset relative to
      PAGE_OFFSET in the virtual space.
      Since memstart_addr is effectively an offset now, redefine its type as s64
      so that expressions involving shifting or division preserve its sign.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  5. 24 Feb, 2016 1 commit
    • Ard Biesheuvel's avatar
      arm64: add support for kernel ASLR · f80fb3a3
      Ard Biesheuvel authored
      This adds support for KASLR is implemented, based on entropy provided by
      the bootloader in the /chosen/kaslr-seed DT property. Depending on the size
      of the address space (VA_BITS) and the page size, the entropy in the
      virtual displacement is up to 13 bits (16k/2 levels) and up to 25 bits (all
      4 levels), with the sidenote that displacements that result in the kernel
      image straddling a 1GB/32MB/512MB alignment boundary (for 4KB/16KB/64KB
      granule kernels, respectively) are not allowed, and will be rounded up to
      an acceptable value.
      If CONFIG_RANDOMIZE_MODULE_REGION_FULL is enabled, the module region is
      randomized independently from the core kernel. This makes it less likely
      that the location of core kernel data structures can be determined by an
      adversary, but causes all function calls from modules into the core kernel
      to be resolved via entries in the module PLTs.
      If CONFIG_RANDOMIZE_MODULE_REGION_FULL is not enabled, the module region is
      randomized by choosing a page aligned 128 MB region inside the interval
      [_etext - 128 MB, _stext + 128 MB). This gives between 10 and 14 bits of
      entropy (depending on page size), independently of the kernel randomization,
      but still guarantees that modules are within the range of relative branch
      and jump instructions (with the caveat that, since the module region is
      shared with other uses of the vmalloc area, modules may need to be loaded
      further away if the module region is exhausted)
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  6. 23 Feb, 2016 2 commits
  7. 18 Feb, 2016 5 commits
    • Ard Biesheuvel's avatar
      arm64: allow kernel Image to be loaded anywhere in physical memory · a7f8de16
      Ard Biesheuvel authored
      This relaxes the kernel Image placement requirements, so that it
      may be placed at any 2 MB aligned offset in physical memory.
      This is accomplished by ignoring PHYS_OFFSET when installing
      memblocks, and accounting for the apparent virtual offset of
      the kernel Image. As a result, virtual address references
      below PAGE_OFFSET are correctly mapped onto physical references
      into the kernel Image regardless of where it sits in memory.
      Special care needs to be taken for dealing with memory limits passed
      via mem=, since the generic implementation clips memory top down, which
      may clip the kernel image itself if it is loaded high up in memory. To
      deal with this case, we simply add back the memory covering the kernel
      image, which may result in more memory to be retained than was passed
      as a mem= parameter.
      Since mem= should not be considered a production feature, a panic notifier
      handler is installed that dumps the memory limit at panic time if one was
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Ard Biesheuvel's avatar
      arm64: defer __va translation of initrd_start and initrd_end · a89dea58
      Ard Biesheuvel authored
      Before deferring the assignment of memstart_addr in a subsequent patch, to
      the moment where all memory has been discovered and possibly clipped based
      on the size of the linear region and the presence of a mem= command line
      parameter, we need to ensure that memstart_addr is not used to perform __va
      translations before it is assigned.
      One such use is in the generic early DT discovery of the initrd location,
      which is recorded as a virtual address in the globals initrd_start and
      initrd_end. So wire up the generic support to declare the initrd addresses,
      and implement it without __va() translations, and perform the translation
      after memstart_addr has been assigned.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Ard Biesheuvel's avatar
      arm64: move kernel image to base of vmalloc area · f9040773
      Ard Biesheuvel authored
      This moves the module area to right before the vmalloc area, and moves
      the kernel image to the base of the vmalloc area. This is an intermediate
      step towards implementing KASLR, which allows the kernel image to be
      located anywhere in the vmalloc area.
      Since other subsystems such as hibernate may still need to refer to the
      kernel text or data segments via their linears addresses, both are mapped
      in the linear region as well. The linear alias of the text region is
      mapped read-only/non-executable to prevent inadvertent modification or
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Ard Biesheuvel's avatar
      arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region · ab893fb9
      Ard Biesheuvel authored
      This introduces the preprocessor symbol KIMAGE_VADDR which will serve as
      the symbolic virtual base of the kernel region, i.e., the kernel's virtual
      offset will be KIMAGE_VADDR + TEXT_OFFSET. For now, we define it as being
      equal to PAGE_OFFSET, but in the future, it will be moved below it once
      we move the kernel virtual mapping out of the linear mapping.
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Ard Biesheuvel's avatar
      arm64: add support for ioremap() block mappings · 324420bf
      Ard Biesheuvel authored
      This wires up the existing generic huge-vmap feature, which allows
      ioremap() to use PMD or PUD sized block mappings. It also adds support
      to the unmap path for dealing with block mappings, which will allow us
      to unmap the __init region using unmap_kernel_range() in a subsequent
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  8. 28 Oct, 2015 1 commit
  9. 07 Oct, 2015 1 commit
  10. 27 Aug, 2015 1 commit
  11. 24 Aug, 2015 1 commit
  12. 08 Aug, 2015 1 commit
  13. 23 Jan, 2015 1 commit
    • Mark Rutland's avatar
      arm64: Fix overlapping VA allocations · aa03c428
      Mark Rutland authored
      PCI IO space was intended to be 16MiB, at 32MiB below MODULES_VADDR, but
      commit d1e6dc91 ("arm64: Add architectural support for PCI")
      extended this to cover the full 32MiB. The final 8KiB of this 32MiB is
      also allocated for the fixmap, allowing for potential clashes between
      the two.
      This change was masked by assumptions in mem_init and the page table
      dumping code, which assumed the I/O space to be 16MiB long through
      seaparte hard-coded definitions.
      This patch changes the definition of the PCI I/O space allocation to
      live in asm/memory.h, along with the other VA space allocations. As the
      fixmap allocation depends on the number of fixmap entries, this is moved
      below the PCI I/O space allocation. Both the fixmap and PCI I/O space
      are guarded with 2MB of padding. Sites assuming the I/O space was 16MiB
      are moved over use new PCI_IO_{START,END} definitions, which will keep
      in sync with the size of the IO space (now restored to 16MiB).
      As a useful side effect, the use of the new PCI_IO_{START,END}
      definitions prevents a build issue in the dumping code due to a (now
      redundant) missing include of io.h for PCI_IOBASE.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Laura Abbott <lauraa@codeaurora.org>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      [catalin.marinas@arm.com: reorder FIXADDR and PCI_IO address_markers_idx enum]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  14. 13 Nov, 2014 1 commit
  15. 10 Nov, 2014 1 commit
  16. 23 Jul, 2014 1 commit
  17. 08 Jul, 2014 1 commit
    • Colin Cross's avatar
      arm64: implement TASK_SIZE_OF · fa2ec3ea
      Colin Cross authored
      include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it
      is not set by the architecture headers.  TASK_SIZE uses the
      current task to determine the size of the virtual address space.
      On a 64-bit kernel this will cause reading /proc/pid/pagemap of a
      64-bit process from a 32-bit process to return EOF when it reads
      past 0xffffffff.
      Implement TASK_SIZE_OF exactly the same as TASK_SIZE with
      test_tsk_thread_flag instead of test_thread_flag.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  18. 12 May, 2014 1 commit
  19. 08 May, 2014 1 commit
  20. 07 Apr, 2014 1 commit
  21. 19 Dec, 2013 1 commit
    • Laura Abbott's avatar
      arm64: Correct virt_addr_valid · e26db3f3
      Laura Abbott authored
      The definition of virt_addr_valid is that virt_addr_valid should
      return true if and only if virt_to_page returns a valid pointer.
      The current definition of virt_addr_valid only checks against the
      virtual address range. There's no guarantee that just because a
      virtual address falls bewteen PAGE_OFFSET and high_memory the
      associated physical memory has a valid backing struct page. Follow
      the example of other architectures and convert to pfn_valid to
      verify that the virtual address is actually valid.
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  22. 05 Nov, 2013 1 commit
  23. 07 Jun, 2013 1 commit
  24. 22 Jan, 2013 1 commit
    • Catalin Marinas's avatar
      arm64: Add simple earlyprintk support · 2475ff9d
      Catalin Marinas authored
      This patch adds support for "earlyprintk=" parameter on the kernel
      command line. The format is:
      where <name> is the name of the (UART) device, e.g. "pl011", <addr> is
      the I/O address. The <options> aren't currently used.
      The mapping of the earlyprintk device is done very early during kernel
      boot and there are restrictions on which functions it can call. A
      special early_io_map() function is added which creates the mapping from
      the pre-defined EARLY_IOBASE to the device I/O address passed via the
      kernel parameter. The pgd entry corresponding to EARLY_IOBASE is
      pre-populated in head.S during kernel boot.
      Only PL011 is currently supported and it is assumed that the interface
      is already initialised by the boot loader before the kernel is started.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
  25. 17 Sep, 2012 1 commit
    • Catalin Marinas's avatar
      arm64: MMU definitions · 4f04d8f0
      Catalin Marinas authored
      The virtual memory layout is described in
      Documentation/arm64/memory.txt. This patch adds the MMU definitions for
      the 4KB and 64KB translation table configurations. The SECTION_SIZE is
      2MB with 4KB page and 512MB with 64KB page configuration.
      PHYS_OFFSET is calculated at run-time and stored in a variable (no
      run-time code patching at this stage).
      On the current implementation, both user and kernel address spaces are
      512G (39-bit) each with a maximum of 256G for the RAM linear mapping.
      Linux uses 3 levels of translation tables with the 4K page configuration
      and 2 levels with the 64K configuration. Extending the memory space
      beyond 39-bit with the 4K pages or 42-bit with 64K pages requires an
      additional level of translation tables.
      The SPARSEMEM configuration is global to all AArch64 platforms and
      allows for 1GB sections with SPARSEMEM_VMEMMAP enabled by default.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>