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]
Message-ID: <CAKv+Gu8TJi8qSWAkL231WhQkWxK+vSQm2tnQn_qN-2wdFaNaEA@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ