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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox