1. 30 Sep, 2018 3 commits
  2. 23 Aug, 2018 1 commit
  3. 31 May, 2018 1 commit
    • Rasmus Villemoes's avatar
      compiler.h: enable builtin overflow checkers and add fallback code · f0907827
      Rasmus Villemoes authored
      This adds wrappers for the __builtin overflow checkers present in gcc
      5.1+ as well as fallback implementations for earlier compilers. It's not
      that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
      b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
      the same. We obviously don't want the wrappers to have different
      semantics depending on $GCC_VERSION, so we also insist on that even when
      using the builtins.
      There are a few problems with the 'a+b < a' idiom for checking for
      overflow: For signed types, it relies on undefined behaviour and is
      not actually complete (it doesn't check underflow;
      e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
      is wrong for all types (signed and unsigned) narrower than
      int. Similarly, when a and b does not have the same type, there are
      subtle cases like
        u32 a;
        if (a + sizeof(foo) < a)
          return -EOVERFLOW;
        a += sizeof(foo);
      where the test is always false on 64 bit platforms. Add to that that it
      is not always possible to determine the types involved at a glance.
      The new overflow.h is somewhat bulky, but that's mostly a result of
      trying to be type-generic, complete (e.g. catching not only overflow
      but also signed underflow) and not relying on undefined behaviour.
      Linus is of course right [1] that for unsigned subtraction a-b, the
      right way to check for overflow (underflow) is "b > a" and not
      "__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
      covered here, and included mostly for completeness.
      So is it worth it? I think it is, if nothing else for the documentation
      value of seeing
        if (check_add_overflow(a, b, &d))
          return -EGOAWAY;
      instead of the open-coded (and possibly wrong and/or incomplete and/or
        if (a+b < a)
          return -EGOAWAY;
      While gcc does recognize the 'a+b < a' idiom for testing unsigned add
      overflow, it doesn't do nearly as good for unsigned multiplication
      (there's also no single well-established idiom). So using
      check_mul_overflow in kcalloc and friends may also make gcc generate
      slightly better code.
      [1] https://lkml.org/lkml/2015/11/2/658
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  4. 21 Apr, 2018 1 commit
  5. 11 Apr, 2018 1 commit
  6. 20 Feb, 2018 1 commit
  7. 07 Feb, 2018 1 commit
  8. 18 Nov, 2017 1 commit
    • Sandipan Das's avatar
      include/linux/compiler-clang.h: handle randomizable anonymous structs · 4ca59b14
      Sandipan Das authored
      The GCC randomize layout plugin can randomize the member offsets of
      sensitive kernel data structures.  To use this feature, certain
      annotations and members are added to the structures which affect the
      member offsets even if this plugin is not used.
      All of these structures are completely randomized, except for task_struct
      which leaves out some of its members.  All the other members are wrapped
      within an anonymous struct with the __randomize_layout attribute.  This is
      done using the randomized_struct_fields_start and
      randomized_struct_fields_end defines.
      When the plugin is disabled, the behaviour of this attribute can vary
      based on the GCC version.  For GCC 5.1+, this attribute maps to
      __designated_init otherwise it is just an empty define but the anonymous
      structure is still present.  For other compilers, both
      randomized_struct_fields_start and randomized_struct_fields_end default
      to empty defines meaning the anonymous structure is not introduced at
      So, if a module compiled with Clang, such as a BPF program, needs to
      access task_struct fields such as pid and comm, the offsets of these
      members as recognized by Clang are different from those recognized by
      modules compiled with GCC.  If GCC 4.6+ is used to build the kernel,
      this can be solved by introducing appropriate defines for Clang so that
      the anonymous structure is seen when determining the offsets for the
      Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
      Signed-off-by: default avatarSandipan Das <sandipan@linux.vnet.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard...
  10. 24 Oct, 2017 1 commit
    • Will Deacon's avatar
      linux/compiler.h: Split into compiler.h and compiler_types.h · d1515582
      Will Deacon authored
      linux/compiler.h is included indirectly by linux/types.h via
      uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h
      -> uapi/linux/stddef.h and is needed to provide a proper definition of
      Unfortunately, compiler.h requires a definition of
      smp_read_barrier_depends() for defining lockless_dereference() and soon
      for defining READ_ONCE(), which means that all
      users of READ_ONCE() will need to include asm/barrier.h to avoid splats
      such as:
         In file included from include/uapi/linux/stddef.h:1:0,
                          from include/linux/stddef.h:4,
                          from arch/h8300/kernel/asm-offsets.c:11:
         include/linux/list.h: In function 'list_empty':
      >> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration]
           smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
      A better alternative is to include asm/barrier.h in linux/compiler.h,
      but this requires a type definition for "bool" on some architectures
      (e.g. x86), which is defined later by linux/types.h. Type "bool" is also
      used directly in linux/compiler.h, so the whole thing is pretty fragile.
      This patch splits compiler.h in two: compiler_types.h contains type
      annotations, definitions and the compiler-specific parts, whereas
      compiler.h #includes compiler-types.h and additionally defines macros
      such as {READ,WRITE.ACCESS}_ONCE().
      uapi/linux/stddef.h and linux/linkage.h are then moved over to include
      linux/compiler_types.h, which fixes the build for h8 and blackfin.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  11. 06 Jul, 2017 1 commit
  12. 11 Jun, 2017 1 commit
  13. 06 Jun, 2017 1 commit
  14. 08 Feb, 2016 1 commit
    • Arnd Bergmann's avatar
      Kbuild: provide a __UNIQUE_ID for clang · b41c29b0
      Arnd Bergmann authored
      The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
      BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
      This adds a copy of the version we use for gcc-4.3 and higher, as the same
      one works with all versions of clang that I could find in svn (2.6 and higher).
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  15. 09 Apr, 2014 1 commit