From: Kees Cook <keescook@chromium.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Chris Packham <chris.packham@alliedtelesis.co.nz>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Discussions about the Letux Kernel
<letux-kernel@openphoenux.org>
Subject: Re: [BUG v5.2-rc1] ARM build broken
Date: Mon, 20 May 2019 11:53:49 -0700 [thread overview]
Message-ID: <201905201142.CF71598A@keescook> (raw)
In-Reply-To: <D8F987B2-8F41-46DE-B298-89541D7A9774@goldelico.com>
[Adding Chris and Ard, who might have more compiler versions that me...]
On Mon, May 20, 2019 at 07:08:39PM +0200, H. Nikolaus Schaller wrote:
> > Am 20.05.2019 um 17:59 schrieb Kees Cook <keescook@chromium.org>:
> >
> > On Mon, May 20, 2019 at 05:15:02PM +0200, H. Nikolaus Schaller wrote:
> >> Hi,
> >> it seems as if ARM build is broken since ARM now hard enables CONFIG_HAVE_GCC_PLUGINS
> >> which indirectly enables CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK. Compiling this breaks
> >> on my system (Darwin build host) due to conflicts in system headers and Linux headers.
> >>
> >> So how can I turn off all these GCC_PLUGINS?
> >>
> >> The offending patch seems to be
> >>
> >> security: Create "kernel hardening" config area
> >>
> >> especially the new "default y" for GCC_PLUGINS. After removing that line from
> >> scripts/gcc-plugins/Kconfig makes my compile succeed.
> >
> > The intention is to enable it _if_ the plugins are available as part of
> > the build environment. The "default y" on GCC_PLUGINS is mediated by:
> > depends on HAVE_GCC_PLUGINS
>
> HAVE_GCC_PLUGINS has the following description:
>
> An arch should select this symbol if it supports building with
> GCC plugins.
>
> So an ARCH (ARM) selects it unconditionally of the build environment.
>
> > depends on PLUGIN_HOSTCC != ""
>
> Well, we have it set to "g++" for ages and it was not a problem.
> So both conditions are true.
PLUGIN_HOSTCC should have passed the scripts/gcc-plugin.sh test, so
that's correct. And the result (CONFIG_GCC_PLUGINS) is correct: it
doesn't enable or disable anything itself.
What you want is to disable CONFIG_STACKPROTECTOR_PER_TASK, which
is the knob for the feature:
config STACKPROTECTOR_PER_TASK
bool "Use a unique stack canary value for each task"
depends on GCC_PLUGINS && STACKPROTECTOR && SMP && !XIP_DEFLATED_DATA
select GCC_PLUGIN_ARM_SSP_PER_TASK
default y
> Build error:
>
> HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
> In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
> scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
> #define __unused __attribute__((__unused__))
> ^
Does the following patch fix your build? (I assume that line is just a
warning, but if not...)
diff --git a/scripts/gcc-plugins/gcc-common.h b/scripts/gcc-plugins/gcc-common.h
index 552d5efd7cb7..17f06079a712 100644
--- a/scripts/gcc-plugins/gcc-common.h
+++ b/scripts/gcc-plugins/gcc-common.h
@@ -150,8 +150,12 @@ void print_gimple_expr(FILE *, gimple, int, int);
void dump_gimple_stmt(pretty_printer *, gimple, int, int);
#endif
+#ifndef __unused
#define __unused __attribute__((__unused__))
+#endif
+#ifndef __visible
#define __visible __attribute__((visibility("default")))
+#endif
#define DECL_NAME_POINTER(node) IDENTIFIER_POINTER(DECL_NAME(node))
#define DECL_NAME_LENGTH(node) IDENTIFIER_LENGTH(DECL_NAME(node))
> HOSTLLD -shared scripts/gcc-plugins/arm_ssp_per_task_plugin.so - due to target missing
> Undefined symbols for architecture x86_64:
> "gen_reg_rtx(machine_mode)", referenced from:
> (anonymous namespace)::arm_pertask_ssp_rtl_pass::execute() in arm_ssp_per_task_plugin.o
However, this part sounds more like what was fixed with
259799ea5a9a ("gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6")
And maybe some additional fixes for 4.9 are needed?
> This is because CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK became automatically enabled and was never
> before. So the compiler may lack some library search path for building this plugin (which we
> did never miss).
Right -- maybe CONFIG_STACKPROTECTOR_PER_TASK doesn't work with old gcc
4.9.2? I'll see if I can find that compiler version...
--
Kees Cook
next prev parent reply other threads:[~2019-05-20 18:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4DB08A04-D03A-4441-85DE-64A13E6D709C@goldelico.com>
2019-05-20 15:59 ` [BUG v5.2-rc1] ARM build broken Kees Cook
[not found] ` <D8F987B2-8F41-46DE-B298-89541D7A9774@goldelico.com>
2019-05-20 18:53 ` Kees Cook [this message]
2019-05-20 19:35 ` H. Nikolaus Schaller
2019-05-20 20:25 ` Kees Cook
2019-05-20 21:21 ` Chris Packham
2019-05-21 11:23 ` H. Nikolaus Schaller
2019-05-21 20:36 ` Kees Cook
2019-05-22 6:02 ` H. Nikolaus Schaller
2019-06-03 7:46 ` [Letux-kernel] " H. Nikolaus Schaller
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=201905201142.CF71598A@keescook \
--to=keescook@chromium.org \
--cc=ard.biesheuvel@linaro.org \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=hns@goldelico.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yamada.masahiro@socionext.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.