All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 03 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: move {PAGE,CONT}_SHIFT into Kconfig · 030c4d24
      Mark Rutland authored
      In some cases (e.g. the awk for CONFIG_RANDOMIZE_TEXT_OFFSET) we would
      like to make use of PAGE_SHIFT outside of code that can include the
      usual header files.
      
      Add a new CONFIG_ARM64_PAGE_SHIFT for this, likewise with
      ARM64_CONT_SHIFT for consistency.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      030c4d24
  2. 16 May, 2016 1 commit
    • Daniel Borkmann's avatar
      bpf: split HAVE_BPF_JIT into cBPF and eBPF variant · 6077776b
      Daniel Borkmann authored
      Split the HAVE_BPF_JIT into two for distinguishing cBPF and eBPF JITs.
      
      Current cBPF ones:
      
        # git grep -n HAVE_CBPF_JIT arch/
        arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
        arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
        arch/powerpc/Kconfig:129:       select HAVE_CBPF_JIT
        arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
      
      Current eBPF ones:
      
        # git grep -n HAVE_EBPF_JIT arch/
        arch/arm64/Kconfig:61:  select HAVE_EBPF_JIT
        arch/s390/Kconfig:126:  select HAVE_EBPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES
        arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if X86_64
      
      Later code also needs this facility to check for eBPF JITs.
      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>
      6077776b
  3. 28 Apr, 2016 3 commits
    • Ezequiel Garcia's avatar
      arm64: kconfig: drop CONFIG_RTC_LIB dependency · 99a50777
      Ezequiel Garcia authored
      The rtc-lib dependency is not required, and seems it was just
      copy-pasted from ARM's Kconfig. If platform requires rtc-lib,
      they should select it individually.
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      99a50777
    • Will Deacon's avatar
      arm64: make ARCH_SUPPORTS_DEBUG_PAGEALLOC depend on !HIBERNATION · da24eb1f
      Will Deacon authored
      Selecting both DEBUG_PAGEALLOC and HIBERNATION results in a build failure:
      
      | kernel/built-in.o: In function `saveable_page':
      | memremap.c:(.text+0x100f90): undefined reference to `kernel_page_present'
      | kernel/built-in.o: In function `swsusp_save':
      | memremap.c:(.text+0x1026f0): undefined reference to `kernel_page_present'
      | make: *** [vmlinux] Error 1
      
      James sayeth:
      
      "This is caused by DEBUG_PAGEALLOC, which clears the PTE_VALID bit from
      'free' pages. Hibernate uses it as a hint that it shouldn't save/access
      that page. This function is used to test whether the PTE_VALID bit has
      been cleared by kernel_map_pages(), hibernate is the only user.
      
      Fixing this exposes a bigger problem with that configuration though: if
      the resume kernel has cut free pages out of the linear map, we copy this
      swiss-cheese view of memory, and try to use it to restore...
      
      We can fixup the copy of the linear map, but it then explodes in my lazy
      'clean the whole kernel to PoC' after resume, as now both the kernel and
      linear map have holes in them."
      
      On closer inspection, the whole Kconfig machinery around DEBUG_PAGEALLOC,
      HIBERNATION, ARCH_SUPPORTS_DEBUG_PAGEALLOC and PAGE_POISONING looks like
      it might need some affection. In particular, DEBUG_ALLOC has:
      
      > depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
      
      which looks pretty fishy.
      
      For the moment, require ARCH_SUPPORTS_DEBUG_PAGEALLOC to depend on
      !HIBERNATION on arm64 and get allmodconfig building again.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      da24eb1f
    • James Morse's avatar
      arm64: kernel: Add support for hibernate/suspend-to-disk · 82869ac5
      James Morse authored
      Add support for hibernate/suspend-to-disk.
      
      Suspend borrows code from cpu_suspend() to write cpu state onto the stack,
      before calling swsusp_save() to save the memory image.
      
      Restore creates a set of temporary page tables, covering only the
      linear map, copies the restore code to a 'safe' page, then uses the copy to
      restore the memory image. The copied code executes in the lower half of the
      address space, and once complete, restores the original kernel's page
      tables. It then calls into cpu_resume(), and follows the normal
      cpu_suspend() path back into the suspend code.
      
      To restore a kernel using KASLR, the address of the page tables, and
      cpu_resume() are stored in the hibernate arch-header and the el2
      vectors are pivotted via the 'safe' page in low memory.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: Kevin Hilman <khilman@baylibre.com> # Tested on Juno R2
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      82869ac5
  4. 20 Apr, 2016 1 commit
  5. 15 Apr, 2016 2 commits
  6. 08 Mar, 2016 2 commits
    • Bjorn Helgaas's avatar
      PCI: Include pci/hotplug Kconfig directly from pci/Kconfig · e7e127e3
      Bjorn Helgaas authored
      Include pci/hotplug/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/hotplug/Kconfig.
      
      Note that this effectively adds pci/hotplug/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/hotplug/Kconfig:
      
        alpha
        arm
        avr32
        frv
        m68k
        microblaze
        mn10300
        sparc
        unicore32
      
      Inspired-by-patch-from: Bogicevic Sasa <brutallesale@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      e7e127e3
    • Bogicevic Sasa's avatar
      PCI: Include pci/pcie/Kconfig directly from pci/Kconfig · 5f8fc432
      Bogicevic Sasa authored
      Include pci/pcie/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/pcie/Kconfig.
      
      Note that this effectively adds pci/pcie/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/pcie/Kconfig:
      
        alpha
        avr32
        blackfin
        frv
        m32r
        m68k
        microblaze
        mn10300
        parisc
        sparc
        unicore32
        xtensa
      
      [bhelgaas: changelog, source pci/pcie/Kconfig at top of pci/Kconfig, whitespace]
      Signed-off-by: default avatarSasa Bogicevic <brutallesale@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      5f8fc432
  7. 29 Feb, 2016 1 commit
  8. 26 Feb, 2016 2 commits
  9. 24 Feb, 2016 4 commits
    • Ard Biesheuvel's avatar
      arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness · 2b5fe07a
      Ard Biesheuvel authored
      Since arm64 does not use a decompressor that supplies an execution
      environment where it is feasible to some extent to provide a source of
      randomness, the arm64 KASLR kernel depends on the bootloader to supply
      some random bits in the /chosen/kaslr-seed DT property upon kernel entry.
      
      On UEFI systems, we can use the EFI_RNG_PROTOCOL, if supplied, to obtain
      some random bits. At the same time, use it to randomize the offset of the
      kernel Image in physical memory.
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      2b5fe07a
    • 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>
      f80fb3a3
    • Ard Biesheuvel's avatar
      arm64: add support for building vmlinux as a relocatable PIE binary · 1e48ef7f
      Ard Biesheuvel authored
      This implements CONFIG_RELOCATABLE, which links the final vmlinux
      image with a dynamic relocation section, allowing the early boot code
      to perform a relocation to a different virtual address at runtime.
      
      This is a prerequisite for KASLR (CONFIG_RANDOMIZE_BASE).
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      1e48ef7f
    • Ard Biesheuvel's avatar
      arm64: add support for module PLTs · fd045f6c
      Ard Biesheuvel authored
      This adds support for emitting PLTs at module load time for relative
      branches that are out of range. This is a prerequisite for KASLR, which
      may place the kernel and the modules anywhere in the vmalloc area,
      making it more likely that branch target offsets exceed the maximum
      range of +/- 128 MB.
      
      In this version, I removed the distinction between relocations against
      .init executable sections and ordinary executable sections. The reason
      is that it is hardly worth the trouble, given that .init.text usually
      does not contain that many far branches, and this version now only
      reserves PLT entry space for jump and call relocations against undefined
      symbols (since symbols defined in the same module can be assumed to be
      within +/- 128 MB)
      
      For example, the mac80211.ko module (which is fairly sizable at ~400 KB)
      built with -mcmodel=large gives the following relocation counts:
      
                          relocs    branches   unique     !local
        .text              3925       3347       518        219
        .init.text           11          8         7          1
        .exit.text            4          4         4          1
        .text.unlikely       81         67        36         17
      
      ('unique' means branches to unique type/symbol/addend combos, of which
      !local is the subset referring to undefined symbols)
      
      IOW, we are only emitting a single PLT entry for the .init sections, and
      we are better off just adding it to the core PLT section instead.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      fd045f6c
  10. 18 Feb, 2016 2 commits
  11. 16 Feb, 2016 3 commits
  12. 20 Jan, 2016 1 commit
    • Christoph Hellwig's avatar
      dma-mapping: always provide the dma_map_ops based implementation · e1c7e324
      Christoph Hellwig authored
      Move the generic implementation to <linux/dma-mapping.h> now that all
      architectures support it and remove the HAVE_DMA_ATTR Kconfig symbol now
      that everyone supports them.
      
      [valentinrothberg@gmail.com: remove leftovers in Kconfig]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Helge Deller <deller@gmx.de>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarValentin Rothberg <valentinrothberg@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e1c7e324
  13. 14 Jan, 2016 1 commit
    • Daniel Cashman's avatar
      arm64: mm: support ARCH_MMAP_RND_BITS · 8f0d3aa9
      Daniel Cashman authored
      arm64: arch_mmap_rnd() uses STACK_RND_MASK to generate the random offset
      for the mmap base address.  This value represents a compromise between
      increased ASLR effectiveness and avoiding address-space fragmentation.
      Replace it with a Kconfig option, which is sensibly bounded, so that
      platform developers may choose where to place this compromise.  Keep
      default values as new minimums.
      Signed-off-by: default avatarDaniel Cashman <dcashman@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mark Salyzyn <salyzyn@android.com>
      Cc: Jeff Vander Stoep <jeffv@google.com>
      Cc: Nick Kralevich <nnk@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f0d3aa9
  14. 09 Jan, 2016 1 commit
  15. 04 Jan, 2016 1 commit
  16. 21 Dec, 2015 2 commits
    • David Woods's avatar
      arm64: hugetlb: add support for PTE contiguous bit · 66b3923a
      David Woods authored
      The arm64 MMU supports a Contiguous bit which is a hint that the TTE
      is one of a set of contiguous entries which can be cached in a single
      TLB entry.  Supporting this bit adds new intermediate huge page sizes.
      
      The set of huge page sizes available depends on the base page size.
      Without using contiguous pages the huge page sizes are as follows.
      
       4KB:   2MB  1GB
      64KB: 512MB
      
      With a 4KB granule, the contiguous bit groups together sets of 16 pages
      and with a 64KB granule it groups sets of 32 pages.  This enables two new
      huge page sizes in each case, so that the full set of available sizes
      is as follows.
      
       4KB:  64KB   2MB  32MB  1GB
      64KB:   2MB 512MB  16GB
      
      If a 16KB granule is used then the contiguous bit groups 128 pages
      at the PTE level and 32 pages at the PMD level.
      
      If the base page size is set to 64KB then 2MB pages are enabled by
      default.  It is possible in the future to make 2MB the default huge
      page size for both 4KB and 64KB granules.
      Reviewed-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Reviewed-by: default avatarSteve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarDavid Woods <dwoods@ezchip.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      66b3923a
    • Stefano Stabellini's avatar
      arm64: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops · dfd57bc3
      Stefano Stabellini authored
      Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
      Necessary duplication of paravirt.h and paravirt.c with ARM.
      
      The only paravirt interface supported is pv_time_ops.steal_clock, so no
      runtime pvops patching needed.
      
      This allows us to make use of steal_account_process_tick for stolen
      ticks accounting.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      dfd57bc3
  17. 03 Dec, 2015 1 commit
  18. 26 Nov, 2015 1 commit
  19. 24 Nov, 2015 1 commit
  20. 10 Nov, 2015 1 commit
  21. 28 Oct, 2015 1 commit
  22. 20 Oct, 2015 1 commit
    • Catalin Marinas's avatar
      arm64: Make 36-bit VA depend on EXPERT · 56a3f30e
      Catalin Marinas authored
      Commit 21539939 (arm64: 36 bit VA) introduced 36-bit VA support for
      the arm64 kernel when the 16KB page configuration is enabled. While this
      is a valid hardware configuration, it's not something we want to
      encourage since it reduces the memory (and I/O) range that the kernel
      can access. Make this depend on EXPERT to avoid complaints of Linux not
      mapping the whole RAM, especially on platforms following the ARM
      recommended memory map.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      56a3f30e
  23. 19 Oct, 2015 4 commits
  24. 15 Oct, 2015 1 commit
  25. 12 Oct, 2015 1 commit
    • Andrey Ryabinin's avatar
      arm64: add KASAN support · 39d114dd
      Andrey Ryabinin authored
      This patch adds arch specific code for kernel address sanitizer
      (see Documentation/kasan.txt).
      
      1/8 of kernel addresses reserved for shadow memory. There was no
      big enough hole for this, so virtual addresses for shadow were
      stolen from vmalloc area.
      
      At early boot stage the whole shadow region populated with just
      one physical page (kasan_zero_page). Later, this page reused
      as readonly zero shadow for some memory that KASan currently
      don't track (vmalloc).
      After mapping the physical memory, pages for shadow memory are
      allocated and mapped.
      
      Functions like memset/memmove/memcpy do a lot of memory accesses.
      If bad pointer passed to one of these function it is important
      to catch this. Compiler's instrumentation cannot do this since
      these functions are written in assembly.
      KASan replaces memory functions with manually instrumented variants.
      Original functions declared as weak symbols so strong definitions
      in mm/kasan/kasan.c could replace them. Original functions have aliases
      with '__' prefix in name, so we could call non-instrumented variant
      if needed.
      Some files built without kasan instrumentation (e.g. mm/slub.c).
      Original mem* function replaced (via #define) with prefixed variants
      to disable memory access checks for such files.
      Signed-off-by: default avatarAndrey Ryabinin <ryabinin.a.a@gmail.com>
      Tested-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      39d114dd