[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[Richard Smith via cfe-dev]

On Tue, 21 Apr 2020 at 15:46, Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Apr 21, 2020 at 6:12 PM Richard Smith via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> What you're proposing is, without question, a language extension. Our
>> policy on language extensions is documented here:
>> http://clang.llvm.org/get_involved.html
>>
>> Right now, this fails at point 4. We do not want to create or encourage
>> the creation of language dialects and non-portable code, so the place to
>> have this discussion is in the C and C++ committees. Both committees have
>> processes for specifying optional features these days, and they might be
>> amenable to using those processes to standardize the behavior you're asking
>> for. (I mean, maybe not, but our policy requires that you at least try.)
>>
>> However, there is a variant on what you're proposing that might fare
>> better: instead of guaranteeing zero-initialization, we could guarantee
>> that any observation of an uninitialized variable *either* gives produces
>> zero or results in a trap. That is: it's still undefined to read from
>> uninitialized variables -- we still do not guarantee what will happen if
>> you do, and will warn on uninitialized uses and so on -- but we would bound
>> the damage that can result from such accesses. You would get the security
>> hardening benefits with the modest binary size impact. That approach would
>> not introduce the risk of creating a language dialect (at least, not to the
>> same extent), so our policy on avoiding language extensions would not apply.
>>
>
> I dont understand the point you're making here.  You're saying that if
> Clang provides reliable behavior, that's a language extension and therefore
> impossible; but if Clang provides behavior that unpredictably switches
> between only two possible alternatives (zero or trap), then that's not a
> language extension anymore and therefore is possible?
>

A major part of the purpose of point 4 of the policy is to prevent creation
of language dialects, such as have unfortunately been created by (for
example) the -fno-exceptions and -fno-rtti flags. If people can rely on
uninitialized variables behaving as if initialized to zero, then they will
write code that assumes that to be the case, and such code will not work in
compilers / compilation modes that don't provide that language dialect. If
people cannot rely on uninitialized variables behaving as if initialized to
zero, then we mitigate the risk of creating a language dialect.


> I suspect many of the people quoted in the original quote-fest would not
> be happy with "zero *or trap*" as the two behaviors.
>

They are, of course, welcome to speak up and express that opinion. But note
that one reason that people want zero-init to be used from a security
perspective is to give a high chance that use of the uninitialized value
(especially when it is a pointer) will crash, and issuing a trap instead is
consistent with that. (Another reason is that zero is very unlikely to be
an out-of-bounds array index, but issuing a trap in that case is likely
more desirable than producing a wrong-but-in-bounds result.)

What if you made it "zero *or one*"?  That is, whenever you access an
> uninitialized variable, you are guaranteed to get either all-bits-zero or
> else all-bits-zero-except-for-the-last-bit-which-is-1?  Would that
> selection of two behaviors leave matters sufficiently unspecified so as to
> dodge this "language extension" nonsense?
>

Please try to keep a respectful tone. Our policy in this area exists for a
reason and is not "nonsense".

Any reasonable alternative that practically mitigates the risk of creating
a language dialect, while still addressing the presented use cases, would
seem in scope for discussion.

Alternatively, what about "all-bits-zero or else we explode the physical
> computer," or "all-bits-zero or else we output a proof of Goldbach's
> conjecture"?
>
> –Arthur
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200421/3760e70d/attachment.html>