lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A22646AB-300F-4E0A-95DE-06633C2A2986@goldelico.com>
Date:   Tue, 21 May 2019 13:23:36 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        Kees Cook <keescook@...omium.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [BUG v5.2-rc1] ARM build broken

Hi Chris,

> Am 20.05.2019 um 23:21 schrieb Chris Packham <Chris.Packham@...iedtelesis.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@...omium.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ