linux-kernel - Re: [BUG v5.2-rc1] ARM build broken

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]

Date:   Wed, 22 May 2019 08:02:17 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        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 Kees,

> Am 21.05.2019 um 22:36 schrieb Kees Cook <keescook@...omium.org>:
> 
> On Tue, May 21, 2019 at 01:23:36PM +0200, H. Nikolaus Schaller wrote:
>>>>> 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
> 
> Are you seeing this error still, even after the fix I sent?

Yes.

> Perhaps I
> misunderstood that it solves all of the build issues?

There was a compiler warning and a linker error. The patch only fixes the compiler warning.

> 
>> 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?
> 
> Right, that seems to be the case: it seems that the gcc plugin build
> sanity detection script is not working in your environment. You can
> check it directly.
> 
> Here's the bits from the Kconfig (though I added --show-error for you,
> in case that's useful):
> 
> preferred-plugin-hostcc := $(if-success,[ $(gcc-version) -ge 40800 ],$(HOSTCXX),$(HOSTCC))
> 
> scripts/gcc-plugin.sh --show-error "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)"
> 
> I'm not sure what your kernel build picks for gcc-version, HOSTCXX
> HOSTCC and CC...

It turns out that HOSTCC and HOSTCXX are a gcc-4.9.4 installed through MacPorts.
And CC is the self-bootstrapped cross-gcc-4.9.2 toolchain for arm.

The problem is likely that they do not know of each other, i.e. the required
include and library search paths. Therefore HOSTCXX can't build plugins compatible
with CC because it does not even know its existence. Or the gcc-4.9.4 from MacPorts
is missing the gcc-plugin library to link against which would explain the HOSTLLD
error message as well.

This seems not to be found by the tests of scripts/gcc-plugin.sh. I have to check why...

BR and thanks,
Nikolaus