linux-kernel - Re: [PATCH v2] [RFC] security: allow using Clang's zero initialization for stack variables

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: <CANP3RGfGThsMOyi2faZmWb5S8tner-aQOsppP=_1+Fm0TDO95w@mail.gmail.com>
Date:   Tue, 16 Jun 2020 01:41:31 -0700
From:   Maciej Żenczykowski <maze@...gle.com>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     yamada.masahiro@...ionext.com, Kees Cook <keescook@...omium.org>,
        jmorris@...ei.org, Nick Desaulniers <ndesaulniers@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-security-module@...r.kernel.org,
        Kernel hackers <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] [RFC] security: allow using Clang's zero
 initialization for stack variables

> In addition to -ftrivial-auto-var-init=pattern (used by
> CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
> locals enabled by -ftrivial-auto-var-init=zero.
> The future of this flag is still being debated, see
> https://bugs.llvm.org/show_bug.cgi?id=45497
> Right now it is guarded by another flag,
> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
> which means it may not be supported by future Clang releases.
> Another possible resolution is that -ftrivial-auto-var-init=zero will
> persist (as certain users have already started depending on it), but the
> name of the guard flag will change.
>
> In the meantime, zero initialization has proven itself as a good
> production mitigation measure against uninitialized locals. Unlike
> pattern initialization, which has a higher chance of triggering existing
> bugs, zero initialization provides safe defaults for strings, pointers,
> indexes, and sizes. On the other hand, pattern initialization remains
> safer for return values.
> Performance-wise, the difference between pattern and zero initialization
> is usually negligible, although the generated code for zero
> initialization is more compact.
>
> This patch renames CONFIG_INIT_STACK_ALL to
> CONFIG_INIT_STACK_ALL_PATTERN and introduces another config option,
> CONFIG_INIT_STACK_ALL_ZERO, that enables zero initialization for locals
> if the corresponding flags are supported by Clang.

I'm a great fan of zero initialization as opposed to pattern.
I don't understand why clang is refusing to make this a supported option.

Anyway:

Reviewed-by: Maciej Żenczykowski <maze@...gle.com>