1. 16 11月, 2016 1 次提交
    • B
      kbuild: Steal gcc's pie from the very beginning · c6a38553
      Borislav Petkov 提交于
      So Sebastian turned off the PIE for kernel builds but that was too late
      - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc
      options with, say cc-disable-warning, fails:
      
        gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
        ...
        -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp
        /dev/null:1:0: error: code model kernel does not support PIC mode
      
      because that returns an error and we can't disable the warning. For
      example in this case:
      
      KBUILD_CFLAGS   += $(call cc-disable-warning,frame-address,)
      
      which leads to gcc issuing all those warnings again.
      
      So let's turn off PIE/PIC at the earliest possible moment, when we
      declare KBUILD_CFLAGS so that cc-disable-warning picks it up too.
      
      Also, we need the $(call cc-option ...) because -fno-PIE is supported
      since gcc v3.4 and our lowest supported gcc version is 3.2 right now.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: stable@vger.kernel.org
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      c6a38553
  2. 09 11月, 2016 1 次提交
    • S
      kbuild: add -fno-PIE · 8ae94224
      Sebastian Andrzej Siewior 提交于
      Debian started to build the gcc with -fPIE by default so the kernel
      build ends before it starts properly with:
      |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
      
      Also add to KBUILD_AFLAGS due to:
      
      |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
      |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
      
      Tagging it stable so it is possible to compile recent stable kernels as
      well.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      8ae94224
  3. 16 10月, 2016 1 次提交
  4. 13 10月, 2016 1 次提交
    • L
      Disable the __builtin_return_address() warning globally after all · ef6000b4
      Linus Torvalds 提交于
      This affectively reverts commit 377ccbb4 ("Makefile: Mute warning
      for __builtin_return_address(>0) for tracing only") because it turns out
      that it really isn't tracing only - it's all over the tree.
      
      We already also had the warning disabled separately for mm/usercopy.c
      (which this commit also removes), and it turns out that we will also
      want to disable it for get_lock_parent_ip(), that is used for at least
      TRACE_IRQFLAGS.  Which (when enabled) ends up being all over the tree.
      
      Steven Rostedt had a patch that tried to limit it to just the config
      options that actually triggered this, but quite frankly, the extra
      complexity and abstraction just isn't worth it.  We have never actually
      had a case where the warning is actually useful, so let's just disable
      it globally and not worry about it.
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef6000b4
  5. 10 10月, 2016 1 次提交
  6. 03 10月, 2016 1 次提交
  7. 26 9月, 2016 1 次提交
  8. 19 9月, 2016 1 次提交
  9. 12 9月, 2016 1 次提交
  10. 09 9月, 2016 2 次提交
    • N
      kbuild: add arch specific post-link Makefile · fbe6e37d
      Nicholas Piggin 提交于
      Allow architectures to create arch/xxx/Makefile.postlink with targets
      for vmlinux, modules.ko, and clean, which will be invoked after final
      linking of vmlinux and modules.
      
      powerpc will use this to check vmlinux linker relocations for sanity,
      and may use it to fix up alternate instruction patch branch addresses.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      fbe6e37d
    • N
      kbuild: allow archs to select link dead code/data elimination · b67067f1
      Nicholas Piggin 提交于
      Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
      select to build with -ffunction-sections, -fdata-sections, and link
      with --gc-sections. It requires some work (documented) to ensure all
      unreferenced entrypoints are live, and requires toolchain and build
      verification, so it is made a per-arch option for now.
      
      On a random powerpc64le build, this yelds a significant size saving,
      it boots and runs fine, but there is a lot I haven't tested as yet, so
      these savings may be reduced if there are bugs in the link.
      
          text      data        bss        dec   filename
      11169741   1180744    1923176	14273661   vmlinux
      10445269   1004127    1919707	13369103   vmlinux.dce
      
      ~700K text, ~170K data, 6% removed from kernel image size.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      b67067f1
  11. 05 9月, 2016 1 次提交
  12. 29 8月, 2016 1 次提交
  13. 23 8月, 2016 1 次提交
  14. 22 8月, 2016 1 次提交
  15. 15 8月, 2016 1 次提交
  16. 09 8月, 2016 1 次提交
  17. 08 8月, 2016 1 次提交
  18. 03 8月, 2016 1 次提交
    • S
      Makefile: Mute warning for __builtin_return_address(>0) for tracing only · 377ccbb4
      Steven Rostedt 提交于
      With the latest gcc compilers, they give a warning if
      __builtin_return_address() parameter is greater than 0. That is because if
      it is used by a function called by a top level function (or in the case of
      the kernel, by assembly), it can try to access stack frames outside the
      stack and crash the system.
      
      The tracing system uses __builtin_return_address() of up to 2! But it is
      well aware of the dangers that it may have, and has even added precautions
      to protect against it (see the thunk code in arch/x86/entry/thunk*.S)
      
      Linus originally added KBUILD_CFLAGS that would suppress the warning for the
      entire kernel, as simply adding KBUILD_CFLAGS to the tracing directory
      wouldn't work. The tracing directory plays a bit with the CFLAGS and
      requires a little more logic.
      
      This adds that special logic to only suppress the warning for the tracing
      directory. If it is used anywhere else outside of tracing, the warning will
      still be triggered.
      
      Link: http://lkml.kernel.org/r/20160728223043.51996267@grimm.local.homeTested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      377ccbb4
  19. 29 7月, 2016 1 次提交
  20. 28 7月, 2016 2 次提交
    • L
      Disable "frame-address" warning · 124a3d88
      Linus Torvalds 提交于
      Newer versions of gcc warn about the use of __builtin_return_address()
      with a non-zero argument when "-Wall" is specified:
      
        kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’:
        kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address]
           stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
        [ .. repeats a few times for other similar cases .. ]
      
      It is true that a non-zero argument is somewhat dangerous, and we do not
      actually have very many uses of that in the kernel - but the ftrace code
      does use it, and as Stephen Rostedt says:
      
       "We are well aware of the danger of using __builtin_return_address() of
        > 0.  In fact that's part of the reason for having the "thunk" code in
        x86 (See arch/x86/entry/thunk_{64,32}.S).  [..] it adds extra frames
        when tracking irqs off sections, to prevent __builtin_return_address()
        from accessing bad areas.  In fact the thunk_32.S states: 'Trampoline to
        trace irqs off.  (otherwise CALLER_ADDR1 might crash)'."
      
      For now, __builtin_return_address() with a non-zero argument is the best
      we can do, and the warning is not helpful and can end up making people
      miss other warnings for real problems.
      
      So disable the frame-address warning on compilers that need it.
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      124a3d88
    • L
      Disable "maybe-uninitialized" warning globally · 6e8d666e
      Linus Torvalds 提交于
      Several build configurations had already disabled this warning because
      it generates a lot of false positives.  But some had not, and it was
      still enabled for "allmodconfig" builds, for example.
      
      Looking at the warnings produced, every single one I looked at was a
      false positive, and the warnings are frequent enough (and big enough)
      that they can easily hide real problems that you don't notice in the
      noise generated by -Wmaybe-uninitialized.
      
      The warning is good in theory, but this is a classic case of a warning
      that causes more problems than the warning can solve.
      
      If gcc gets better at avoiding false positives, we may be able to
      re-enable this warning.  But as is, we're better off without it, and I
      want to be able to see the *real* warnings.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6e8d666e
  21. 27 7月, 2016 2 次提交
    • K
      kbuild: abort build on bad stack protector flag · c965b105
      Kees Cook 提交于
      Before, the stack protector flag was sanity checked before .config had
      been reprocessed.  This meant the build couldn't be aborted early, and
      only a warning could be emitted followed later by the compiler blowing
      up with an unknown flag.  This has caused a lot of confusion over time,
      so this splits the flag selection from sanity checking and performs the
      sanity checking after the make has been restarted from a reprocessed
      .config, so builds can be aborted as early as possible now.
      
      Additionally moves the x86-specific sanity check to the same location,
      since it suffered from the same warn-then-wait-for-compiler-failure
      problem.
      
      Link: http://lkml.kernel.org/r/20160712223043.GA11664@www.outflux.netSigned-off-by: NKees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c965b105
    • K
      kbuild: Abort build on bad stack protector flag · 228d96c6
      Kees Cook 提交于
      Before, the stack protector flag was sanity checked before .config had
      been reprocessed. This meant the build couldn't be aborted early, and
      only a warning could be emitted followed later by the compiler blowing
      up with an unknown flag. This has caused a lot of confusion over time,
      so this splits the flag selection from sanity checking and performs the
      sanity checking after the make has been restarted from a reprocessed
      .config, so builds can be aborted as early as possible now.
      
      Additionally moves the x86-specific sanity check to the same location,
      since it suffered from the same warn-then-wait-for-compiler-failure
      problem.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      228d96c6
  22. 25 7月, 2016 1 次提交
  23. 22 7月, 2016 1 次提交
    • A
      kbuild: make samples depend on headers_install · ddea05fa
      Arnd Bergmann 提交于
      Olof's build test setup keeps failing to compile arm64 kernels
      because of a toolchain that uses outdated kernel headers:
      
      /work/build/batch/samples/seccomp/bpf-fancy.c:13:27: fatal error: linux/seccomp.h: No such file or directory
      
      This is of course something he could change, but it also indicates
      that others may run into the same problem. Running 'make headers_install'
      avoids the issue by ensuring that the kernel headers are put into
      the $(objdir)/usr/include path before we build the samples.
      
      The same problem happened for the Documentation build in the
      past and was fixed up with commit 8e2faea8 ("Make Documenation
      depend on headers_install"). This adds an identical Makefile dependency
      for the samples/ subdirectory.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      ddea05fa
  24. 19 7月, 2016 2 次提交
    • A
      Kbuild: always prefix objtree in LINUXINCLUDE · 3308b285
      Arnd Bergmann 提交于
      When $(LINUXINCLUDE) is added to the cflags of a target that
      normall doesn't have it (e.g. HOSTCFLAGS), each entry in the
      list is expanded so that we search both $(objtree) and $(srctree),
      which is a bit silly, as we already know which of the two we
      want for each entry in LINUXINCLUDE.
      
      Also, a follow-up patch changes the behavior so we only look in
      $(srctree) for manually added include path, and that breaks finding
      the generated headers.
      
      This adds an explicit $(objtree) for each tree that we want to
      look for generated files.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      3308b285
    • A
      Kbuild: avoid duplicate include path · dc33db7c
      Arnd Bergmann 提交于
      arch/$(hdr-arch)/include/generated/uapi is included twice in the
      header search path, which is unnecessary, so this changes the
      top-level Makefile to drop the second instance by filtering out
      everything from USERINCLUDE that was already part of LINUXINCLUDE.
      
      This should have very little effect other than making the 'make V=1'
      output slightly smaller and making the build time faster by a miniscule
      amount, but it seems to be cleaner.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      dc33db7c
  25. 11 7月, 2016 1 次提交
  26. 04 7月, 2016 1 次提交
  27. 02 7月, 2016 1 次提交
  28. 27 6月, 2016 1 次提交
  29. 23 6月, 2016 1 次提交
  30. 22 6月, 2016 1 次提交
  31. 20 6月, 2016 1 次提交
  32. 12 6月, 2016 1 次提交
  33. 08 6月, 2016 3 次提交
    • M
      kbuild: Initialize exported variables · b36fad65
      Michal Marek 提交于
      The NOSTDINC_FLAGS variable is exported, so it needs to be cleared to
      avoid duplicating its content when running make from within make (e.g.
      in the packaging targets). This became an issue after commit
      9c8fa9bc ("kbuild: fix if_change and friends to consider argument
      order"), which no longer ignores the duplicate options. As Paulo Zanoni
      points out, the LDFLAGS_vmlinux variable has the same problem.
      Reported-by: N"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
      Fixes: 9c8fa9bc ("kbuild: fix if_change and friends to consider argument order")
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      b36fad65
    • E
      Add sancov plugin · 543c37cb
      Emese Revfy 提交于
      The sancov gcc plugin inserts a __sanitizer_cov_trace_pc() call
      at the start of basic blocks.
      
      This plugin is a helper plugin for the kcov feature. It supports
      all gcc versions with plugin support (from gcc-4.5 on).
      It is based on the gcc commit "Add fuzzing coverage support" by Dmitry Vyukov
      (https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=231296).
      Signed-off-by: NEmese Revfy <re.emese@gmail.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      543c37cb
    • E
      GCC plugin infrastructure · 6b90bd4b
      Emese Revfy 提交于
      This patch allows to build the whole kernel with GCC plugins. It was ported from
      grsecurity/PaX. The infrastructure supports building out-of-tree modules and
      building in a separate directory. Cross-compilation is supported too.
      Currently the x86, arm, arm64 and uml architectures enable plugins.
      
      The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory
      there. The plugins compile with these options:
       * -fno-rtti: gcc is compiled with this option so the plugins must use it too
       * -fno-exceptions: this is inherited from gcc too
       * -fasynchronous-unwind-tables: this is inherited from gcc too
       * -ggdb: it is useful for debugging a plugin (better backtrace on internal
          errors)
       * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
       * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
          variable, plugin-version.h)
      
      The infrastructure introduces a new Makefile target called gcc-plugins. It
      supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
      chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
      This script also checks the availability of the included headers in
      scripts/gcc-plugins/gcc-common.h.
      
      The gcc-common.h header contains frequently included headers for GCC plugins
      and it has a compatibility layer for the supported gcc versions.
      
      The gcc-generate-*-pass.h headers automatically generate the registration
      structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.
      
      Note that 'make clean' keeps the *.so files (only the distclean or mrproper
      targets clean all) because they are needed for out-of-tree modules.
      
      Based on work created by the PaX Team.
      Signed-off-by: NEmese Revfy <re.emese@gmail.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      6b90bd4b
  34. 06 6月, 2016 1 次提交