From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: "Li, Xin3" <xin3.li@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"H.Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
llvm@lists.linux.dev, linux-kbuild@vger.kernel.org
Subject: Re: upgrade the orphan section warning to a hard link error
Date: Mon, 17 Oct 2022 12:56:08 -0700 [thread overview]
Message-ID: <Y02zWFxC92VDSpdZ@dev-arch.thelio-3990X> (raw)
In-Reply-To: <202210171230.CC40461C@keescook>
On Mon, Oct 17, 2022 at 12:32:39PM -0700, Kees Cook wrote:
> On Mon, Oct 17, 2022 at 11:26:47AM -0700, Nathan Chancellor wrote:
> > It might be interesting to turn orphan sections into an error if
> > CONFIG_WERROR is set. Perhaps something like the following (FYI, not
> > even compile tested)?
> >
> > diff --git a/Makefile b/Makefile
> > index 0837445110fc..485f47fc2c07 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1119,7 +1119,7 @@ endif
> > # We never want expected sections to be placed heuristically by the
> > # linker. All sections should be explicitly named in the linker script.
> > ifdef CONFIG_LD_ORPHAN_WARN
> > -LDFLAGS_vmlinux += --orphan-handling=warn
> > +LDFLAGS_vmlinux += --orphan-handling=$(if $(CONFIG_WERROR),error,warn)
> > endif
>
> Yes, this is much preferred.
>
> > Outright turning the warning into an error with no escape hatch might be
> > too aggressive, as we have had these warnings triggered by new compiler
> > generated sections, such as in commit 848378812e40 ("vmlinux.lds.h:
> > Handle clang's module.{c,d}tor sections"). Unconditionally breaking the
> > build in these situations is unfortunate but the warnings do need to be
> > dealt with so I think having it error by default with the ability to
> > opt-out is probably worth doing. I do not have a strong opinion though.
>
> Correct; the mandate from Linus (disregarding his addition of
> CONFIG_WERROR for all*config builds), is that we should avoid breaking
> builds. It wrecks bisection, it causes problems across compiler versions,
> etc.
>
> So, yes, only on CONFIG_WERROR=y.
We would probably want to alter the text of CONFIG_WERROR in some manner
to convey this, perhaps like so:
diff --git a/init/Kconfig b/init/Kconfig
index a19314933e54..1fc03e4b2af2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -165,10 +165,12 @@ config WERROR
help
A kernel build should not cause any compiler warnings, and this
enables the '-Werror' (for C) and '-Dwarnings' (for Rust) flags
- to enforce that rule by default.
+ to enforce that rule by default. Certain warnings from other tools
+ such as the linker may be upgraded to errors with this option as
+ well.
- However, if you have a new (or very old) compiler with odd and
- unusual warnings, or you have some architecture with problems,
+ However, if you have a new (or very old) compiler or linker with odd
+ and unusual warnings, or you have some architecture with problems,
you may need to disable this config option in order to
successfully build the kernel.
---
Cheers,
Nathan
next prev parent reply other threads:[~2022-10-17 19:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BN6PR1101MB216105D169D482FC8C539059A8269@BN6PR1101MB2161.namprd11.prod.outlook.com>
2022-10-17 18:26 ` upgrade the orphan section warning to a hard link error Nathan Chancellor
2022-10-17 19:32 ` Kees Cook
2022-10-17 19:56 ` Nathan Chancellor [this message]
2022-10-20 5:17 ` Li, Xin3
2022-10-20 17:53 ` Nathan Chancellor
2022-10-21 1:58 ` Li, Xin3
2022-10-22 3:39 ` Li, Xin3
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=Y02zWFxC92VDSpdZ@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=xin3.li@intel.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