linux-kernel - Re: [clang] stack protector and f1f029c7bf

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: <CAKwvOdnLt5qr_5ah86qdsocTxUbo_3X1y3PPRp1EZwt=__NxnA@mail.gmail.com>
Date:   Thu, 24 May 2018 13:26:14 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     hpa@...or.com
Cc:     Alistair Strachan <astrachan@...gle.com>,
        Manoj Gupta <manojgupta@...gle.com>,
        Matthias Kaehlcke <mka@...gle.com>,
        Greg Hackmann <ghackmann@...gle.com>, sedat.dilek@...il.com,
        tstellar@...hat.com, LKML <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...gle.com>
Subject: Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 11:59 AM <hpa@...or.com> wrote:
> Ok, this is the *second* thing about LLVM-originated bug reports that
drives me batty. When you *do* identify a real problem, you propose a paper
over and/or talk about it as an LLVM issue and don't consider the often far
bigger picture.

Considering the bigger picture is why we have this thread going.  You have
much more context about the kernel than I or the llvm maintainers do.  We
can't consider the bigger picture until we ask.

> Issue 1: Fundamentally,

Fundamentally, the Linux kernel should not rely on GCC's heuristics for
adding or not adding a stack protector to functions with custom calling
conventions that are not marked in any way to let the compiler know.

Should GCC change their heuristic, deciding to insert stack guards for
non-inlined but marked static inline functions for
-fstack-protector-strong, or the kernel decide to use
-fstack-protector-all, the paravirt code will break in the same way.

> You are claiming it doesn't buy us anything, but you are only looking at
the paravirt case which is kind of "special" (in the short bus kind of way),

That's fair.  Is another possible solution to have paravirt maybe not use
native_save_fl() then, but its own non-static-inline-without-m-constraint
implementation?

> Issue 2: ... The other option is to turn stack canary explicitly off for
all such functions.

We're looking to add the compiler attribute no_stack_protector.  It's added
in mainline clang, the llvm bug cited earlier is about getting it
backported into clang-6.0.1 release.  Sedat has tested/verified a set of
patches to the kernel that use this new feature in:
https://marc.info/?l=linux-kernel&m=152697630812366&w=2

> Issue 3: Let's face it, reading and writing the flags should be builtins,
exactly because it has to do stack operations, which really means the
compiler should be involved.

I'm happy to propose that as a feature request to llvm+gcc.
-- 
Thanks,
~Nick Desaulniers