Skip to content
Snippets Groups Projects
  1. Aug 21, 2022
  2. Aug 20, 2022
    • Guru Das Srinagesh's avatar
      scripts/clang-tools: Remove DeprecatedOrUnsafeBufferHandling check · 4be72c1b
      Guru Das Srinagesh authored
      
      This `clang-analyzer` check flags the use of memset(), suggesting a more
      secure version of the API, such as memset_s(), which does not exist in
      the kernel:
      
        warning: Call to function 'memset' is insecure as it does not provide
        security checks introduced in the C11 standard. Replace with analogous
        functions that support length arguments or provides boundary checks such
        as 'memset_s' in case of C11
        [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
      
      Signed-off-by: default avatarGuru Das Srinagesh <quic_gurus@quicinc.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      4be72c1b
    • Nathan Chancellor's avatar
      scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length · 370655bc
      Nathan Chancellor authored
      
      There are no instances of this warning in the tree across several
      difference architectures and configurations. This was added by
      commit 26ea6bb1 ("kbuild, LLVMLinux: Supress warnings unless W=1-3")
      back in 2014, where it might have been necessary, but there are no
      instances of it now so stop disabling it to increase warning coverage
      for clang.
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      370655bc
    • Jiri Slaby's avatar
      kbuild: dummy-tools: pretend we understand __LONG_DOUBLE_128__ · 0df499ea
      Jiri Slaby authored
      
      There is a test in powerpc's Kconfig which checks __LONG_DOUBLE_128__
      and sets CONFIG_PPC_LONG_DOUBLE_128 if it is understood by the compiler.
      
      We currently don't handle it, so this results in PPC_LONG_DOUBLE_128 not
      being in super-config generated by dummy-tools. So take this into
      account in the gcc script and preprocess __LONG_DOUBLE_128__ as "1".
      
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      0df499ea
    • Masahiro Yamada's avatar
      modpost: fix module versioning when a symbol lacks valid CRC · 5b8a9a8f
      Masahiro Yamada authored
      
      Since commit 7b453719 ("kbuild: link symbol CRCs at final link,
      removing CONFIG_MODULE_REL_CRCS"), module versioning is broken on
      some architectures. Loading a module fails with "disagrees about
      version of symbol module_layout".
      
      On such architectures (e.g. ARCH=sparc build with sparc64_defconfig),
      modpost shows a warning, like follows:
      
        WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
        Is "_mcount" prototyped in <asm/asm-prototypes.h>?
      
      Previously, it was a harmless warning (CRC check was just skipped),
      but now wrong CRCs are used for comparison because invalid CRCs are
      just skipped.
      
        $ sparc64-linux-gnu-nm -n vmlinux
          [snip]
        0000000000c2cea0 r __ksymtab__kstrtol
        0000000000c2ceb8 r __ksymtab__kstrtoul
        0000000000c2ced0 r __ksymtab__local_bh_enable
        0000000000c2cee8 r __ksymtab__mcount
        0000000000c2cf00 r __ksymtab__printk
        0000000000c2cf18 r __ksymtab__raw_read_lock
        0000000000c2cf30 r __ksymtab__raw_read_lock_bh
          [snip]
        0000000000c53b34 D __crc__kstrtol
        0000000000c53b38 D __crc__kstrtoul
        0000000000c53b3c D __crc__local_bh_enable
        0000000000c53b40 D __crc__printk
        0000000000c53b44 D __crc__raw_read_lock
        0000000000c53b48 D __crc__raw_read_lock_bh
      
      Please notice __crc__mcount is missing here.
      
      When the module subsystem looks up a CRC that comes after, it results
      in reading out a wrong address. For example, when __crc__printk is
      needed, the module subsystem reads 0xc53b44 instead of 0xc53b40.
      
      All CRC entries must be output for correct index accessing. Invalid
      CRCs will be unused, but are needed to keep the one-to-one mapping
      between __ksymtab_* and __crc_*.
      
      The best is to fix all modpost warnings, but several warnings are still
      remaining on less popular architectures.
      
      Fixes: 7b453719 ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS")
      Reported-by: default avatarmatoro <matoro_mailinglist_kernel@matoro.tk>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Tested-by: default avatarmatoro <matoro_mailinglist_kernel@matoro.tk>
      5b8a9a8f
  3. Aug 16, 2022
    • Andrew Donnellan's avatar
      gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a file · 012e8d20
      Andrew Donnellan authored
      Commit 36d4b36b ("lib/nodemask: inline next_node_in() and
      node_random()") refactored some code by moving node_random() from
      lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
      include random.h, which conditionally defines add_latent_entropy()
      depending on whether the macro LATENT_ENTROPY_PLUGIN is defined.
      
      This broke the build on powerpc, where nodemask.h is indirectly included
      in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that
      is excluded from the latent entropy plugin using
      DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag
      to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN.
      
      This leads to the following:
      
          CC      arch/powerpc/kernel/prom_init.o
        In file included from ./include/linux/nodemask.h:97,
                         from ./include/linux/mmzone.h:17,
                         from ./include/linux/gfp.h:7,
                         from ./include/linux/xarray.h:15,
                         from ./include/linux/radix-tree.h:21,
                         from ./include/linux/idr.h:15,
                         from ./include/linux/kernfs.h:12,
                         from ./include/linux/sysfs.h:16,
                         from ./include/linux/kobject.h:20,
                         from ./include/linux/pci.h:35,
                         from arch/powerpc/kernel/prom_init.c:24:
        ./include/linux/random.h: In function 'add_latent_entropy':
        ./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'?
           25 |         add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy));
              |                                              ^~~~~~~~~~~~~~
              |                                              add_latent_entropy
        ./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in
        make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1
        make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2
        make: *** [Makefile:1855: arch/powerpc] Error 2
      
      Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine
      LATENT_ENTROPY_PLUGIN for files where the plugin is disabled.
      
      Cc: Yury Norov <yury.norov@gmail.com>
      Fixes: 38addce8 ("gcc-plugins: Add latent_entropy plugin")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367
      Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/
      
      
      Reported-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Signed-off-by: default avatarAndrew Donnellan <ajd@linux.ibm.com>
      Reviewed-by: default avatarYury Norov <yury.norov@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com
      012e8d20
  4. Aug 11, 2022
    • Masahiro Yamada's avatar
      riscv/purgatory: Omit use of bin2c · d8357e3b
      Masahiro Yamada authored
      
      The .incbin assembler directive is much faster than bin2c + $(CC).
      
      Do similar refactoring as in commit 4c0f032d ("s390/purgatory:
      Omit use of bin2c").
      
      Please note the .quad directive matches to size_t in C (both 8 byte)
      because the purgatory is compiled only for the 64-bit kernel.
      (KEXEC_FILE depends on 64BIT).
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Link: https://lore.kernel.org/r/20220625223438.835408-2-masahiroy@kernel.org
      
      
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      d8357e3b
    • Linus Torvalds's avatar
      Revert "Makefile.extrawarn: re-enable -Wformat for clang" · 21f9c8a1
      Linus Torvalds authored
      
      This reverts commit 258fafcd.
      
      The clang -Wformat warning is terminally broken, and the clang people
      can't seem to get their act together.
      
      This test program causes a warning with clang:
      
      	#include <stdio.h>
      
      	int main(int argc, char **argv)
      	{
      		printf("%hhu\n", 'a');
      	}
      
      resulting in
      
        t.c:5:19: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat]
                printf("%hhu\n", 'a');
                        ~~~~     ^~~
                        %d
      
      and apparently clang people consider that a feature, because they don't
      want to face the reality of how either C character constants, C
      arithmetic, and C varargs functions work.
      
      The rest of the world just shakes their head at that kind of
      incompetence, and turns off -Wformat for clang again.
      
      And no, the "you should use a pointless cast to shut this up" is not a
      valid answer.  That warning should not exist in the first place, or at
      least be optinal with some "-Wformat-me-harder" kind of option.
      
      [ Admittedly, there's also very little reason to *ever* use '%hh[ud]' in
        C, but what little reason there is is entirely about 'I want to see
        only the low 8 bits of the argument'. So I would suggest nobody ever
        use that format in the first place, but if they do, the clang
        behavious is simply always wrong. Because '%hhu' takes an 'int'. It's
        that simple. ]
      
      Reported-by: default avatarSudip Mukherjee (Codethink) <sudipm.mukherjee@gmail.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      21f9c8a1
  5. Aug 07, 2022
  6. Aug 04, 2022
  7. Aug 03, 2022
    • Tianjia Zhang's avatar
      sign-file: Fix confusing error messages · 1a839502
      Tianjia Zhang authored
      
      When an error occurs, use errx() instead of err() to display the
      error message, because openssl has its own error record. When an
      error occurs, errno will not be changed, while err() displays the
      errno error message. It will cause confusion. For example, when
      CMS_add1_signer() fails, the following message will appear:
      
        sign-file: CMS_add1_signer: Success
      
      errx() ignores errno and does not cause such issue.
      
      Signed-off-by: default avatarTianjia Zhang <tianjia.zhang@linux.alibaba.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      1a839502
    • Masahiro Yamada's avatar
      modpost: use more reliable way to get fromsec in section_rel(a)() · 5419aa2a
      Masahiro Yamada authored
      
      The section name of Rel and Rela starts with ".rel" and ".rela"
      respectively (but, I do not know whether this is specification or
      convention).
      
      For example, ".rela.text" holds relocation entries applied to the
      ".text" section.
      
      So, the code chops the ".rel" or ".rela" prefix to get the name of
      the section to which the relocation applies.
      
      However, I do not like to skip 4 or 5 bytes blindly because it is
      potential memory overrun.
      
      The ELF specification provides a more reliable way to do this.
      
       - The sh_info field holds extra information, whose interpretation
         depends on the section type
      
       - If the section type is SHT_REL or SHT_RELA, the sh_info field holds
         the section header index of the section to which the relocation
         applies.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      5419aa2a
    • Masahiro Yamada's avatar
      modpost: add array range check to sec_name() · 125ed24a
      Masahiro Yamada authored
      
      The section index is always positive, so the argument, secindex, should
      be unsigned.
      
      Also, inserted the array range check.
      
      If sym->st_shndx is a special section index (between SHN_LORESERVE and
      SHN_HIRESERVE), there is no corresponding section header.
      
      For example, if a symbol specifies an absolute value, sym->st_shndx is
      SHN_ABS (=0xfff1).
      
      The current users do not cause the out-of-range access of
      info->sechddrs[], but it is better to avoid such a pitfall.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      125ed24a
    • Masahiro Yamada's avatar
      modpost: refactor get_secindex() · 36b0f0de
      Masahiro Yamada authored
      
      SPECIAL() is only used in get_secindex(). Squash it.
      
      Make the code more readable with more comments.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      36b0f0de
    • Masahiro Yamada's avatar
      kbuild: set EXIT trap before creating temporary directory · dd298656
      Masahiro Yamada authored
      
      Swap the order of 'mkdir' and 'trap' just in case the subshell is
      interrupted between 'mkdir' and 'trap' although the effect might be
      subtle.
      
      This does not intend to make the cleanup perfect. There are more cases
      that miss to remove the tmp directory, for example:
      
       - When interrupted, dash does not invoke the EXIT trap (bash does)
      
       - 'rm' command might be interrupted before removing the directory
      
      I am not addressing all the cases since the tmp directory is harmless
      after all.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      dd298656
    • Masahiro Yamada's avatar
      modpost: remove unused Elf_Sword macro · 7193cda9
      Masahiro Yamada authored
      
      Commit 9ad21c3f ("kbuild: try harder to find symbol names in
      modpost") added Elf_Sword (in a wrong way), but did not use it at all.
      
      BTW, the current code looks weird.
      
      The fix for the 32-bit part would be:
      
          Elf64_Sword  -->  Elf32_Sword
      
      (inconsistet prefix, Elf32_ vs Elf64_)
      
      The fix for the 64-bit part would be:
      
          Elf64_Sxword  -->  Elf64_Sword
      
      (the size is different between Sword and Sxword)
      
      Note:
      
          Elf32_Sword   ==  Elf64_Sword   ==  int32_t
          Elf32_Sxword  ==  Elf64_Sxword  ==  int64_t
      
      Anyway, let's drop unused code instead of fixing it.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      7193cda9
    • Justin Stitt's avatar
      Makefile.extrawarn: re-enable -Wformat for clang · 258fafcd
      Justin Stitt authored
      There's been an ongoing mission to re-enable the -Wformat warning for
      Clang. A previous attempt at enabling the warning showed that there were
      many instances of this warning throughout the codebase. The sheer amount
      of these warnings really polluted builds and thus -Wno-format was added
      to _temporarily_ toggle them off.
      
      After many patches the warning has largely been eradicated for x86,
      x86_64, arm, and arm64 on a variety of configs. The time to enable the
      warning has never been better as it seems for the first time we are
      ahead of them and can now solve them as they appear rather than tackling
      from a backlog.
      
      As to the root cause of this large backlog of warnings, Clang seems to
      pickup on some more nuanced cases of format warnings caused by implicit
      integer conversion as well as default argument promotions from
      printf-like functions.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/378
      
      
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarJustin Stitt <justinstitt@google.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      258fafcd
  8. Aug 02, 2022
  9. Jul 30, 2022
  10. Jul 27, 2022
Loading