linux-hardening - [PATCH RFC] kbuild: Prevent compiler mismatch with external modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 Jan 2021 14:08:02 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>
Cc:     linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        linux-hardening@...r.kernel.org, linux-kbuild@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Justin Forbes <jforbes@...hat.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Miroslav Benes <mbenes@...e.cz>,
        David Laight <David.Laight@...LAB.COM>,
        Jessica Yu <jeyu@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH RFC] kbuild: Prevent compiler mismatch with external modules

When building an external module, if the compiler version differs from
what the kernel was built with, bad things can happen.  Many kernel
features change based on available compiler features.  Silently removing
a compiler-dependent feature in the external module build can cause
unpredictable behavior.  Right now there are no checks to help prevent
such mismatches.

On the other hand, when a user is building an external module against a
distro kernel, the exact compiler version may not be installed, or in
some cases not even released yet.  In fact it's quite common for
external modules to be built with a slightly different version of GCC
than the kernel.

A minor version mismatch should be ok.  User space does it all the time.
New compiler features aren't added within a major version.

Add a check for compiler mismatch, but only check the major version.

Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
---
This is related to the previous RFC I posted:

  https://lkml.kernel.org/r/efe6b039a544da8215d5e54aa7c4b6d1986fc2b0.1611607264.git.jpoimboe@redhat.com

The discussion revealed gaps between developer perceptions and distro
realities with respect to external (out-of-tree) modules...

Backing up a bit, let's please decide on what exactly is supported (or
not supported) with respect to mismatched compiler versions.  Then let's
try to enforce and/or document the decision.

Please stick to technical arguments...

 Makefile | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index b0e4767735dc..f281d2587fa5 100644
--- a/Makefile
+++ b/Makefile
@@ -1744,6 +1744,14 @@ help:
 # no-op for external module builds
 PHONY += prepare modules_prepare

+# External module compiler (major) version must match the kernel
+ifneq ($(shell echo $(CONFIG_GCC_VERSION) | cut -c-2), $(shell $(srctree)/scripts/gcc-version.sh $(CC) | cut -c-2))
+  $(error ERROR: Compiler version mismatch in external module build)
+endif
+ifneq ($(shell echo $(CONFIG_CLANG_VERSION) | cut -c-2), $(shell $(srctree)/scripts/clang-version.sh $(CC) | cut -c-2))
+  $(error ERROR: Compiler version mismatch in external module build)
+endif
+
 endif # KBUILD_EXTMOD

 # Single targets
-- 
2.29.2