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

[Kees Cook via cfe-dev]

On Tue, Apr 21, 2020 at 06:44:44PM -0400, Arthur O'Dwyer 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.)

Well, I wasn't intending to re-discuss the presence of the feature. I was
trying to point out that it does exist in Clang already, and it exists
in other compilers too (and is being rapidly embraced by projects). So,
language extension or not, this behavior is present in released C/C++
binaries. Do you mean that _because_ it's present, it should be brought
to the committee for standardization? If so, what's the right path there?

> > 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.

While I like the trap idea, I must say that I don't have a lot of
confidence that it can be done in a way that would actually provide the
same coverage benefits. How would such detection work? There are entire
suites of tools (e.g. KMSan) that exist for this kind of thing and are not
really suited for production use because it's so expensive to implement.

> 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?

Er, is that what was meant? I mean, don't we kind of already have this
state in Clang already with "pattern" or "zero"? I'm just hoping to drop
the -enable... flag.

> I suspect many of the people quoted in the original quote-fest would not be
> happy with "zero *or trap*" as the two behaviors.
> 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?

Speaking with my kernel security flaw mitigation hat on, no, zero-init is
the desired feature unless trap is equally or less expensive, in which
case trap is great because then the kernel will warn and then set it
to zero.

-- 
Kees Cook