I think a compiler option for zero initialization is an
excellent idea and people should use it in production.

Zero initialization by default when mandated by the standard is
counterproductive and will hurt security, because it takes away
options to find and fix these bugs from missing initialization
because as soon as people start to rely on it there will be
a lot of false positives.

I would be fine with zero or trap (e.g. option 4.9). This
option is dismissed in the paper because it could be
"such a change is rejected by teams because it cannot be
deployed to codebases that seem to work just fine".

But this just illustrates the point: The code base in
question would then not have UB from uninitialized
automatic variable but still likely have hidden subtle
bugs. Every trap you might then get from this code base
indicates a possible bug that needs to be fixed. A team
not willing to do this is a problem and we should not
penalize everybody else because of this.

In production, it might be perfectly reasonable in some
cases to turn off the traps or continue after a run-time
diagnostic, but this is an entirely different question.

I am also perfectly fine with leaving this undefined.
C made reading of unintialized variables undefined
exactly to support the use case of detecting these
bugs with traps (at this time using hardward traps,
but the same logic applied to sanitizers). The existence
of compiler options to zero initialize automatic
variables as well as tools to detect UB implies that
there is no nreal eed to standardize anything.
People can and should just use such tools.

The paper perpetuates the misconception that it is
the UB that causes the security problem, while in reality
it is the underlying bug in combination with the
specific behavior of the compiler in this scenario.
Making the buggy behavior defined does not change
reality, the bug is still there.

So to summarize: Fixing bugs is good. Mitigating problems
by zero initialization is good. But making bugs themselves
more difficult to find by mandating zero initialization is
counterproductive.

Martin



Am Freitag, dem 10.02.2023 um 12:00 -0800 schrieb Robert Seacord via Liaison:

WG21 would like some feedback from WG14 on the following proposal "Zero-initialize objects of automatic storage duration":

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html

Thanks,
rCs




_______________________________________________
Liaison mailing list
Liaison_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2023/02/1172.php