linux-kernel - Re: [GIT PULL] x86/build changes for v4.17

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, 04 Apr 2018 16:53:52 +0000
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Y Knight <jyknight@...gle.com>,
        Chandler Carruth <chandlerc@...gle.com>,
        Stephen Hines <srhines@...gle.com>,
        Kees Cook <keescook@...gle.com>, groeck@...omium.org,
        Greg Hackmann <ghackmann@...gle.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17

(re-sending as plain text)

On Wed, Apr 4, 2018 at 2:38 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> There are known-bugs with building a kernel with clang right now (I
> pointed one out a few days ago about NULL checks being deleted from the
> clang output for no good reason, which really is scary for obvious
> reasons).

Is this the thread you are referring to?
https://lkml.org/lkml/2018/3/27/1286

It's definitely something curious that I'll need to sit down and
investigate more.  If there are other known instances, it would be good to
let me know.

> So while it is great that small subsets of the kernel can
> work properly (or hopefully properly), with clang, it still isn't ready
> to be considered a "fully supported and we can't change the kernel if we
> break using it" option, sorry.

> And don't tie _anything_ to a LTS kernel, that's exactly what those
> kernels are NOT for.  You implement features and things in the kernel
> when they are ready, and I'll pick a random LTS kernel out of the air
> when I feel like it.  Never should the two intersect and matter.

> So please, work on fixing up clang for asm-goto and other "features"
> that the kernel requires, and maybe when all build options/configs are
> really solid and working well, will we be able to properly consider it
> as a reason to implement, or not implement, something in the kernel
> source.

Acknowledged.
-- 
Thanks,
~Nick Desaulniers