linux-kernel - Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

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, 17 May 2017 16:24:34 -0700
From:   Greg Hackmann <ghackmann@...gle.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Matthias Kaehlcke <mka@...omium.org>
Cc:     Matt Fleming <matt@...eblueprint.co.uk>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Grant Grundler <grundler@...omium.org>,
        Michael Davidson <md@...gle.com>,
        Bernhard Rosenkränzer 
        <Bernhard.Rosenkranzer@...aro.org>
Subject: Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

On 05/11/2017 06:51 AM, Ard Biesheuvel wrote:
[snip]
>>>>> In my opinion, the correct fix would be to make -fpie (as opposed to
>>>>> -fpic) imply hidden visibility, given that PIE executables don't
>>>>> export symbols in the first place, and so the preemption rules do not
>>>>> apply. It is worth a try whether -fpie works as expected in this case
>>>>> on Clang, but the last time I tried it on GCC, it behaved exactly like
>>>>> -fpic.
>>>>
>>>> Thanks a lot for the detailed description and your suggestions!
>>>>
>>>> A clang build with -fpie for the EFI stub succeeds without complaints
>>>> about GOT entries. I will send out an updated patch (with -fpie only
>>>> for clang) later.
>>>>
>>>
>>> Good! I never liked the visibility hack, which is why I never upstreamed it.
>>>
>>> Could you please check how recent GCC behaves?
>>
>> I tried GCC v4.9.4 and v6.3.1, both build the EFI stub with -fpie
>> without errors.
>>
>> Are you suggesting to use -fpie for both clang and GCC? Do you know
>> what the minimum required GCC version is for building an arm64 kernel?
> 
> Yes. Up until now, we have been relying on the position independent
> nature of small model code, but it would be better to specify it
> explicitly, so if -fpie gives us mostly identical code and does not
> need visibility hacks, I would prefer to add it for all compilers and
> not have an exception only for Clang. Note that the same applies to
> the entire kernel when built in KASLR mode, so it would also be good
> to know our options here.
> 
> Arnd, Will, what is the oldest GCC version we claim to support for arm64?
> 

Unfortunately, after looking into this a bit more, -fpie by itself 
doesn't force clang to disable symbol preeemption.  For example when 
building the EFI stub from 4.9 with clang, -fpie gives me a stub that 
crashes with a synchronous exception inside handle_kernel_image().  The 
faulting instruction is a read from __nokaslr that still goes through 
the GOT.

Right now you'll get a usable EFI stub with -fpie anyway, since 
60f38de7a8d4 ("efi/libstub: Unify command line param parsing") masked 
the problem when it moved __nokaslr behind a helper function.  But AIUI 
there's nothing really preventing a similar problem in the future.

You *can* force clang to disable symbol preemption using "-fpie 
-mpie-copy-relocations".  That said, I don't know enough about EFI to 
say whether this is actually appropriate for building the EFI stub.