Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Andrew Donnellan]

On 13/05/16 09:57, Emese Revfy wrote:
> This patch allows to build the whole kernel with GCC plugins. It was ported from
> grsecurity/PaX. The infrastructure supports building out-of-tree modules and
> building in a separate directory. Cross-compilation is supported too.
> Currently the x86, arm, arm64 and uml architectures enable plugins.
>
> The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory
> there. The plugins compile with these options:
>   * -fno-rtti: gcc is compiled with this option so the plugins must use it too
>   * -fno-exceptions: this is inherited from gcc too
>   * -fasynchronous-unwind-tables: this is inherited from gcc too
>   * -ggdb: it is useful for debugging a plugin (better backtrace on internal
>      errors)
>   * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
>   * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
>      variable, plugin-version.h)
>
> The infrastructure introduces a new Makefile target called gcc-plugins. It
> supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
> chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
> This script also checks the availability of the included headers in
> scripts/gcc-plugins/gcc-common.h.
>
> The gcc-common.h header contains frequently included headers for GCC plugins
> and it has a compatibility layer for the supported gcc versions.
>
> The gcc-generate-*-pass.h headers automatically generate the registration
> structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.
>
> Note that 'make clean' keeps the *.so files (only the distclean or mrproper
> targets clean all) because they are needed for out-of-tree modules.
>
> The arm and arm64 architectures were tested by David Brown <david.brown@linaro.org>.
>
> Signed-off-by: Emese Revfy <re.emese@gmail.com>

I've done some basic sanity testing on powerpc with the cyclomatic 
complexity plugin (with LE native + cross-compilers) and it seems to 
work with the patch below.

Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a18a0dc..0cfed5b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -97,6 +97,7 @@ config PPC
         select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL
         select HAVE_FUNCTION_TRACER
         select HAVE_FUNCTION_GRAPH_TRACER
+       select HAVE_GCC_PLUGINS
         select SYSCTL_EXCEPTION_TRACE
         select ARCH_WANT_OPTIONAL_GPIOLIB
         select VIRT_TO_BUS if !PPC64

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Emese Revfy]

> I've done some basic sanity testing on powerpc with the cyclomatic 
> complexity plugin (with LE native + cross-compilers) and it seems to 
> work with the patch below.
> 
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a18a0dc..0cfed5b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -97,6 +97,7 @@ config PPC
>          select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL
>          select HAVE_FUNCTION_TRACER
>          select HAVE_FUNCTION_GRAPH_TRACER
> +       select HAVE_GCC_PLUGINS
>          select SYSCTL_EXCEPTION_TRACE
>          select ARCH_WANT_OPTIONAL_GPIOLIB
>          select VIRT_TO_BUS if !PPC64

Hi,

Did you test the plugins with all gcc versions (4.5-6)?

-- 
Emese

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Andrew Donnellan]

On 18/05/16 20:33, Emese Revfy wrote:
> Did you test the plugins with all gcc versions (4.5-6)?

No, I tested with 4.8 and 5.2 as those are the toolchains I have on hand 
- I'll try to test with the rest of 4.5 - 6.1.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Michael Ellerman]

On Wed, 2016-05-18 at 12:33 +0200, Emese Revfy wrote:

> > I've done some basic sanity testing on powerpc with the cyclomatic 
> > complexity plugin (with LE native + cross-compilers) and it seems to 
> > work with the patch below.
> > 
> > Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> > 
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index a18a0dc..0cfed5b 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -97,6 +97,7 @@ config PPC
> >          select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL
> >          select HAVE_FUNCTION_TRACER
> >          select HAVE_FUNCTION_GRAPH_TRACER
> > +       select HAVE_GCC_PLUGINS
> >          select SYSCTL_EXCEPTION_TRACE
> >          select ARCH_WANT_OPTIONAL_GPIOLIB
> >          select VIRT_TO_BUS if !PPC64
> 
> Hi,
> 
> Did you test the plugins with all gcc versions (4.5-6)?

What's the concern about gcc versions? Just not breaking the build on old
compilers?

I'm pretty sure powerpc big endian still builds with gcc 4.4.

However if Andrew's only tested on little endian, then that select should be
guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9.

cheers

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Andrew Donnellan]

On 19/05/16 16:22, Michael Ellerman wrote:
>> Did you test the plugins with all gcc versions (4.5-6)?
>
> What's the concern about gcc versions? Just not breaking the build on old
> compilers?
> I'm pretty sure powerpc big endian still builds with gcc 4.4.

gcc's plugin support only landed in 4.5, so we don't care about <=4.4.

> However if Andrew's only tested on little endian, then that select should be
> guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9.

I'm going to give BE a test too just to be sure.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[PaX Team]

On 19 May 2016 at 16:22, Michael Ellerman wrote:

> On Wed, 2016-05-18 at 12:33 +0200, Emese Revfy wrote:
> > Did you test the plugins with all gcc versions (4.5-6)?
> 
> What's the concern about gcc versions? Just not breaking the build on old
> compilers?

the earlier plugin capable gcc versions used to install gcc headers in a somewhat
ad-hoc manner resulting in compile time breakage for plugins and since some of
those potentially missing headers are target specific, each target arch should
be verified before enabling plugin support on them. things have much improved with
gcc 5 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176) though there's still
an occasional missing header but with wider use of plugins they will hopefully be
discovered earlier now. perhaps linux-arch should be cc'ed on the plugin infrastructure
so that arch maintainers are aware of this?

> I'm pretty sure powerpc big endian still builds with gcc 4.4.
> 
> However if Andrew's only tested on little endian, then that select should be
> guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9.

i guess that's part of the target tuple so in general arch maintainers should test
the target tuples used on their arch with all the supported gcc versions (speaking
of CC, not HOSTCC/HOSTCXX).

cheers,
 PaX Team

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Andrew Donnellan]

On 19/05/16 18:24, PaX Team wrote:
> the earlier plugin capable gcc versions used to install gcc headers in a somewhat
> ad-hoc manner resulting in compile time breakage for plugins and since some of
> those potentially missing headers are target specific, each target arch should
> be verified before enabling plugin support on them. things have much improved with
> gcc 5 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176) though there's still
> an occasional missing header but with wider use of plugins they will hopefully be
> discovered earlier now. perhaps linux-arch should be cc'ed on the plugin infrastructure
> so that arch maintainers are aware of this?

Upon further testing it does seem we've got header issues as well as 
hitting a segfault on 4.7.0. Looking into it further...

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure

[Michael Ellerman]

On Thu, 2016-05-19 at 10:24 +0200, PaX Team wrote:
> On 19 May 2016 at 16:22, Michael Ellerman wrote:
> > On Wed, 2016-05-18 at 12:33 +0200, Emese Revfy wrote:
> > > Did you test the plugins with all gcc versions (4.5-6)?
> > 
> > What's the concern about gcc versions? Just not breaking the build on old
> > compilers?
> 
> the earlier plugin capable gcc versions used to install gcc headers in a somewhat
> ad-hoc manner resulting in compile time breakage for plugins and since some of
> those potentially missing headers are target specific, each target arch should
> be verified before enabling plugin support on them. things have much improved with
> gcc 5 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176) though there's still
> an occasional missing header but with wider use of plugins they will hopefully be
> discovered earlier now. 

OK thanks.

> perhaps linux-arch should be cc'ed on the plugin infrastructure
> so that arch maintainers are aware of this?

linux-arch is still fairly high traffic, so it's no guarantee arch maintainers
will see it, but it's probably worth a try.

> > I'm pretty sure powerpc big endian still builds with gcc 4.4.
> > 
> > However if Andrew's only tested on little endian, then that select should be
> > guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9.
> 
> i guess that's part of the target tuple so in general arch maintainers should test
> the target tuples used on their arch with all the supported gcc versions (speaking
> of CC, not HOSTCC/HOSTCXX).

Yeah. I think we'll probably enable it gradually as folks get time to test it.
ie. ppc64le first, then ppc64 (BE), and then 32-bit if someone is interested.

cheers