1. 22 Jul, 2018 1 commit
  2. 15 Jul, 2018 1 commit
  3. 12 Jul, 2018 1 commit
  4. 08 Jul, 2018 1 commit
  5. 06 Jul, 2018 1 commit
  6. 01 Jul, 2018 1 commit
  7. 28 Jun, 2018 1 commit
  8. 24 Jun, 2018 1 commit
  9. 16 Jun, 2018 1 commit
  10. 14 Jun, 2018 1 commit
    • Linus Torvalds's avatar
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds authored
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 11 Jun, 2018 1 commit
    • Masahiro Yamada's avatar
      kcov: test compiler capability in Kconfig and correct dependency · 5aadfdeb
      Masahiro Yamada authored
      As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
      be used with care - it forces a lower limit of another symbol, ignoring
      the dependency.  Currently, KCOV can select GCC_PLUGINS even if arch
      does not select HAVE_GCC_PLUGINS.  This could cause the unmet direct
      Now that Kconfig can test compiler capability, let's handle this in a
      more sophisticated way.
      There are two ways to enable KCOV; use the compiler that natively
      supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
      the compiler has ability to build GCC plugins.  Hence, the correct
      dependency for KCOV is:
        depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
      You do not need to build the SANCOV plugin if the compiler already
      supports -fsanitize-coverage=trace-pc.  Hence, the select should be:
      With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
      scripts/Makefile.gcc-plugins can be cleaner.
      I also cleaned up Kconfig and scripts/Makefile.kcov as well.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
  12. 08 Jun, 2018 2 commits
    • Masahiro Yamada's avatar
      stack-protector: test compiler capability in Kconfig and drop AUTO mode · 2a61f474
      Masahiro Yamada authored
      Move the test for -fstack-protector(-strong) option to Kconfig.
      If the compiler does not support the option, the corresponding menu
      is automatically hidden.  If STRONG is not supported, it will fall
      back to REGULAR.  If REGULAR is not supported, it will be disabled.
      This means, AUTO is implicitly handled by the dependency solver of
      Kconfig, hence removed.
      I also turned the 'choice' into only two boolean symbols.  The use of
      'choice' is not a good idea here, because all of all{yes,mod,no}config
      would choose the first visible value, while we want allnoconfig to
      disable as many features as possible.
      X86 has additional shell scripts in case the compiler supports those
      options, but generates broken code.  I added CC_HAS_SANE_STACKPROTECTOR
      to test this.  I had to add -m32 to gcc-x86_32-has-stack-protector.sh
      to make it work correctly.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
    • Masahiro Yamada's avatar
      kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE · 315bab4e
      Masahiro Yamada authored
      Commit 21c54b77 ("kconfig: show compiler version text in the top
      comment") was intended to detect the compiler upgrade, but Geert
      reported a breakage on the m68k build.
      The compiler upgrade is detected by the change of the environment
      variable, CC_VERSION_TEXT, which contains the first line of the output
      from $(CC) --version.  Currently, this works well when CROSS_COMPILE
      is given via the environment variable or the Make command line.
      However, some architectures such as m68k can specify CROSS_COMPILE
      from arch/$(SRCARCH)/Makefile as well.  In this case, "make ARCH=m68k"
      ends up with endless syncconfig loop.
        $ make ARCH=m68k defconfig
        *** Default configuration is based on 'multi_defconfig'
        # configuration written to .config
        $ make ARCH=m68k
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
      Things are happening like this:
      Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
      is set, it contains the host compiler version in the defconfig phase.
      To create or update auto.conf, the following line is triggered:
      include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
              $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
      This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
      included.  CROSS_COMPILE is set to a m68k toolchain prefix and
      exported to the recursed Make.  Then, syncconfig is invoked with
      the target compiler version in CC_VERSION_TEXT.
      The Make will restart because auto.conf and auto.conf.cmd have been
      updated.  At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
      is set to the host compiler version again.  Then, syncconfig is
      triggered due to the change of CC_VERSION_TEXT.  This loop continues
      To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
      arch/$(SRCARCH)/Makefile.  Setting it earlier is OK as long as it is
      defined by using the '=' operator instead of ':='.
      For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
      descends into scripts/kconfig/, so it contains the target compiler
      version correctly.
      include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
      so it must be included after arch/$(SRCARCH)/Makefile.
      Fixes: 21c54b77 ("kconfig: show compiler version text in the top comment")
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
  13. 05 Jun, 2018 1 commit
  14. 03 Jun, 2018 1 commit
  15. 01 Jun, 2018 1 commit
  16. 29 May, 2018 2 commits
  17. 28 May, 2018 5 commits
    • Masahiro Yamada's avatar
      kconfig: show compiler version text in the top comment · 21c54b77
      Masahiro Yamada authored
      The kernel configuration phase is now tightly coupled with the compiler
      in use.  It will be nice to show the compiler information in Kconfig.
      The compiler information will be displayed like this:
        $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
        scripts/kconfig/conf  --oldaskconfig Kconfig
        * Linux/arm64 4.16.0-rc1 Kernel Configuration
        * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
        * General setup
        Compile also drivers which will not load (COMPILE_TEST) [N/y/?]
      If you use GUI methods such as menuconfig, it will be displayed in the
      top menu.
      This is simply implemented by using the 'comment' statement.  So, it
      will be saved into the .config file as well.
      This commit has a very important meaning.  If the compiler is upgraded,
      Kconfig must be re-run since different compilers have different sets
      of supported options.
      All referenced environments are written to include/config/auto.conf.cmd
      so that any environment change triggers syncconfig, and prompt the user
      to input new values if needed.
      With this commit, something like follows will be added to
        ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011"
        include/config/auto.conf: FORCE
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    • Masahiro Yamada's avatar
      kconfig: replace $(UNAME_RELEASE) with function call · 2972666a
      Masahiro Yamada authored
      Now that 'shell' function is supported, this can be self-contained in
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
    • Masahiro Yamada's avatar
      kconfig: reference environment variables directly and remove 'option env=' · 104daea1
      Masahiro Yamada authored
      To get access to environment variables, Kconfig needs to define a
      symbol using "option env=" syntax.  It is tedious to add a symbol entry
      for each environment variable given that we need to define much more
      such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
      in Kconfig.
      Adding '$' for symbol references is grammatically inconsistent.
      Looking at the code, the symbols prefixed with 'S' are expanded by:
       - conf_expand_value()
         This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
       - sym_expand_string_value()
         This is used to expand strings in 'source' and 'mainmenu'
      All of them are fixed values independent of user configuration.  So,
      they can be changed into the direct expansion instead of symbols.
      This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
      'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.
      sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
      should be replaced with an environment variable.
      ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
      without '$' prefix.
      The new syntax is addicted by Make.  The variable reference needs
      parentheses, like $(FOO), but you can omit them for single-letter
      variables, like $F.  Yet, in Makefiles, people tend to use the
      parenthetical form for consistency / clarification.
      At this moment, only the environment variable is supported, but I will
      extend the concept of 'variable' later on.
      The variables are expanded in the lexer so we can simplify the token
      handling on the parser side.
      For example, the following code works.
      [Example code]
        config MY_TOOLCHAIN_LIST
                default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
        $ make -s alldefconfig && tail -n 1 .config
        CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    • Masahiro Yamada's avatar
      kbuild: remove CONFIG_CROSS_COMPILE support · f1089c92
      Masahiro Yamada authored
      Kbuild provides a couple of ways to specify CROSS_COMPILE:
      [1] Command line
      [2] Environment
      [3] arch/*/Makefile (only some architectures)
      [4] is problematic for the compiler capability tests in Kconfig.
      CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
      'make menuconfig', etc.  It means, the compiler options would have
      to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.
      To avoid complexity and performance issues, I'd like to evaluate
      the shell commands statically, i.e. only parsing Kconfig files.
      I guess the majority is [1] or [2].  Currently, there are only
      5 defconfig files that specify CONFIG_CROSS_COMPILE.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    • Masahiro Yamada's avatar
      kbuild: remove kbuild cache · e08d6de4
      Masahiro Yamada authored
      The kbuild cache was introduced to remember the result of shell
      commands, some of which are expensive to compute, such as
      $(call cc-option,...).
      However, this turned out not so clever as I had first expected.
      Actually, it is problematic.  For example, "$(CC) -print-file-name"
      is cached.  If the compiler is updated, the stale search path causes
      build error, which is difficult to figure out.  Another problem
      scenario is cache files could be touched while install targets are
      running under the root permission.  We can patch them if desired,
      but the build infrastructure is getting uglier and uglier.
      Now, we are going to move compiler flag tests to the configuration
      phase.  If this is completed, the result of compiler tests will be
      naturally cached in the .config file.  We will not have performance
      issues of incremental building since this testing only happens at
      Kconfig time.
      To start this work with a cleaner code base, remove the kbuild
      cache first.
      Revert the following commits:
      Commit 9a234a2e ("kbuild: create directory for make cache only when necessary")
      Commit e17c400a ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
      Commit 4e562071 ("kbuild: Cache a few more calls to the compiler")
      Commit 3298b690 ("kbuild: Add a cache for generated variables")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
  18. 27 May, 2018 1 commit
  19. 20 May, 2018 1 commit
  20. 17 May, 2018 4 commits
  21. 13 May, 2018 1 commit
  22. 07 May, 2018 1 commit
  23. 29 Apr, 2018 1 commit
  24. 23 Apr, 2018 1 commit
  25. 16 Apr, 2018 1 commit
  26. 07 Apr, 2018 4 commits
    • Masahiro Yamada's avatar
      kbuild: use -fmacro-prefix-map to make __FILE__ a relative path · a73619a8
      Masahiro Yamada authored
      The __FILE__ macro is used everywhere in the kernel to locate the file
      printing the log message, such as WARN_ON(), etc.  If the kernel is
      built out of tree, this can be a long absolute path, like this:
        WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...
      This is because Kbuild runs in the objtree instead of the srctree,
      then __FILE__ is expanded to a file path prefixed with $(srctree)/.
      Commit 9da0763b ("kbuild: Use relative path when building in a
      subdir of the source tree") improved this to some extent; $(srctree)
      becomes ".." if the objtree is a child of the srctree.
      For other cases of out-of-tree build, __FILE__ is still the absolute
      path.  It also means the kernel image depends on where it was built.
      A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
      If your compiler supports it, __FILE__ is the relative path from the
      srctree regardless of O= option.  This provides more readable log and
      more reproducible builds.
      Please note __FILE__ is always an absolute path for external modules.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      kbuild: rename *-asn1.[ch] to *.asn1.[ch] · 4fa8bc94
      Masahiro Yamada authored
      Our convention is to distinguish file types by suffixes with a period
      as a separator.
      *-asn1.[ch] is a different pattern from other generated sources such
      as *.lex.c, *.tab.[ch], *.dtb.S, etc.  More confusing, files with
      '-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in
      Rename generated files to *.asn1.[ch] for consistency.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      kbuild: clean up *-asn1.[ch] patterns from top-level Makefile · 3ca3273e
      Masahiro Yamada authored
      Clean up these patterns from the top Makefile to omit 'clean-files'
      in each Makefile.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile · 9a8dfb39
      Masahiro Yamada authored
      Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers,
      respectively.  Clean them up globally from the top Makefile.
      Some of the final host programs those lexer/parser are linked into
      are necessary for building external modules, but the intermediates
      are unneeded.  They can be cleaned away by 'make clean' instead of
      'make mrproper'.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarFrank Rowand <frowand.list@gmail.com>
  27. 01 Apr, 2018 1 commit
  28. 25 Mar, 2018 1 commit