linux-kernel - Re: Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils

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] [day] [month] [year] [list]

Date:   Thu, 23 Nov 2017 14:26:09 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     nickc@...hat.com,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>, binutils@...rceware.org,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils

On 23 November 2017 at 14:02, Russell King - ARM Linux
<linux@...linux.org.uk> wrote:
> On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
>> Hello Nick & Binutils developers,
>>
>> It would appear that recent changes in the binutils assembler (perhaps
>> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
>> the kernel when compiled in thumb2 mode. We currently do not have a
>> way of working around your breaking changes without adding additional
>> runtime instructions, which isn't acceptable for us. Details are
>> included in the thread below.
>
> Hi Nick,
>
> I have to ask why it was thought a good idea to change the behaviour
> of the assembler's "adr" pseudo-instruction after it's had the existing
> behaviour for such a long time.
>

I think part of the confusion comes from the fact that ADR is no
longer a pseudo-instruction on Thumb2, and can be used to create
cross-section symbol references that are fixed up by the linker (using
a dedicated relocation type)

So before the change, we were in the situation where ADR behaved
differently when used on symbols, depending on whether they were
defined in the same section or not:
- cross section symbol references are fixed up by the linker, and do
take the Thumb bit into account for function symbols,
- local symbol references and label references are not fixed up at
all, regardless of their type annotation.

Note that external symbol references are hardly ever used, given that
they don't work in ARM mode (since it is a pseudo op there), so in the
kernel, we only care about local symbol references and label
references.

After the change, internal symbol references behave differently, but
label references behave the same. So the uniform behavior we care
about and rely on is no longer there, and even worse, we cannot deal
with this in the code because we cannot detect which binutils version
we are using without intrusive workarounds)

-- 
Ard.