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: <CA+icZUWR0Pg7z+GhgbB+MBKR2FQtP2x3Mdq5gebJvumJDc1j1w@mail.gmail.com>
Date:   Thu, 24 May 2018 12:33:51 +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>, x86@...nel.org
Subject: Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 12:08 AM, Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
> H. Peter,
>
> It was reported [0] that compiling the Linux kernel with Clang +
> CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due to
> how GCC does not emit a stack guard for static inline functions (see
> Alistair's excellent report in [1]) but Clang does.
>
> When working with the LLVM release maintainers, Tom had suggested [2]
> changing the inline assembly constraint in native_save_fl() from '=rm' to
> '=r', and Alistair had verified the disassembly:
>
> (good) code generated w/o -fstack-protector-strong:
>
> native_save_fl:
>           pushfq
>           popq    -8(%rsp)
>           movq    -8(%rsp), %rax
>           retq
>
> (good) code generated w/ =r input constraint:
>
> native_save_fl:
>           pushfq
>           popq    %rax
>           retq
>
> (bad) code generated with -fstack-protector-strong:
>
> native_save_fl:
>           subq    $24, %rsp
>           movq    %fs:40, %rax
>           movq    %rax, 16(%rsp)
>           pushfq
>           popq    8(%rsp)
>           movq    8(%rsp), %rax
>           movq    %fs:40, %rcx
>           cmpq    16(%rsp), %rcx
>           jne     .LBB0_2
>           addq    $24, %rsp
>           retq
> .LBB0_2:
>           callq   __stack_chk_fail
>
> It looks like the sugguestion is actually a revert of your commit:
> ab94fcf528d127fcb490175512a8910f37e5b346:
> x86: allow "=rm" in native_save_fl()
>
> It seemed like there was a question internally about why worry about pop
> adjusting the stack if the stack could be avoided altogether.
>
> I think Sedat can retest this, but I was curious as well about the commit
> message in ab94fcf528d: "[ Impact: performance ]", but Alistair's analysis
> of the disassembly seems to indicate there is no performance impact (in
> fact, looks better as there's one less mov).
>
> Is there a reason we should not revert ab94fcf528d12, or maybe a better
> approach?
>
> [0] https://lkml.org/lkml/2018/5/7/534
> [1] https://bugs.llvm.org/show_bug.cgi?id=37512#c15
> [2] https://bugs.llvm.org/show_bug.cgi?id=37512#c22

[ CC Linux/x86 folks ]

Hi,

with reverting...

commit ab94fcf528d127fcb490175512a8910f37e5b346
"x86: allow "=rm" in native_save_fl()"

...I had success to boot into a paravirtualized/strong-stackprotected
Linux-kernel v4.14.43 on *bare metal* (Lenovo ThinkPad T470).

For my experiments I used LLVM/Clang version 7~svn332830 from <apt.llvm.org>.
My host runs Debian/testing AMD64.

My patchset is against linux v4.14.43.
The base was Matthias (mka) "v4.14_ext" Git branch (which bases on
Linux v4.14 vanilla) [2].

[1] Testing patch for x86 (x86/paravirt/stackprotector)...

Revert "x86: allow "=rm" in native_save_fl()"

[2] Additional patches when using HOSTCC in make-line and wanna-build
XEN (stolen from Linus tree)...

x86: xen: remove the use of VLAIS
kbuild: clang: remove crufty HOSTCFLAGS

[3] Revert kbuild-fixes included in v4.14.43 and revert clang3/clang4
as I use clang7...

Revert "UPSTREAM: kbuild: fix linker feature test macros when cross
compiling with Clang"
Revert "BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch Makefile"
Revert "BACKPORT: kbuild: disable clang's default use of -fmerge-all-constants"
Revert "CLANG4: crypto: arm64/aes-ce: Explicitly pass through assembler options"
Revert "CLANG4: kbuild: Add -meabi gnu to the clang parameters"
Revert "CLANG4: arm64: prefetch: Use __builtin_arm_prefetch() for clang"
Revert "CLANG4: Disable lkdtm when ftrace is enabled"
Revert "CLANG4: futex: don't optimize futex_detect_cmpxchg() on ARM64"
Revert "CLANG3: core: clang: work around x86 regparm / intrinsics bug"

My kernel-config, dmesg-log and qemu-log are attached.

Hope this helps.

Regards,
- Sedat -

[1] https://bugs.llvm.org/show_bug.cgi?id=37512#c26
[2] https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext

View attachment "qemu-log.txt" of type "text/plain" (20176 bytes)

Download attachment "config-4.14.43-2-iniza-llvmlinux" of type "application/octet-stream" (197116 bytes)

View attachment "dmesg_4.14.43-2-iniza-llvmlinux.txt" of type "text/plain" (68021 bytes)