1. 05 Dec, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: ftrace: emit ftrace-mod.o contents through code · e9b2a668
      Ard Biesheuvel authored
      commit be0f272b upstream.
      When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and
      CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built
      with the kernel and contains a trampoline that is linked into each
      module, so that modules can be loaded far away from the kernel and
      still reach the ftrace entry point in the core kernel with an ordinary
      relative branch, as is emitted by the compiler instrumentation code
      dynamic ftrace relies on.
      In order to be able to build out of tree modules, this object file
      needs to be included into the linux-headers or linux-devel packages,
      which is undesirable, as it makes arm64 a special case (although a
      precedent does exist for 32-bit PPC).
      Given that the trampoline essentially consists of a PLT entry, let's
      not bother with a source or object file for it, and simply patch it
      in whenever the trampoline is being populated, using the existing
      PLT support routines.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 18 Sep, 2017 1 commit
  3. 26 Jun, 2017 1 commit
    • Luc Van Oostenryck's avatar
      arm64: pass endianness info to sparse · bcde519e
      Luc Van Oostenryck authored
      ARM64 depends on the macro __AARCH64EB__ being defined or not
      to correctly select or define endian-specific macros, structures
      or pieces of code.
      This macro is predefined by the compiler but sparse knows nothing
      about it and thus may pre-process files differently from what
      gcc would.
      Fix this by passing '-D__AARCH64EL__' or '-D__AARCH64EB__' to
      sparse depending of the endianness of the kernel, like defined
      by GCC.
      Note: In most case it won't change anything since most arm64 use
            little-endian (but an allyesconfig would use big-endian!).
      CC: Catalin Marinas <catalin.marinas@arm.com>
      CC: Will Deacon <will.deacon@arm.com>
      CC: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  4. 20 Jun, 2017 1 commit
    • Luc Van Oostenryck's avatar
      arm64: pass machine size to sparse · f5d28490
      Luc Van Oostenryck authored
      When using sparse on the arm64 tree we get many thousands of
      warnings like 'constant ... is so big it is unsigned long long'
      or 'shift too big (32) for type unsigned long'. This happens
      because by default sparse considers the machine as 32bit and
      defines the size of the types accordingly.
      Fix this by passing the '-m64' flag to sparse so that
      sparse can correctly define longs as being 64bit.
      CC: Catalin Marinas <catalin.marinas@arm.com>
      CC: Will Deacon <will.deacon@arm.com>
      CC: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  5. 07 Jun, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: ftrace: add support for far branches to dynamic ftrace · e71a4e1b
      Ard Biesheuvel authored
      Currently, dynamic ftrace support in the arm64 kernel assumes that all
      core kernel code is within range of ordinary branch instructions that
      occur in module code, which is usually the case, but is no longer
      guaranteed now that we have support for module PLTs and address space
      Since on arm64, all patching of branch instructions involves function
      calls to the same entry point [ftrace_caller()], we can emit the modules
      with a trampoline that has unlimited range, and patch both the trampoline
      itself and the branch instruction to redirect the call via the trampoline.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: minor clarification to smp_wmb() comment]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  6. 12 Apr, 2017 1 commit
    • Marc Zyngier's avatar
      arm64: Silence spurious kbuild warning on menuconfig · d91750f1
      Marc Zyngier authored
      Since bbb56c27 ("arm64: Add detection code for broken .inst support
      in binutils"), running any make target that doesn't involve the cross
      compiler results in a spurious warning:
      $ make ARCH=arm64 menuconfig
      arch/arm64/Makefile:43: Detected assembler with broken .inst; disassembly will be unreliable
      $ make ARCH=arm64 CROSS_COMPILE=aarch64-arm-linux- menuconfig
      is silent (assuming your compiler is not affected). That's because
      the code that tests for the workaround is always run, irrespective
      of the current configuration being available or not.
      An easy fix is to make the detection conditional on CONFIG_ARM64
      being defined, which is only the case when actually building
      Fixes: bbb56c27 ("arm64: Add detection code for broken .inst support in binutils")
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  7. 20 Mar, 2017 1 commit
  8. 06 Dec, 2016 1 commit
  9. 20 Oct, 2016 1 commit
    • Ard Biesheuvel's avatar
      arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y · b9dce7f1
      Ard Biesheuvel authored
      GNU ld used to set the ELF file type to ET_DYN for PIE executables, which
      is the same file type used for shared libraries. However, this was changed
      recently, and now PIE executables are emitted as ET_EXEC instead.
      The distinction is only relevant for ELF loaders, and so there is little
      reason to care about the difference when building the kernel, which is
      why the change has gone unnoticed until now.
      However, debuggers do use the ELF binary, and expect ET_EXEC type files
      to appear in memory at the exact offset described in the ELF metadata.
      This means source level debugging is no longer possible when KASLR is in
      effect or when executing the stub.
      So add the -shared LD option when building with CONFIG_RELOCATABLE=y. This
      forces the ELF file type to be set to ET_DYN (which is what you get when
      building with binutils 2.24 and earlier anyway), and has no other ill
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  10. 31 Aug, 2016 1 commit
  11. 26 Aug, 2016 1 commit
  12. 29 Jul, 2016 1 commit
    • Ard Biesheuvel's avatar
      arm64: relocatable: suppress R_AARCH64_ABS64 relocations in vmlinux · 08cc55b2
      Ard Biesheuvel authored
      The linker routines that we rely on to produce a relocatable PIE binary
      treat it as a shared ELF object in some ways, i.e., it emits symbol based
      R_AARCH64_ABS64 relocations into the final binary since doing so would be
      appropriate when linking a shared library that is subject to symbol
      preemption. (This means that an executable can override certain symbols
      that are exported by a shared library it is linked with, and that the
      shared library *must* update all its internal references as well, and point
      them to the version provided by the executable.)
      Symbol preemption does not occur for OS hosted PIE executables, let alone
      for vmlinux, and so we would prefer to get rid of these symbol based
      relocations. This would allow us to simplify the relocation routines, and
      to strip the .dynsym, .dynstr and .hash sections from the binary. (Note
      that these are tiny, and are placed in the .init segment, but they clutter
      up the vmlinux binary.)
      Note that these R_AARCH64_ABS64 relocations are only emitted for absolute
      references to symbols defined in the linker script, all other relocatable
      quantities are covered by anonymous R_AARCH64_RELATIVE relocations that
      simply list the offsets to all 64-bit values in the binary that need to be
      fixed up based on the offset between the link time and run time addresses.
      Fortunately, GNU ld has a -Bsymbolic option, which is intended for shared
      libraries to allow them to ignore symbol preemption, and unconditionally
      bind all internal symbol references to its own definitions. So set it for
      our PIE binary as well, and get rid of the asoociated sections and the
      relocation code that processes them.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: fixed conflict with __dynsym_offset linker script entry]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  13. 19 Jul, 2016 1 commit
  14. 11 Jul, 2016 1 commit
    • Kevin Brodsky's avatar
      arm64: fix vdso-offsets.h dependency · a66649da
      Kevin Brodsky authored
      arm64/kernel/{vdso,signal}.c include vdso-offsets.h, as well as any
      file that includes asm/vdso.h. Therefore, vdso-offsets.h must be
      generated before these files are compiled.
      The current rules in arm64/kernel/Makefile do not actually enforce
      this, because even though $(obj)/vdso is listed as a prerequisite for
      vdso-offsets.h, this does not result in the intended effect of
      building the vdso subdirectory (before all the other objects). As a
      consequence, depending on the order in which the rules are followed,
      vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
      are built. The current rules also impose an unnecessary dependency on
      vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
      rebuilds. This is made obvious when using make -j:
        touch arch/arm64/kernel/vdso/gettimeofday.S && make -j$NCPUS arch/arm64/kernel
      will sometimes result in none of arm64/kernel/*.o being
      rebuilt, sometimes all of them, or even just some of them.
      It is quite difficult to ensure that a header is generated before it
      is used with recursive Makefiles by using normal rules.  Instead,
      arch-specific generated headers are normally built in the archprepare
      recipe in the arch Makefile (see for instance arch/ia64/Makefile).
      Unfortunately, asm-offsets.h is included in gettimeofday.S, and must
      therefore be generated before vdso-offsets.h, which is not the case if
      archprepare is used. For this reason, a rule run after archprepare has
      to be used.
      This commit adds rules in arm64/Makefile to build vdso-offsets.h
      during the prepare step, ensuring that vdso-offsets.h is generated
      before building anything. It also removes the now-unnecessary
      dependencies on vdso-offsets.h in arm64/kernel/Makefile. Finally, it
      removes the duplication of asm-offsets.h between arm64/kernel/vdso/
      and include/generated/ and makes include/generated/vdso-offsets.h a
      target in arm64/kernel/vdso/Makefile.
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Michal Marek <mmarek@suse.com>
      Signed-off-by: default avatarKevin Brodsky <kevin.brodsky@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  15. 21 Jun, 2016 1 commit
  16. 03 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: fix alignment when RANDOMIZE_TEXT_OFFSET is enabled · aed7eb83
      Mark Rutland authored
      With ARM64_64K_PAGES and RANDOMIZE_TEXT_OFFSET enabled, we hit the
      following issue on the boot:
      kernel BUG at arch/arm64/mm/mmu.c:480!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0 #310
      Hardware name: ARM Juno development board (r2) (DT)
      task: ffff000008d58a80 ti: ffff000008d30000 task.ti: ffff000008d30000
      PC is at map_kernel_segment+0x44/0xb0
      LR is at paging_init+0x84/0x5b0
      pc : [<ffff000008c450b4>] lr : [<ffff000008c451a4>] pstate: 600002c5
      Call trace:
      [<ffff000008c450b4>] map_kernel_segment+0x44/0xb0
      [<ffff000008c451a4>] paging_init+0x84/0x5b0
      [<ffff000008c42728>] setup_arch+0x198/0x534
      [<ffff000008c40848>] start_kernel+0x70/0x388
      [<ffff000008c401bc>] __primary_switched+0x30/0x74
      Commit 7eb90f2f ("arm64: cover the .head.text section in the .text
      segment mapping") removed the alignment between the .head.text and .text
      sections, and used the _text rather than the _stext interval for mapping
      the .text segment.
      Prior to this commit _stext was always section aligned and didn't cause
      any issue even when RANDOMIZE_TEXT_OFFSET was enabled. Since that
      alignment has been removed and _text is used to map the .text segment,
      we need ensure _text is always page aligned when RANDOMIZE_TEXT_OFFSET
      is enabled.
      This patch adds logic to TEXT_OFFSET fuzzing to ensure that the offset
      is always aligned to the kernel page size. To ensure this, we rely on
      the PAGE_SHIFT being available via Kconfig.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Fixes: 7eb90f2f ("arm64: cover the .head.text section in the .text segment mapping")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  17. 24 Feb, 2016 2 commits
    • 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>
    • 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>
  18. 19 Feb, 2016 1 commit
  19. 26 Jan, 2016 2 commits
  20. 12 Oct, 2015 2 commits
    • 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>
    • Will Deacon's avatar
      arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419 · b6dd8e07
      Will Deacon authored
      Commit df057cc7 ("arm64: errata: add module build workaround for
      erratum #843419") sets CFLAGS_MODULE to ensure that the large memory
      model is used by the compiler when building kernel modules.
      However, CFLAGS_MODULE is an environment variable and intended to be
      overridden on the command line, which appears to be the case with the
      Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead.
      Cc: <stable@vger.kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Fixes: df057cc7 ("arm64: errata: add module build workaround for erratum #843419")
      Reported-by: default avatarDann Frazier <dann.frazier@canonical.com>
      Tested-by: default avatarDann Frazier <dann.frazier@canonical.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  21. 17 Sep, 2015 1 commit
    • Will Deacon's avatar
      arm64: errata: add module build workaround for erratum #843419 · df057cc7
      Will Deacon authored
      Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can
      lead to a memory access using an incorrect address in certain sequences
      headed by an ADRP instruction.
      There is a linker fix to generate veneers for ADRP instructions, but
      this doesn't work for kernel modules which are built as unlinked ELF
      This patch adds a new config option for the erratum which, when enabled,
      builds kernel modules with the mcmodel=large flag. This uses absolute
      addressing for all kernel symbols, thereby removing the use of ADRP as
      a PC-relative form of addressing. The ADRP relocs are removed from the
      module loader so that we fail to load any potentially affected modules.
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  22. 27 Jul, 2015 2 commits
  23. 17 Mar, 2015 1 commit
    • Steve Capper's avatar
      arm64: Adjust EFI libstub object include logic · ad08fd49
      Steve Capper authored
      Commit f4f75ad5 ("efi: efistub: Convert into static library")
      introduced a static library for EFI stub, libstub.
      The EFI libstub directory is referenced by the kernel build system via
      a obj subdirectory rule in:
      Unfortunately, arm64 also references the EFI libstub via:
      libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/
      If we're unlucky, the kernel build system can enter libstub via two
      simultaneous threads resulting in build failures such as:
      fixdep: error opening depfile: drivers/firmware/efi/libstub/.efi-stub-helper.o.d: No such file or directory
      scripts/Makefile.build:257: recipe for target 'drivers/firmware/efi/libstub/efi-stub-helper.o' failed
      make[1]: *** [drivers/firmware/efi/libstub/efi-stub-helper.o] Error 2
      Makefile:939: recipe for target 'drivers/firmware/efi/libstub' failed
      make: *** [drivers/firmware/efi/libstub] Error 2
      make: *** Waiting for unfinished jobs....
      This patch adjusts the arm64 Makefile to reference the compiled library
      explicitly (as is currently done in x86), rather than the directory.
      Fixes: f4f75ad5 efi: efistub: Convert into static library
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  24. 20 Jan, 2015 1 commit
  25. 15 Jan, 2015 1 commit
    • Kevin Hao's avatar
      arm64: kill off the libgcc dependency · d67703a8
      Kevin Hao authored
      The arm64 kernel builds fine without the libgcc. Actually it should not
      be used at all in the kernel. The following are the reasons indicated
      by Russell King:
        Although libgcc is part of the compiler, libgcc is built with the
        expectation that it will be running in userland - it expects to link
        to a libc.  That's why you can't build libgcc without having the glibc
        headers around.
        Meanwhile, having the kernel build the compiler support functions that
        it needs ensures that (a) we know what compiler support functions are
        being used, (b) we know the implementation of those support functions
        are sane for use in the kernel, (c) we can build them with appropriate
        compiler flags for best performance, and (d) we remove an unnecessary
        dependency on the build toolchain.
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  26. 21 Oct, 2014 3 commits
  27. 02 Oct, 2014 1 commit
  28. 08 Sep, 2014 1 commit
  29. 19 Aug, 2014 1 commit
    • Ard Biesheuvel's avatar
      arm64: align randomized TEXT_OFFSET on 4 kB boundary · 4190312b
      Ard Biesheuvel authored
      When booting via UEFI, the kernel Image is loaded at a 4 kB boundary and
      the embedded EFI stub is executed in place. The EFI stub relocates the
      Image to reside TEXT_OFFSET bytes above a 2 MB boundary, and jumps into
      the kernel proper.
      In AArch64, PC relative symbol references are emitted using adrp/add or
      adrp/ldr pairs, where the offset into a 4 kB page is resolved using a
      separate :lo12: relocation. This implicitly assumes that the code will
      always be executed at the same relative offset with respect to a 4 kB
      boundary, or the references will point to the wrong address.
      This means we should link the kernel at a 4 kB aligned base address in
      order to remain compatible with the base address the UEFI loader uses
      when doing the initial load of Image. So update the code that generates
      TEXT_OFFSET to choose a multiple of 4 kB.
      At the same time, update the code so it chooses from the interval [0..2MB)
      as the author originally intended.
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  30. 18 Jul, 2014 1 commit
    • Ard Biesheuvel's avatar
      efi: efistub: Convert into static library · f4f75ad5
      Ard Biesheuvel authored
      This patch changes both x86 and arm64 efistub implementations
      from #including shared .c files under drivers/firmware/efi to
      building shared code as a static library.
      The x86 code uses a stub built into the boot executable which
      uncompresses the kernel at boot time. In this case, the library is
      linked into the decompressor.
      In the arm64 case, the stub is part of the kernel proper so the library
      is linked into the kernel proper as well.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  31. 10 Jul, 2014 1 commit
    • Mark Rutland's avatar
      arm64: Enable TEXT_OFFSET fuzzing · da57a369
      Mark Rutland authored
      The arm64 Image header contains a text_offset field which bootloaders
      are supposed to read to determine the offset (from a 2MB aligned "start
      of memory" per booting.txt) at which to load the kernel. The offset is
      not well respected by bootloaders at present, and due to the lack of
      variation there is little incentive to support it. This is unfortunate
      for the sake of future kernels where we may wish to vary the text offset
      (even zeroing it).
      This patch adds options to arm64 to enable fuzz-testing of text_offset.
      CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET forces the text offset to a random
      16-byte aligned value value in the range [0..2MB) upon a build of the
      kernel. It is recommended that distribution kernels enable randomization
      to test bootloaders such that any compliance issues can be fixed early.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarTom Rini <trini@ti.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  32. 14 May, 2014 1 commit
  33. 25 Oct, 2013 1 commit
  34. 19 Jun, 2013 1 commit