Conversation

Notices

Embed this notice
pinskia (pinskia@hachyderm.io)'s status on Sunday, 19-Jan-2025 15:19:22 JST pinskia
in reply to
- Kees Cook :tux:
@kees From the way I understand the infrastructure was done to allow for C++ needing to zero-initialize non-active union fields. And then it was shown that C23 allowed for the change too. So it was done for C23 too.

In conversation about 19 days ago from hachyderm.io permalink
- Embed this notice
  Kees Cook :tux: (kees@fosstodon.org)'s status on Sunday, 19-Jan-2025 15:19:23 JST Kees Cook :tux:
  
  Well I guess everyone everywhere will want to use -fzero-init-padding-bits=all when updating to GCC15 to avoid regressing their uninitialized variable mitigations... Why in the world would the C standard committee work to make things *less* safe by default??!
  Edit: this appears to be a decision on GCC's part and not a new change from the C committee. (See down-thread.)
  https://infosec.exchange/@edmonds/113851256533780886
  In conversation about 19 days ago permalink
  Attachments
  1. No result found on File_thumbnail lookup.
    
    Robert Edmonds (@edmonds@infosec.exchange)
    
    from Robert Edmonds
    
    @bert_hubert@fosstodon.org Oh yes I was just idly wondering if that would work, I've already poured over the disassembly and seen the movl's and movb's in the actual broken code 🙂 In the upcoming gcc 15 they have introduced new behavior due to C23 which allows for a standards compliant "= {}" initializer in C that zeroes all the bits (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2900.htm), and they've, coincidentally, taken the opportunity to change the behavior of the "= {0}" initializer from one standards compliant interpretation (zero all the bits) to another standards compliant interpretation (don't necessarily zero all the bits). C23 6.2.6.1 paragraph 7 (same as in previous versions of the C standard): > When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values. There is a new -fzero-init-padding-bits= option in gcc 15 that controls the behavior (https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fzero-init-padding-bits_003dvalue) which I found completely confusing until I realized gcc uses the term "union padding bits" in a sort of unconventional way. But you don't really want to rely on those new flags in gcc 15 if you can reorder the members of the union and rely on standards compliant "= {0}" initialization. In that case, always remember to put the biggest, strongest member of your union at the front if you want it initialized, just like a real union 😃
  Haelwenn /элвэн/ :triskell: likes this.

Public

Conversation

Notices

Feeds