lkml.org 
[lkml]   [2019]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG v5.2-rc1] ARM build broken
From
Date
Hi Chris,

> Am 20.05.2019 um 23:21 schrieb Chris Packham <Chris.Packham@alliedtelesis.co.nz>:
>
> On 21/05/19 6:54 AM, Kees Cook wrote:
>> [Adding Chris and Ard, who might have more compiler versions that me...]
>
> Late to the thread but ...
>
>>
>> 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...
>>
>
> My build environment is based on debian-jessie
>
> $ g++ --version
> g++ (Debian 4.9.2-10) 4.9.2
>
> After the fix I posted (which is now commit 259799ea5a9a ("gcc-plugins:
> arm_ssp_per_task_plugin: Fix for older GCC < 6")) I wasn't having any
> more problems.

Ok, fine.

So it indeed looks as if my host-g++ can not properly build gcc-plugins for
the arm cross-gcc. This may come from using Darwin as the build host... So
it may have/use/need a different gcc for building the gcc-plugin for
cross-building the kernel.

Hm. Yes. The cross-toolchain was bootstrapped from scratch. The HOSTCC
comes from Macports and may be a different version. So it is likely that
the HOSTCC from Macports can not build a compatible gcc-plugin for the
cross-gcc.

That seems to be a significant assumption about the build infrastructure
which now became permanently enabled by the "default y" for GCC_PLUGINS.

I am not sure what the right way forward is. Probably for me it is to find
out if I can fix my cross-toolchain. Or if the kernel should better check
if gcc-plugins can really be built, if they are automatically enabled.
Or keep all gcc-plugins disabled until explicitly configured for?

BR and thanks,
Nikolaus

\
 
 \ /
  Last update: 2019-05-21 13:25    [W:0.143 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site