linux-kernel - Re: move stack-protector availability out of Kconfig

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: <CAGXu5jKkUbDaOuypmGhq1FCDDvsU24GkGEU9z0d1YQ9-kRajNQ@mail.gmail.com>
Date:   Tue, 13 Feb 2018 07:41:42 -0800
From:   Kees Cook <keescook@...omium.org>
To:     whiteheadm@....org
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Arnd Bergmann <arnd@...db.de>,
        Josh Triplett <josh@...htriplett.org>,
        Nick Piggin <npiggin@...il.com>,
        Laura Abbott <labbott@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: move stack-protector availability out of Kconfig

On Tue, Feb 13, 2018 at 7:27 AM, tedheadster <tedheadster@...il.com> wrote:
> Kees,
>   I have a question about this patch. When I configure a kernel for
> ARCH=i386 it sets these Kconfig variables this way:
>
> HAVE_CC_STACKPROTECTOR=y
> CC_STACKPROTECTOR_AUTO=y
>
> CC_STACKPROTECTOR_NONE=n
> CC_STACKPROTECTOR_REGULAR=n
> CC_STACKPROTECTOR_STRONG=n
>
> It seems to me that at least _one_ of the last _three_ variables
> should be set to 'y' with the defaults that are being set, probably
> CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to
> me.

The last three are a defined state and map to specific flags. _AUTO
just tries its best to find any working flag. After some redesign to
Kconfig, this may improve so that Kconfig maps directly to things that
right now only the Makefile can determine. That's under development
now.

> As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32
> [=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels
> to hang. I'll discuss  that in a different email thread, but just
> wanted to say how I came upon this.

I'd tested this combination, but I must have missed something. I'll go
read the other email...

-Kees

-- 
Kees Cook
Pixel Security