Date:   Thu, 8 Dec 2016 20:52:15 -0500
From:   Paul Gortmaker <paul.gortmaker@...driver.com>
To:     Kees Cook <keescook@...gle.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Arnd Bergmann <arnd@...db.de>,
        Randy Dunlap <rdunlap@...radead.org>,
        Olof Johansson <olof@...om.net>,
        Mark Brown <broonie@...nel.org>, info@...nelci.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will.deacon@....com>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Next <linux-next@...r.kernel.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Andrew Donnellan <andrew.donnellan@....ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Laura Abbott <labbott@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: enabling COMPILE_TEST support for GCC plugins in v4.11

On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook <keescook@...gle.com> wrote:
> Hi,
>
> I'd like to get the GCC plugins building under
> allyesconfig/allmodconfig for -next soon (with the intention of
> landing the change in v4.11). Specifically, I intend to revert
> a519167e753e ("gcc-plugins: disable under COMPILE_TEST").

If I recall correctly, I noted that the plugins broke the kernel.org
cross compiler toolchains which led to the above disable.

Has that changed?    People who have been doing tree wide changes
and have been compiling across a bunch of different arch to ensure
their changes don't cause breakage should not be left out in the cold.

If there are newer toolchains that I can download and use in "toaster"
mode, then great.   But I (and many others) don't want to waste a day
trying to make the latest gcc build some obsolete pa-risc architecture
just to support a Kconfig default setting change.

Can you elaborate on the motivation for this change?  At the moment
I see more downsides than advantages.

Thanks,
Paul.
--

>
> Right now the plugins are only supported on x86, arm, and arm64,
> though powerpc may happen in either v4.10 or v4.11 as well. This means
> that the autobuilders for these architectures need to have the "gcc
> plugin development" package installed which contains the GCC headers
> needed for the plugins. For Debian/Ubuntu, this is gcc-$N-plugin-dev
> (and for cross compilers: gcc-$N-plugin-dev-$arch-linux-$abi). For
> Fedora, it is gcc-plugin-devel (though I'm not sure the naming for
> cross compilers). Manual builds of compilers should already have these
> headers installed.
>
> The "noisy" plugin, cyc_complexity, is just an example, and I have
> disabled it (which is pending[1] for v4.10). The remaining ones
> (sancov and latent_entropy) are what I'm hoping to see tested
> tree-wide (with the expectation that more are coming down the road:
> initify, randstruct, structleak, constify, ...)
>
> IIUC, the 0day builder already has the headers installed. I tried to
> look through linux-next to find all the other folks that do
> autobuilding on these architectures; apologies if I've missed anyone.
>
> If you have a moment, applying 215e2aa6c024[1] and reverting
> a519167e753e for an allyesconfig/allmodconfig build should let you
> know if things are working correctly with headers installed. If anyone
> sees any problems, please let me know and I can queue up fixes.
>
> Thanks!
>
> -Kees
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=for-next/gcc-plugins&id=215e2aa6c024d27cdbe88e2ea88cb59dcab588eb
>
> --
> Kees Cook
> Nexus Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists