[Bug c++/110816] New: Emit initialization code for empty class under -ftrivial-auto-var-init

[Bug c++/110816] New: Emit initialization code for empty class under -ftrivial-auto-var-init

[serge.guelton@telecom-bretagne.eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

            Bug ID: 110816
           Summary: Emit initialization code for empty class under
                    -ftrivial-auto-var-init
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: serge.guelton@telecom-bretagne.eu
  Target Milestone: ---

As show cased by https://godbolt.org/z/o5asYGq8G, gcc doesn't fill the byte
used by empty class/struct under -ftrivial-auto-var-init. This potentially
leaks a byte of memory.

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The testcase is:


struct f { void crash(); };

void bar(bool cond) {
    f t;
    if(cond)
        t.crash();
    //user(&t);
}

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> This potentially leaks a byte of memory.  
The only way to access that byte is to use memcpy or via char. 
-ftrivial-auto-var-init is not designed for security this way but rather for
normal code ...

IIRC atomic compare and swap will zero it out too ...

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-07-26

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> The only way to access that byte is to use memcpy or via char. 
> -ftrivial-auto-var-init is not designed for security this way but rather for
> normal code ...

That's not what the manual says (emphasis mine):

"Initialize automatic variables with either a pattern or with zeroes to
increase the security and predictability of a program by preventing
**uninitialized memory disclosure** and use."

> IIRC atomic compare and swap will zero it out too ...

The std::atomic and std::atomic_ref compare_exchange members will zero it, but
the compiler built-in won't.

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The only way to access that byte is to use memcpy or via char. 
> > -ftrivial-auto-var-init is not designed for security this way but rather for
> > normal code ...
> 
> That's not what the manual says (emphasis mine):
> 
> "Initialize automatic variables with either a pattern or with zeroes to
> increase the security and predictability of a program by preventing
> **uninitialized memory disclosure** and use."

probably should add 'some' qualification here.

> > IIRC atomic compare and swap will zero it out too ...
> 
> The std::atomic and std::atomic_ref compare_exchange members will zero it,
> but the compiler built-in won't.

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And fix the spelling of zeros, which is generally preferred to zeroes for the
noun.