From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Nicolas Schier <nsc@kernel.org>,
Julian Braha <julianbraha@gmail.com>,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Ricardo Ribalda <ribalda@chromium.org>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH 1/2] kbuild: Move testing of '-mfentry' back to Makefile from Kconfig
Date: Wed, 21 Oct 2026 11:25:54 -0700 [thread overview]
Message-ID: <20261021182554.GA2594500@ax162> (raw)
In-Reply-To: <F643B506-5031-4BEA-8279-199E7E181721@kernel.org>
On Wed, Oct 21, 2026 at 07:44:16AM -0700, Kees Cook wrote:
>
>
> On October 20, 2026 2:52:18 PM PDT, Nathan Chancellor <nathan@kernel.org> wrote:
> >Unlike cc-option in Kbuild, cc-option in Kconfig does not test options
> >with either bit ('-m32' / '-m64') or endianness ('-mbig-endian' /
> >'-mlittle-endian') flags because which flag to use may depend on the
> >result of the configuration stage.
>
> Oooh, yeah... Do we have any silent failures due to this in other places? On x86 I worry we'll see similar problems. Stack protector arg checking comes to mind. I will go see if I can find anything...
I am not sure. I did not look that far, mainly because I thought it
might be hard to audit what is expected vs. unexpected but I guess it
would be easy enough to just dump the result of cc-probe from
scripts/Kconfig.include into a file then look at the tested flag.
On immediate glance across the tree, the s390 Kconfig checks might be
problematic with s390-linux-gcc like '-mfentry' was. Arnd, could the
target for s390 be flipped for the kernel.org GCC toolchains to
s390x-linux-gcc so that '-m64' was the default but the toolchain could
still generate compat code, which seems way more standard for distros?
FWIW, compat support is being killed in the toolchains too, so it feels
like it is worth making this switch even more:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5886bb453a6a010fc218d90c18febf94a1be30d1
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=748bc6a7febf874d84657f538c9d9e3b8153c6e7
The kCFI checks could become problematic if one of the 32/64 or
bi-endian architectures gained asymmetric support in the toolchain but
it was not the target triple that scripts/Makefile.clang uses, but that
feels somewhat unlikely.
Everything else probably does not matter much in practice just due to
lack of use (think 32-bit RISC-V probes when using clang since it has a
64-bit target triple). It does make me a little worried though.
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-10-21 18:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 21:52 [PATCH 0/2] kbuild: Fallout from moving '-mfentry' check into Kconfig stage Nathan Chancellor
2026-10-20 21:52 ` [PATCH 1/2] kbuild: Move testing of '-mfentry' back to Makefile from Kconfig Nathan Chancellor
2026-10-21 14:44 ` Kees Cook
2026-10-21 18:25 ` Nathan Chancellor [this message]
2026-10-20 21:52 ` [PATCH 2/2] scripts/Kconfig.toolchain: Highlight cc-option differences between Kconfig and Kbuild Nathan Chancellor
2026-10-20 23:48 ` [PATCH 0/2] kbuild: Fallout from moving '-mfentry' check into Kconfig stage Ricardo Ribalda
2026-10-21 13:31 ` Lorenzo Stoakes (ARM)
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=20261021182554.GA2594500@ax162 \
--to=nathan@kernel.org \
--cc=julianbraha@gmail.com \
--cc=kees@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=nsc@kernel.org \
--cc=ribalda@chromium.org \
/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
all inboxes | Powered by JetHome®