linux-kernel - Re: [PATCH 2/2] x86, boot: Use regparm=0 for memcpy and memset when using clang

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: <CA+=D-XX8AnD+BpWDJjAhafdDWq+fCMOwYqdRNZ5XkDscw26=cA@mail.gmail.com>
Date:   Thu, 16 Mar 2017 08:21:35 -0700
From:   Michael Davidson <md@...gle.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>, x86@...nel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] x86, boot: Use regparm=0 for memcpy and memset when
 using clang

On Thu, Mar 16, 2017 at 12:46 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> I don't think we want to add such ugly workarounds for clang bugs in a piecemail
> wise manner. If this was the _only_ workaround required to have a working kernel
> built with clang then maybe, but there's no way to tell from this submission.
>
Apologies for the lack of context. This change, and the #undef of mem*
in x86/boot/string.c
are actually the only patches that are absolutely needed to get an
x86_64 kernel to
build and boot successfully with clang provided that you also arrange
for  clang
be invoked with the -no-integrated-as option. In practice it is also
necessary to disable
a few more clang warnings to make the build tolerable.

I will send out a more complete set of patches later today which deal
with those other
issues.

As far as the specific issue of this particular clang bug is concerned
I did also consider
adding a configuration option to simply not build the real mode boot
code at all but
that looked like it would require much more extensive surgery.