Re: [PATCH v2] objtool: move libelf detection to Kconfig from Makefile

[Kees Cook]

On Mon, Jul 9, 2018 at 9:26 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> I wasn't a part of the -fstack-protector conversation, but I doubt it's
> the same pattern.  We're trying to phase out frame pointers, for several
> reasons.  One big reason is that they cause a general slowdown across
> the entire kernel.

My primary concern with stack-protector was that I wanted to avoid a
disconnect between what was visible in CONFIG_* and how the kernel
actually got built. i.e. a kernel config had
CONFIG_STACKPROTECTOR_STRONG, it was actually built with
-fstack-protector-strong. Having it silently downgrade to
-fstack-protector while keeping CONFIG_STACKPROTECTOR_STRONG would
lead to serious confusion.

The second issue was that I wanted the best stack protector a compiler
supported, and at the time it wasn't possible to do this from kconfig.

Masahiro fixed both of these now. :) (Thank you!)

> Since we switched the x86_64 default to the ORC unwinder, a lot of
> people have switched over.  But this patch will reverse (or at least
> slow down) that trend, because almost nobody has the libelf devel
> packaged installed by default.  So over time, it will effectively make
> frame pointers the default again in many cases.  That's exactly what we
> *don't* want to do.  It will also cause people to accidentally re-enable
> frame pointers when they thought they had ORC.

This is more like the gcc-plugins: kconfig will just not make the
plugin CONFIG_*s visible if the gcc plugin dev package is missing on
the build host. However, having or not having these isn't something
we're trying to phase in or out, so the ORC case is more like how
stack-protector was originally: fail the build if your CONFIG requires
some additional build host package.

What might be interesting is having "make *config" report certain
CONFIG_* failures with helpful text. "WARNING: missing libelf for
CONFIG_ORC..." or "Warning: missing gcc-plugin-dev for
CONFIG_GCC_PLUGINS" etc?

-Kees

-- 
Kees Cook
Pixel Security