An error occurred fetching the project authors.
  1. 17 Apr, 2019 1 commit
  2. 01 Mar, 2019 1 commit
  3. 01 Feb, 2019 1 commit
  4. 31 Dec, 2018 1 commit
  5. 12 Dec, 2018 1 commit
    • Ard Biesheuvel's avatar
      ARM: smp: add support for per-task stack canaries · 189af465
      Ard Biesheuvel authored
      On ARM, we currently only change the value of the stack canary when
      switching tasks if the kernel was built for UP. On SMP kernels, this
      is impossible since the stack canary value is obtained via a global
      symbol reference, which means
      a) all running tasks on all CPUs must use the same value
      b) we can only modify the value when no kernel stack frames are live
         on any CPU, which is effectively never.
      
      So instead, use a GCC plugin to add a RTL pass that replaces each
      reference to the address of the __stack_chk_guard symbol with an
      expression that produces the address of the 'stack_canary' field
      that is added to struct thread_info. This way, each task will use
      its own randomized value.
      
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: kernel-hardening@lists.openwall.com
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      189af465
  6. 04 Oct, 2018 1 commit
  7. 02 Oct, 2018 1 commit
    • Rob Herring's avatar
      kbuild: consolidate Devicetree dtb build rules · 37c8a5fa
      Rob Herring authored
      There is nothing arch specific about building dtb files other than their
      location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
      The dependencies and supported targets are all slightly different.
      Also, a cross-compiler for each arch is needed, but really the host
      compiler preprocessor is perfectly fine for building dtbs. Move the
      build rules to a common location and remove the arch specific ones. This
      is done in a single step to avoid warnings about overriding rules.
      
      The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
      These pull in several dependencies some of which need a target compiler
      (specifically devicetable-offsets.h) and aren't needed to build dtbs.
      All that is really needed is dtc, so adjust the dependencies to only be
      dtc.
      
      This change enables support 'dtbs_install' on some arches which were
      missing the target.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarPaul Burton <paul.burton@mips.com>
      Acked-by: default avatarLey Foon Tan <ley.foon.tan@intel.com>
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Cc: linux-mips@linux-mips.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      37c8a5fa
  8. 19 Sep, 2018 1 commit
  9. 23 Aug, 2018 1 commit
  10. 01 Aug, 2018 1 commit
  11. 18 Jul, 2018 1 commit
  12. 11 Jul, 2018 1 commit
  13. 01 Jun, 2018 1 commit
  14. 19 May, 2018 1 commit
  15. 23 Apr, 2018 1 commit
  16. 06 Mar, 2018 1 commit
  17. 17 Dec, 2017 1 commit
    • Nicolas Pitre's avatar
      ARM: 8723/2: always assume the "unified" syntax for assembly code · 75fea300
      Nicolas Pitre authored
      The GNU assembler has implemented the "unified syntax" parsing since
      2005. This "unified" syntax is required when the kernel is built in
      Thumb2 mode. However the "unified" syntax is a mixed bag of features,
      including not requiring a `#' prefix with immediate operands. This leads
      to situations where some code builds just fine in Thumb2 mode and fails
      to build in ARM mode if that prefix is missing. This behavior
      discrepancy makes build tests less valuable, forcing both ARM and Thumb2
      builds for proper coverage.
      
      Let's "fix" this issue by always using the "unified" syntax for both ARM
      and Thumb2 mode. Given that the documented minimum binutils version that
      properly builds the kernel is version 2.20 released in 2010, we can
      assume that any toolchain capable of building the latest kernel is also
      "unified syntax" capable.
      
      Whith this, a bunch of macros used to mask some differences between both
      syntaxes can be removed, with the side effect of making LTO easier.
      Suggested-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      75fea300
  18. 01 Nov, 2017 1 commit
    • Luc Van Oostenryck's avatar
      ARM: 8716/1: pass endianness info to sparse · ff0c6eec
      Luc Van Oostenryck authored
      ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined
      or not to correctly select or define endian-specific macros,
      structures or pieces of code.
      
      These macros are predefined by the compiler but sparse knows
      nothing about them and thus may pre-process files differently
      from what gcc would.
      
      Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse,
      depending on the endianness of the kernel, like defined by GCC.
      
      Note: In most case it won't change anything since most ARMs use
            little-endian (but an allyesconfig would use big-endian!).
      
      To: Russell King <linux@armlinux.org.uk>
      
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      ff0c6eec
  19. 30 Oct, 2017 1 commit
  20. 29 Oct, 2017 1 commit
  21. 12 Oct, 2017 1 commit
  22. 21 Jun, 2017 1 commit
  23. 20 Mar, 2017 1 commit
  24. 23 Nov, 2016 1 commit
  25. 18 Oct, 2016 2 commits
    • Russell King's avatar
      ARM: convert to generated system call tables · 96a8fae0
      Russell King authored
      Convert ARM to use a similar mechanism to x86 to generate the unistd.h
      system call numbers and the various kernel system call tables.  This
      means that rather than having to edit three places (asm/unistd.h for
      the total number of system calls, uapi/asm/unistd.h for the system call
      numbers, and arch/arm/kernel/calls.S for the call table) we have only
      one place to edit, making the process much more simple.
      
      The scripts have knowledge of the table padding requirements, so there's
      no need to worry about __NR_syscalls not fitting within the immediate
      constant field of ALU instructions anymore.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      96a8fae0
    • Russell King's avatar
      ARM: remove indirection of asm/mach-types.h · 4e2648db
      Russell King authored
      Arrange for mach-types.h to be directly generated in the relevant
      path, so we don't need a one-liner file in arch/arm/include/asm/.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      4e2648db
  26. 12 Aug, 2016 1 commit
  27. 10 Aug, 2016 1 commit
    • Arnd Bergmann's avatar
      ARM: hide mach-*/ include for ARM_SINGLE_ARMV7M · de8a06f6
      Arnd Bergmann authored
      The machine specific header files are exported for traditional
      platforms, but not for the ones that use ARCH_MULTIPLATFORM, as
      they could conflict with one another.
      
      In case of ARM_SINGLE_ARMV7M, we end up also exporting them,
      but that appears to be a mistake, and we should treat it the
      same way as ARCH_MULTIPLATFORM here.
      
      'make W=1' warns about this because it passes -Wmissing-includes
      to gcc and the directories are not actually present.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      de8a06f6
  28. 06 Jul, 2016 1 commit
  29. 22 Jun, 2016 1 commit
    • Masahiro Yamada's avatar
      ARM: 8576/1: avoid duplicating "Kernel: arch/arm/boot/*Image is ready" · c6bbfbb7
      Masahiro Yamada authored
      Commit 3939f334 ("ARM: 8418/1: add boot image dependencies to
      not generate invalid images") fixed bad image generation for the
      parallel building, but as its side effect, Kbuild now descends into
      arch/arm/boot/ again and again, duplicating the log messages.
      It looks clumsy, so let's display the same message only once.
      
      This commit moves the log rules from arch/arm/boot/Makefile to
      arch/arm/Makefile.  I did not delete them completely because *Image
      are the final targets that users are interested in.
      
      Without this commit, the log of incremental build is like follows:
      
      $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
        CHK     include/config/kernel.release
        CHK     include/generated/uapi/linux/version.h
        CHK     include/generated/utsrelease.h
        CHK     include/generated/bounds.h
        CHK     include/generated/timeconst.h
        CHK     include/generated/asm-offsets.h
        CALL    scripts/checksyscalls.sh
        CHK     include/generated/compile.h
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Image arch/arm/boot/uImage is ready
      
      With this commit, it will look like follows:
      
      $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
        CHK     include/config/kernel.release
        CHK     include/generated/uapi/linux/version.h
        CHK     include/generated/utsrelease.h
        CHK     include/generated/bounds.h
        CHK     include/generated/timeconst.h
        CHK     include/generated/asm-offsets.h
        CALL    scripts/checksyscalls.sh
        CHK     include/generated/compile.h
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Kernel: arch/arm/boot/uImage is ready
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c6bbfbb7
  30. 26 Apr, 2016 1 commit
  31. 24 Feb, 2016 1 commit
  32. 16 Feb, 2016 1 commit
  33. 31 Dec, 2015 1 commit
  34. 22 Dec, 2015 1 commit
  35. 07 Sep, 2015 1 commit
    • Ard Biesheuvel's avatar
      ARM: 8429/1: disable GCC SRA optimization · a077224f
      Ard Biesheuvel authored
      While working on the 32-bit ARM port of UEFI, I noticed a strange
      corruption in the kernel log. The following snprintf() statement
      (in drivers/firmware/efi/efi.c:efi_md_typeattr_format())
      
      	snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
      
      was producing the following output in the log:
      
      	|    |   |   |   |    |WB|WT|WC|UC]
      	|    |   |   |   |    |WB|WT|WC|UC]
      	|    |   |   |   |    |WB|WT|WC|UC]
      	|RUN|   |   |   |    |WB|WT|WC|UC]*
      	|RUN|   |   |   |    |WB|WT|WC|UC]*
      	|    |   |   |   |    |WB|WT|WC|UC]
      	|RUN|   |   |   |    |WB|WT|WC|UC]*
      	|    |   |   |   |    |WB|WT|WC|UC]
      	|RUN|   |   |   |    |   |   |   |UC]
      	|RUN|   |   |   |    |   |   |   |UC]
      
      As it turns out, this is caused by incorrect code being emitted for
      the string() function in lib/vsprintf.c. The following code
      
      	if (!(spec.flags & LEFT)) {
      		while (len < spec.field_width--) {
      			if (buf < end)
      				*buf = ' ';
      			++buf;
      		}
      	}
      	for (i = 0; i < len; ++i) {
      		if (buf < end)
      			*buf = *s;
      		++buf; ++s;
      	}
      	while (len < spec.field_width--) {
      		if (buf < end)
      			*buf = ' ';
      		++buf;
      	}
      
      when called with len == 0, triggers an issue in the GCC SRA optimization
      pass (Scalar Replacement of Aggregates), which handles promotion of signed
      struct members incorrectly. This is a known but as yet unresolved issue.
      (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
      case, it is causing the second while loop to be executed erroneously a
      single time, causing the additional space characters to be printed.
      
      So disable the optimization by passing -fno-ipa-sra.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a077224f
  36. 18 Aug, 2015 1 commit
    • Masahiro Yamada's avatar
      ARM: 8418/1: add boot image dependencies to not generate invalid images · 3939f334
      Masahiro Yamada authored
      U-Boot is often used to boot the kernel on ARM boards, but uImage
      is not built by "make all", so we are often inclined to do
      "make all uImage" to generate DTBs, modules and uImage in a single
      command, but we should notice a pitfall behind it.  In fact,
      "make all uImage" could generate an invalid uImage if it is run with
      the parallel option (-j).
      
      You can reproduce this problem with the following procedure:
      
      [1] First, build "all" and "uImage" separately.
          You will get a valid uImage
      
        $ git clean -f -x -d
        $ export CROSS_COMPILE=<your-tools-prefix>
        $ make -s -j8 ARCH=arm multi_v7_defconfig
        $ make -s -j8 ARCH=arm all
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CHK     include/generated/compile.h
          Kernel: arch/arm/boot/Image is ready
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:21:35 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    6138648 Bytes = 5994.77 kB = 5.85 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:20 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro  6138712 Aug  8 23:21 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:20 arch/arm/boot/zImage
      
      [2] Update some source file(s)
      
        $ touch init/main.c
      
      [3] Then, re-build "all" and "uImage" simultaneously.
          You will get an invalid uImage at random.
      
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CC      init/main.o
          CHK     include/generated/compile.h
          LD      init/built-in.o
          LINK    vmlinux
          LD      vmlinux.o
          MODPOST vmlinux.o
          GEN     .version
          CHK     include/generated/compile.h
          UPD     include/generated/compile.h
          CC      init/version.o
          LD      init/built-in.o
          KSYM    .tmp_kallsyms1.o
          KSYM    .tmp_kallsyms2.o
          LD      vmlinux
          SORTEX  vmlinux
          SYSMAP  System.map
          OBJCOPY arch/arm/boot/Image
          Building modules, stage 2.
          Kernel: arch/arm/boot/Image is ready
          GZIP    arch/arm/boot/compressed/piggy.gzip
          AS      arch/arm/boot/compressed/piggy.gzip.o
          Kernel: arch/arm/boot/Image is ready
          LD      arch/arm/boot/compressed/vmlinux
          GZIP    arch/arm/boot/compressed/piggy.gzip
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:23:14 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    26472 Bytes = 25.85 kB = 0.03 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
          MODPOST 192 modules
          AS      arch/arm/boot/compressed/piggy.gzip.o
          LD      arch/arm/boot/compressed/vmlinux
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:23 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro    26536 Aug  8 23:23 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:23 arch/arm/boot/zImage
      
      Please notice the uImage is extremely small when this issue is
      encountered.  Besides, "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, before and after the uImage log.
      
      The root cause of this is the race condition between zImage and
      uImage.  Actually, uImage depends on zImage, but the dependency
      between the two is only described in arch/arm/boot/Makefile.
      Because arch/arm/boot/Makefile is not included from the top-level
      Makefile, it cannot know the dependency between zImage and uImage.
      
      Consequently, when we run make with the parallel option, Kbuild
      updates vmlinux first, and then two different threads descends into
      the arch/arm/boot/Makefile almost at the same time, one for updating
      zImage and the other for uImage.  While one thread is re-generating
      zImage, the other also tries to update zImage before creating uImage
      on top of that.  zImage is overwritten by the slower thread and then
      uImage is created based on the half-written zImage.
      
      This is the reason why "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, and a broken uImage is created.
      
      The same problem could happen on bootpImage.
      
      This commit adds dependencies among Image, zImage, uImage, and
      bootpImage to arch/arm/Makefile, which is included from the
      top-level Makefile.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3939f334
  37. 15 May, 2015 3 commits