1. 11 12月, 2017 2 次提交
  2. 07 11月, 2017 1 次提交
  3. 28 7月, 2017 1 次提交
  4. 30 5月, 2017 1 次提交
  5. 06 4月, 2017 1 次提交
    • T
      arm64: kdump: protect crash dump kernel memory · 98d2e153
      Takahiro Akashi 提交于
      arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
      are meant to be called by kexec_load() in order to protect the memory
      allocated for crash dump kernel once the image is loaded.
      
      The protection is implemented by unmapping the relevant segments in crash
      dump kernel memory, rather than making it read-only as other archs do,
      to prevent coherency issues due to potential cache aliasing (with
      mismatched attributes).
      
      Page-level mappings are consistently used here so that we can change
      the attributes of segments in page granularity as well as shrink the region
      also in page granularity through /sys/kernel/kexec_crash_size, putting
      the freed memory back to buddy system.
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      98d2e153
  6. 23 3月, 2017 10 次提交
  7. 24 2月, 2017 1 次提交
    • M
      Revert "arm64: mm: set the contiguous bit for kernel mappings where appropriate" · d81bbe6d
      Mark Rutland 提交于
      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: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by: NJean-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: NWill Deacon <will.deacon@arm.com>
      d81bbe6d
  8. 15 2月, 2017 1 次提交
  9. 13 1月, 2017 1 次提交
  10. 12 1月, 2017 1 次提交
  11. 08 11月, 2016 4 次提交
  12. 07 9月, 2016 1 次提交
  13. 22 8月, 2016 1 次提交
  14. 01 8月, 2016 1 次提交
  15. 26 7月, 2016 2 次提交
  16. 01 7月, 2016 4 次提交
  17. 28 6月, 2016 1 次提交
  18. 16 4月, 2016 1 次提交
  19. 15 4月, 2016 2 次提交
  20. 25 3月, 2016 1 次提交
    • M
      arm64: consistently use p?d_set_huge · c661cb1c
      Mark Rutland 提交于
      Commit 324420bf ("arm64: add support for ioremap() block
      mappings") added new p?d_set_huge functions which do the hard work to
      generate and set a correct block entry.
      
      These differ from open-coded huge page creation in the early page table
      code by explicitly setting the P?D_TYPE_SECT bits (which are implicitly
      retained by mk_sect_prot() for any valid prot), but are otherwise
      identical (and cannot fail on arm64).
      
      For simplicity and consistency, make use of these in the initial page
      table creation code.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      c661cb1c
  21. 26 2月, 2016 1 次提交
  22. 24 2月, 2016 1 次提交
    • A
      arm64: add support for kernel ASLR · f80fb3a3
      Ard Biesheuvel 提交于
      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: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f80fb3a3