On Thu, Mar 3, 2022 at 7:23 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
wrote:

> Dear Hubert,
>
> On Thu, Mar 3, 2022 at 4:53 PM Hubert Tong <
> hubert.reinterpretcast_at_[hidden]> wrote:
>
>> …
>> The net of this is that we're getting initialization for the first member
>> and trailing padding beyond the largest union member for alignment purposes
>> because "as if static storage duration" does not provide as many guarantees
>> as people think... (not so much of a problem for structs without nested
>> unions).
>>
>> I might need to open a defect for Clang's
>> `-ftrivial-auto-var-init=pattern` to properly restrict the padding that is
>> zeroed, but I really think the situation is a bit nonsensical.
>>
>
> I agree that the situation is non-ideal. However, I did do my best to
> represent your concerns to the Committee. In particular, I provided
> Optional Change 0 as part of the proposal. It was Optional and not part of
> the core proposal (therefore, it was voted on separately). The reason is
> because the wording in the previous revision had attempted to mandate it,
> and **most** individuals in the C Committee were miffed by such a departure
> from how unions were normally treated: it has always been first-member-init.
>

I agree that Optional Change 0 is one way of approaching the gap. It sounds
from what you describe above that the primary objection to it was how it
does so. An alternative method would be to adjust the static initialization
wording (with WG 21 coordination) to clarify that (a) the representation of
the value converted from 0 that is chosen for each scalar type is
consistent for all such initialization of an object of that type, (b) all
padding bits between members of a structure and all trailing padding in a
structure is zeroed, and (c) all bytes of a union that do not overlap with
the object representation of the first member of the union are zeroed.


>
> In an attempt to alleviate their concerns, I wrote Optional Change 0
> (
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2900.htm#wording-6.7.9p10-extra)
> as follows:
>
> > …
> > — if it is a union and the initializer is the empty initializer, the
> largest member is initialized (recursively) according to these rules, then
> the first named member is initialized (recursively) according to these
> rules, and any padding is initialized to zero bits; > — if it is a union and
> the initializer is not an empty initializer , the first named member is
> initialized (recursively) according to these rules, and any padding is
> initialized to zero bits; > …
>
> We took a vote on it. It did not pass:
>
> > No consensus to initialize whole union then largest member for {}
> (N2900) into C23.
>
> Again, I sincerely tried to make what you had pointed out as part of
> the semantics so that unions would be usefully included. I think folks in
> WG14 would be okay if there was a separate syntax that deliberately
> initialized "as-if everything including padding bits are static-init, and
> then performed the correct initialization of the proper members". I think
> if you presented the security benefits to them and gave them that
> alternative syntax, they would like it. I think that implementing it in a
> handful of compilers and advertising it would make it easy to get into the
> next revision of C, and consequently C++ (both Committees need/want
> something of this nature).
>

That would be a separate feature though. It is also perhaps less likely to
be expressed as a modification of the initialization than it is to be as a
modifier of the type because assignment has similar problems (e.g., when
assigning to "fresh" heap-allocated memory).


>
> I understand it is not ideal to have the opt-in syntax be the secure
> syntax. I can't really change C or C++'s momentum in this direction,
> though. Many members are adamant we do not change the semantics of existing
> initialization, and stick to existing principles, no matter how dangerous
> or no matter how proven they are to leak information/cause problems.
>

Perhaps the reaction was for the scope of the change implied by Optional
Change 0, which I agree is scary if the union's first member disagreed with
its largest member as to what the byte values in the object representation
needs to be. A wording change that reinforces what people probably are
assuming about static initialization might get a better reception.


>
> …
>> It seems the goal was achieved for structs (or mostly so) and not
>> achieved for unions. It is still a question (because "any padding" may
>> refer to "padding of the aggregate/union" instead of "padding within")
>> whether integer subobjects may have non-zero padding bits from such an
>> initialization.
>>
>
> My interpretation is that it was "padding of the aggregate/union",
> but bits inside (e.g., for an integer) *could* be non-zero (since the
> static init rules say it is the value of literal 0 cast to the integer
> type, and if that literal zero cast to the integer type produces an integer
> that has non-zero padding bits, that's fine because the
> value-representation bits are already in the proper configuration to
> presented the casted-literal-0).
>
> I think clarifying that all the padding bits within the structure, or
> the first member of the union, or within any arithmetic or pointer object,
> should be 0 when doing static initialization. I think that is in the spirit
> of what the wording is trying to achieve. I do not know if they were
> considering the padding bits of integers when they added the padding bit
> fixes for structures/unions in C99 for static initialization. This does
> become more important where things like _Bool, which by-default have
> padding bits because the value representation only takes 1 bit and _Bool
> will occupy at least 8 bits.
>
> I should ask some of the older WG14 members if they remember what was
> going on at the time for C99 and that change. Maybe they did not add the
> clause to arithmetic and pointer types in C99 because they just did not
> consider arithmetic types with padding bits as something that could be
> real/important. Or maybe they believed that no architecture would interpret
> "initialized from conversion from literal 0" as giving padding bits.
>

Aside from the consistency suggested by my change suggestion earlier, the
line between being a goal and a non-goal gets fuzzy past asking for the
all-bits zero representation if that is a representation of the value
converted from 0.


>
>>
>> …
>> It is compatible in that a user only relying on the C++ semantics is
>> fine. It is not compatible in the way where "correct" C code is also
>> "correct" C++ code.
>>
>
> Agreed, but this is beyond the scope of my work. I could ask C++ if
> they were interested in such a change (padding bits are zero), and the
> benefits it could bring to aggregates (though, perhaps not to unions, as
> you detailed previously). I think it would be a positive change.
> Alternatively, we could revert what C has done and specifically exempt = {}
> from initializing padding bits. It would worsen security for structures and
> for people who put largest-member-first in their unions. I think that would
> be a negative change, but the positive is that both languages would be
> equally "too bad for you, security person". (Which doesn't sound like a
> benefit, but is at least some form of "equal is always fair", and therefore
> dependable.)
>

Suggesting such a change for C++ is likely going to produce objections due
to reductions in efficiency for code that is "correct" today.

I would not consider this {} behaviour a solution to a "sanitized" handoff
to a different security context scenario anyway. Even assigning the "right
values" after such an initialization is not fool-proof. It's perfectly
conforming to omit zeroing of padding bytes if an assignment to a member
(which causes padding bytes to take unspecified values) occurs immediately
after. It's also perfectly conforming to copy data adjacent to the source
(that is within the same memory allocation) into the padding.

I think the pragmatic approach would be to make {} in C perform (for other
than static or thread storage duration) what C++ does. `{ static }` or
something as new syntax might be appropriate for saying "as if initialized
with 'zero padding'"; however, someone who needs that is probably doing
something suspect (wants security but not doing enough to have security or
is reading from an inactive member of a union). A false sense of security
is probably harmful to actual security.

My thinking on the subject of whether a convenient syntax for getting the
as-if static storage duration initialization may have changed since I first
engaged with you (a year or more ago) regarding this paper. The fact that
the C syntax being made to do it does something different than what C++
does for the same syntax makes me inclined not to have that syntax for this
as-if static purpose.

TL;DR: I think {} should be better aligned to the status quo for C++. I
think static initialization wording should guarantee what people expect and
implementations provide. I think the security scenarios mentioned where {}
having the "as-if static" behavior is said to help should be addressed by a
different solution. I do realize that (with what I am suggesting) only the
first sentence ties closely with the paper; however, I hope you don't mind
also following up on the second since our discussion on that topic so far
has been productive. I am up for discussing the third with you if you wish
to explore it further.


> Sincerely,
> JeanHeyd
>
>>