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]

Date:   Fri, 25 May 2018 10:24:13 +0200
From:   Sedat Dilek <sedat.dilek@...il.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     hpa@...or.com, Alistair Strachan <astrachan@...gle.com>,
        Manoj Gupta <manojgupta@...gle.com>,
        Matthias Kaehlcke <mka@...gle.com>,
        Greg Hackmann <ghackmann@...gle.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 10:26 PM, Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
[...]
>> 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
>
Hi Nick,

sorry, if I was not clear/precise on this.
You referenced the patches from my 1st tryouts which were wrong in the
sense of "did-not-compile".
I have attached the correct two patches.
The commit-bodies needs some more "massage" to quote Thomas Gleixner,
useful web-links and credits should be added also.
I appreciate your help here.

>From my understanding...
The more correct approach in fixing the issue is to add Clang's
"no_stack_protector" function attribute support and mark
native_save_fl() accordingly.
The 2nd solution partly revert "x86: allow "=rm" in native_save_fl()"
is not favoured as the impact on other parts of the Linux-kernel are
not clear.
The 1st solution requires a Clang >= 7-svn331925.
Is that correct?

What does that mean in fixing the issue?
[ Linux-kernel side ]
I guess GCC and marking native_save_fl() should be OK?
After some rework, do you plan to push patches from the 1st solution
to Linus uptream?
[ LLVM/Clang side ]
What about backporting "no_stack_protector" to LLVM/Clang v6.0.1?

Thanks to all involved people.

Sunshiny greetings from North-West Germany,
- Sedat -

View attachment "0001-compiler-clang.h-Add-no_stack_protector-function-att.patch" of type "text/x-patch" (1552 bytes)

View attachment "0002-x86-paravirt-Mark-native_save_fl-with-__nostackprote.patch" of type "text/x-patch" (963 bytes)