From: Kees Cook <kees@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Petr Pavlu <petr.pavlu@suse.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Justin Stitt <justinstitt@google.com>,
Marco Elver <elver@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com,
linux-um@lists.infradead.org
Subject: [PATCH v2 0/3] Detect changed compiler dependencies for full rebuild
Date: Fri, 2 May 2025 15:54:12 -0700 [thread overview]
Message-ID: <20250502224512.it.706-kees@kernel.org> (raw)
v2:
- switch from -include to -I with a -D gated include compiler-version.h
v1: https://lore.kernel.org/lkml/20250501193839.work.525-kees@kernel.org/
Hi,
This is my attempt to introduce dependencies that track the various
compiler behaviors that may globally change the build that aren't
represented by either compiler flags nor the compiler version
(CC_VERSION_TEXT). Namely, this is to detect when the contents of a
file the compiler uses changes. We have 3 such situations currently in
the tree:
- If any of the GCC plugins change, we need to rebuild everything that
was built with them, as they may have changed their behavior and those
behaviors may need to be synchronized across all translation units.
(The most obvious of these is the randstruct GCC plugin, but is true
for most of them.)
- If the randstruct seed itself changes (whether for GCC plugins or
Clang), the entire tree needs to be rebuilt since the randomization of
structures may change between compilation units if not.
- If the integer-wrap-ignore.scl file for Clang's integer wrapping
sanitizer changes, a full rebuild is needed as the coverage for wrapping
types may have changed, once again cause behavior differences between
compilation units.
The best way I found to deal with this is to:
- Generate a .h file that is updated when the specific dependencies change.
e.g.: randstruct_hash.h depends on randstruct.seed
- Add a -I argument globally to be able to locate the .h file.
e.g.: -I$(objtree)/scripts/basic
- Add a conditional -D argument for each separate case
e.g.: RANDSTRUCT_CFLAGS += -DRANDSTRUCT
- Include the .h file from compiler-version.h through an #ifdef for the define
e.g.:
#ifdef RANDSTUCT
#include "randstruct_hash.h"
#endif
This means that all targets gain the dependency (via fixdep), but only
when the defines are active, which means they are trivially controlled
by the existing CFLAGS removal mechanisms that are already being used
to turn off each of the above features.
-Kees
Kees Cook (3):
gcc-plugins: Force full rebuild when plugins change
randstruct: Force full rebuild when seed changes
integer-wrap: Force full rebuild when .scl file changes
Makefile | 1 +
arch/um/Makefile | 2 ++
include/linux/compiler-version.h | 10 ++++++++++
include/linux/vermagic.h | 1 -
scripts/Makefile.gcc-plugins | 2 +-
scripts/Makefile.ubsan | 1 +
scripts/basic/Makefile | 20 +++++++++++++++-----
scripts/gcc-plugins/Makefile | 8 ++++++++
8 files changed, 38 insertions(+), 7 deletions(-)
--
2.34.1
next reply other threads:[~2025-05-02 22:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 22:54 Kees Cook [this message]
2025-05-02 22:54 ` [PATCH v2 1/3] gcc-plugins: Force full rebuild when plugins change Kees Cook
2025-05-03 6:12 ` Masahiro Yamada
2025-05-03 17:25 ` Kees Cook
2025-05-02 22:54 ` [PATCH v2 2/3] randstruct: Force full rebuild when seed changes Kees Cook
2025-05-03 6:13 ` Masahiro Yamada
2025-05-03 17:27 ` Kees Cook
2025-05-02 22:54 ` [PATCH v2 3/3] integer-wrap: Force full rebuild when .scl file changes Kees Cook
2025-05-03 9:39 ` [PATCH v2 0/3] Detect changed compiler dependencies for full rebuild Masahiro Yamada
2025-05-03 17:37 ` Kees Cook
2025-05-08 16:44 ` Masahiro Yamada
2025-05-08 16:56 ` Kees Cook
2025-05-08 23:13 ` Masahiro Yamada
2025-05-08 23:59 ` Kees Cook
2025-05-13 14:52 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250502224512.it.706-kees@kernel.org \
--to=kees@kernel.org \
--cc=andreyknvl@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=bigeasy@linutronix.de \
--cc=elver@google.com \
--cc=johannes@sipsolutions.net \
--cc=justinstitt@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=petr.pavlu@suse.com \
--cc=richard@nod.at \
--cc=ryabinin.a.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox