[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200908205612.GA1060586@google.com>
Date: Tue, 8 Sep 2020 13:56:12 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
clang-built-linux@...glegroups.com,
kernel-hardening@...ts.openwall.com, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
x86@...nel.org
Subject: Re: [PATCH v2 11/28] kbuild: lto: postpone objtool
On Thu, Sep 03, 2020 at 03:19:43PM -0700, Kees Cook wrote:
> On Thu, Sep 03, 2020 at 01:30:36PM -0700, Sami Tolvanen wrote:
> > With LTO, LLVM bitcode won't be compiled into native code until
> > modpost_link, or modfinal for modules. This change postpones calls
> > to objtool until after these steps.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@...gle.com>
>
> For a "fail fast" style of building, it makes sense to have objtool run
> as early as possible, so it makes sense to keep the current behavior in
> non-LTO mode. I do wonder, though, if there is a real benefit to having
> "fail fast" case. I imagine a lot of automated builds are using
> --keep-going with make, and actually waiting until the end to do the
> validation means more code will get build-tested before objtool rejects
> the results. *shrug*
>
> > ---
> > arch/Kconfig | 2 +-
> > scripts/Makefile.build | 2 ++
> > scripts/Makefile.modfinal | 24 ++++++++++++++++++++++--
> > scripts/link-vmlinux.sh | 23 ++++++++++++++++++++++-
> > 4 files changed, 47 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 71392e4a8900..7a418907e686 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -599,7 +599,7 @@ config LTO_CLANG
> > depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> > depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> > depends on ARCH_SUPPORTS_LTO_CLANG
> > - depends on !FTRACE_MCOUNT_RECORD
> > + depends on HAVE_OBJTOOL_MCOUNT || !(X86_64 && DYNAMIC_FTRACE)
> > depends on !KASAN
> > depends on !GCOV_KERNEL
> > select LTO
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index c348e6d6b436..b8f1f0d65a73 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -218,6 +218,7 @@ cmd_record_mcount = $(if $(findstring $(strip $(CC_FLAGS_FTRACE)),$(_c_flags)),
> > endif # USE_RECORDMCOUNT
> >
> > ifdef CONFIG_STACK_VALIDATION
> > +ifndef CONFIG_LTO_CLANG
> > ifneq ($(SKIP_STACK_VALIDATION),1)
> >
> > __objtool_obj := $(objtree)/tools/objtool/objtool
> > @@ -253,6 +254,7 @@ objtool_obj = $(if $(patsubst y%,, \
> > $(__objtool_obj))
> >
> > endif # SKIP_STACK_VALIDATION
> > +endif # CONFIG_LTO_CLANG
> > endif # CONFIG_STACK_VALIDATION
> >
> > # Rebuild all objects when objtool changes, or is enabled/disabled.
> > diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> > index 1005b147abd0..909bd509edb4 100644
> > --- a/scripts/Makefile.modfinal
> > +++ b/scripts/Makefile.modfinal
> > @@ -34,10 +34,30 @@ ifdef CONFIG_LTO_CLANG
> > # With CONFIG_LTO_CLANG, reuse the object file we compiled for modpost to
> > # avoid a second slow LTO link
> > prelink-ext := .lto
> > -endif
> > +
> > +# ELF processing was skipped earlier because we didn't have native code,
> > +# so let's now process the prelinked binary before we link the module.
> > +
> > +ifdef CONFIG_STACK_VALIDATION
> > +ifneq ($(SKIP_STACK_VALIDATION),1)
> > +cmd_ld_ko_o += \
> > + $(objtree)/tools/objtool/objtool \
> > + $(if $(CONFIG_UNWINDER_ORC),orc generate,check) \
> > + --module \
> > + $(if $(CONFIG_FRAME_POINTER),,--no-fp) \
> > + $(if $(CONFIG_GCOV_KERNEL),--no-unreachable,) \
> > + $(if $(CONFIG_RETPOLINE),--retpoline,) \
> > + $(if $(CONFIG_X86_SMAP),--uaccess,) \
> > + $(if $(USE_OBJTOOL_MCOUNT),--mcount,) \
> > + $(@:.ko=$(prelink-ext).o);
> > +
> > +endif # SKIP_STACK_VALIDATION
> > +endif # CONFIG_STACK_VALIDATION
>
> I wonder if objtool_args could be reused here instead of having two
> places to keep in sync? It looks like that might mean moving things
> around a bit before this patch, since I can't quite see if
> Makefile.build's variables are visible to Makefile.modfinal?
It doesn't look like they are. I suppose we could move objtool_args to
Makefile.lib. Masahiro, any thoughts?
Sami
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
