linux-kernel - Re: arm64 kvm built with clang doesn't boot

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: <CAKv+Gu-eBHaoyqO_Vs0ZWahj9pkWWo6kP+9svtMoqcFMjKVd7A@mail.gmail.com>
Date:   Sat, 17 Mar 2018 10:19:12 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Mark Rutland <mark.rutland@....com>,
        Thomas Garnier <thgarnie@...gle.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        kernel-dynamic-tools <kernel-dynamic-tools@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Hackmann <ghackmann@...gle.com>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Stephen Hines <srhines@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        kvmarm <kvmarm@...ts.cs.columbia.edu>,
        Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: arm64 kvm built with clang doesn't boot

(+ Thomas)

On 16 March 2018 at 17:13, Mark Rutland <mark.rutland@....com> wrote:
> On Fri, Mar 16, 2018 at 04:52:08PM +0000, Nick Desaulniers wrote:
>> + Sami (Google), Takahiro (Linaro)
>>
>> Just so I fully understand the problem enough to articulate it, we'd be
>> looking for the compiler to keep the jump tables for speed (I would guess
>> -fno-jump-tables would emit an if-else chain) but only emit relative jumps
>> (not absolute jumps)?
>
> Our main concern is that there is no absolute addressing. If that rules
> out using a relative jump table, that's ok.
>
> We want to avoid the fragility of collecting -f-no-* options as future
> compiler transformations end up introducing absolute addressing.
>

This all comes back to the assumptions made by the compiler when
building PIC/PIE code, i.e., that symbols should be preemptible and
thus all references should be indirected via GOT entries, and that
text relocations should be avoided.

If we had a way to tell the compiler that these concerns do not apply
for us, we could use -fpic/-fpie in the kernel and be done with it.
-fvisibility=hidden *almost* gives us what we need, but in practice,
only the #pragma variant (#pragma GCC visibility push (hidden)) makes
-fpic behave in a sensible way for freestanding builds, and gets rid
of absolute references where possible (note that statically
initialized pointer variables always involve absolute relocations)