linux-kernel - Re: [PATCH] arm64: disable patchable function entry on big-endian clang builds

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: <20200506154556.5fsxzs3vbfwixggd@google.com>
Date:   Wed, 6 May 2020 08:45:56 -0700
From:   Fangrui Song <maskray@...gle.com>
To:     Nathan Chancellor <natechancellor@...il.com>,
        Ard Biesheuvel <ardb@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>, Torsten Duwe <duwe@....de>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Amit Daniel Kachhap <amit.kachhap@....com>,
        Torsten Duwe <duwe@...e.de>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Julien Thierry <jthierry@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Marc Zyngier <maz@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Alexandre Ghiti <alex@...ti.fr>,
        Kristina Martsenko <kristina.martsenko@....com>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Steve Capper <steve.capper@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] arm64: disable patchable function entry on big-endian
 clang builds

On 2020-05-06, Nathan Chancellor wrote:
>On Wed, May 06, 2020 at 12:22:58PM +0200, Arnd Bergmann wrote:
>> On Wed, May 6, 2020 at 5:45 AM Nathan Chancellor
>> <natechancellor@...il.com> wrote:
>> > On Tue, May 05, 2020 at 07:42:43PM +0200, Torsten Duwe wrote:
>> > > On Tue, 5 May 2020 15:25:56 +0100 Mark Rutland <mark.rutland@....com> wrote:
>> > > > On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote:
>> > > > This practically rules out a BE distro kernel with things like PAC,
>> > > > which isn't ideal.
>> >
>> > To be fair, are there big endian AArch64 distros?
>> >
>> > https://wiki.debian.org/Arm64Port: "There is also a big-endian version
>> > of the architecture/ABI: aarch64_be-linux-gnu but we're not supporting
>> > that in Debian (so there is no corresponding Debian architecture name)
>> > and hopefully will never have to. Nevertheless you might want to check
>> > for this by way of completeness in upstream code."
>> >
>> > OpenSUSE and Fedora don't appear to have support for big endian.
>>
>> I don't think any of the binary distros ship big endian ARM64. There are
>> a couple of users that tend to build everything from source using Yocto
>> or similar embedded distros, but as far as I can tell this is getting less
>> common over time as applications get ported to be compatible with
>> big-endian, or get phased out and replaced by code running on regular
>> little-endian systems.
>>
>> The users we see today are likely in telco, military or aerospace
>> settings (While earth is mostly little-endian these days, space is
>> definitely big-endian) that got ported from big-endian hardware, but
>> often with a high degree of customization and long service life.
>
>Ah yes, that makes sense, thanks for the information and background.
>Helps orient myself for the future.
>
>> My policy for Arm specific kernel code submissions is generally that
>> it should be written so it can work on either big-endian or little-endian
>> using the available abstractions (just like any architecture independent
>> code), but I don't normally expect it to be tested on big endian.
>>
>> There are some important examples of code that just doesn't work
>> on big-endian because it's far too hard, e.g. the UEFI runtime services.
>> That is also ok, if anyone really needs it, they can do the work.
>>
>> > > I suggest to get a quote from clang folks first about their schedule and
>> > > regarded importance of patchable-function-entries on BE, and leave it as
>> > > is: broken on certain clang configurations. It's not the kernel's fault.
>> >
>> > We can file an upstream PR (https://bugs.llvm.org) to talk about this
>> > (although I've CC'd Fangrui) but you would rather the kernel fail to
>> > work properly than prevent the user from being able to select that
>> > option? Why even have the "select" or "depends on" keyword then?

Created https://reviews.llvm.org/D79495 to allow the function attribute
'patchable_function_entry' on aarch64_be.
I think -fpatchable-function-entry= just works.

Note, LLD does not support aarch64_be
(https://github.com/ClangBuiltLinux/linux/issues/380).

>> I definitely want all randconfig kernels to build without warnings,
>> and I agree with you that making it just fail at build time is not
>> a good solution.
>>
>> > That said, I do think we should hold off on this patch until we hear
>> > from the LLVM developers.
>>
>> +1
>>
>>       Arnd
>
>Glad we are on the same page.
>
>Cheers,
>Nathan