linux-kernel - Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds

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:   Tue, 18 Dec 2018 19:33:07 +0000
From:   Nadav Amit <namit@...are.com>
To:     Sedat Dilek <sedat.dilek@...il.com>
CC:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Richard Biener <rguenther@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Logan Gunthorpe <logang@...tatee.com>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        "linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
        Alok Kataria <akataria@...are.com>,
        Juergen Gross <jgross@...e.com>,
        Andy Lutomirski <luto@...nel.org>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds

> On Dec 17, 2018, at 1:16 AM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> 
> On Thu, Dec 13, 2018 at 10:19 AM Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>> Revert the following commits:
>> 
>> - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd
>>  ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2
>>  ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200.
>>  ("x86/extable: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - 494b5168f2de009eb80f198f668da374295098dd.
>>  ("x86/paravirt: Work around GCC inlining bugs when compiling paravirt ops")
>> 
>> - f81f8ad56fd1c7b99b2ed1c314527f7d9ac447c6.
>>  ("x86/bug: Macrofy the BUG table section handling, to work around GCC inlining bugs")
>> 
>> - 77f48ec28e4ccff94d2e5f4260a83ac27a7f3099.
>>  ("x86/alternatives: Macrofy lock prefixes to work around GCC inlining bugs")
>> 
>> - 9e1725b410594911cc5981b6c7b4cea4ec054ca8.
>>  ("x86/refcount: Work around GCC inlining bug")
>>  (Conflicts: arch/x86/include/asm/refcount.h)
>> 
>> - c06c4d8090513f2974dfdbed2ac98634357ac475.
>>  ("x86/objtool: Use asm macros to work around GCC inlining bugs")
>> 
>> - 77b0bf55bc675233d22cd5df97605d516d64525e.
>>  ("kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs")
>> 
>> A few days after those commits applied, discussion started to solve
>> the issue more elegantly on the compiler side:
>> 
>>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92&amp;data=02%7C01%7Cnamit%40vmware.com%7C40b5df8a38e54f310ab708d664005ee0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636806350113136223&amp;sdata=RlYXSyhzM6HLQuKC2NuyDqvke9qZ11tvMDNd32NiF2U%3D&amp;reserved=0
>> 
>> The "asm inline" was implemented by Segher Boessenkool, and now queued
>> up for GCC 9. (People were positive even for back-porting it to older
>> compilers).
>> 
>> Since the in-kernel workarounds merged, some issues have been reported:
>> breakage of building with distcc/icecc, breakage of distro packages for
>> module building. (More fundamentally, we cannot build external modules
>> after 'make clean')
>> 
>> Patching around the build system would make the code even uglier.
>> 
>> Given that this issue will be solved in a cleaner way sooner or later,
>> let's revert the in-kernel workarounds, and wait for GCC 9.
>> 
>> Reported-by: Logan Gunthorpe <logang@...tatee.com> # distcc
>> Reported-by: Sedat Dilek <sedat.dilek@...il.com> # debian/rpm package
> 
> Hi,
> 
> I reported the issue with debian package breakage in [1].
> 
> I am not subscribed to any involved mailing-list and not following all
> the discussions.
> I see the situation is not easy as there is especially linux-kbuild
> and linux/x86 involved and maybe other interests.
> But I am interested in having a fix in v4.20 final and hope this all
> still works with LLVM/Clang.
> 
> I can offer my help in testing - against Linux v4.20-rc7.
> Not sure if all discussed material is in upstream or elsewhere.
> What is your suggestion for me as a tester?
> 
> Will we have a solution in Linux v4.20 final?

Thanks for the reference. I see solutions have already been developed. So
it’s Masahiro’s call.