[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

Wed May 11 09:59:45 PDT 2022

kees added a comment.

In D125142#3505767 <https://reviews.llvm.org/D125142#3505767>, @jfb wrote:

> I think the most relevant post from @rsmith is: https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/40
>
> He has a prototype: https://reviews.llvm.org/D79249
> I assume he would like someone to pursue it further, it was a good faith attempt at not just demanding. I'd played with it and it needed a few fixes, but overall it was pretty complete. Does someone want to give it a go?

That's a different mode and doesn't seem to be relevant to the current situation and this change to drop the -enable flag.

> The fact remains that people have deployed zero init widely (you're likely running multiple zero-init codebases to read this), and they would not ever deploy zero-or-trap init. That's simply a fact.

Right.

> Separately, we'd discussed narrowing the performance gap between pattern and zero-init, @Florian and team had done a bunch of work 2+ years ago, but I don't know how "done" we can claim that work is since I haven't been tracking the work.

Performance is the smaller part of why init=zero is being used so widely. It's about stability. Quoting from my earlier thread <https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html>:

> Another driving factor (see below from various vendors/projects), is the
> security stance. Putting non-zero values into most variables types ends
> up making them arguably more dangerous than if they were zero-filled.
> Most notably, sizes and indexes and less likely to be used out of bounds
> if they are zero-initialized. The same holds for bool values that tend
> to indicate success instead of failing safe with a false value. While
> pointers in the non-canonical range are nice, zero tends to be just
> as good. There are certainly exceptions here, but the bulk of the
> historical record on how "uninitialized" variables have been used in
> real world exploitation involve their being non-zero, and analysis of
> those bugs support that conclusion.

This "usually handled safely" state (e.g. existing NULL pointer checks) is specifically why Chrome OS switched from init=pattern to init=zero.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125142/new/

https://reviews.llvm.org/D125142