[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Qing Zhao qing.zhao@oracle.com
Tue Jun 8 18:05:53 GMT 2021



> On Jun 8, 2021, at 11:59 AM, Kees Cook <keescook@chromium.org> wrote:
> 
> On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote:
>> On Mon, 7 Jun 2021, Qing Zhao wrote:
>>> 
>>> Personally, I am okay with splitting padding initialization from this current patch,
>>> Kees, what’s your opinion on this? i.e, the current -ftrivial-auto-var-init will NOT initialize padding, we will add another option to 
>>> Explicitly initialize padding.
>> 
>> It would also be possible to have -fauto-var-init, -fauto-var-init-padding
>> and have -ftrivial-auto-var-init for clang compatibility enabling both.
> 
> Sounds good to me!

Agreed!

Then I will take this approach:

1.  Adding two separate new options:
   -fauto-var-init.     initialize auto variables to zero or patterns. For variables that have paddings, only initialize valid fields, no padding initialization;
   -fauto-var-init-padding    initialize paddings inside an auto variables to zeroes. 

2.  Add another new option for Clang compatibility:
   -ftrivial-auto-var-init   will enable -fauto-var-init + -fauto-var-init-padding


Thanks.

Qing
> 
>> Or -fauto-var-init={zero,pattern,padding} and allow
>> -fauto-var-init=pattern,padding to be specified.  Note there's also
>> padding between auto variables on the stack - that "trailing"
>> padding isn't initialized either?  (yes, GCC sorts variables to minimize
>> that padding)  For example for
>> 
>> void foo()
>> {
>>  char a[3];
>>  bar (a);
>> }
>> 
>> there's 12 bytes padding after 'a', shouldn't we initialize that?  If not,
>> why's other padding important to be initialized?
> 
> This isn't a situation that I'm aware of causing real-world problems.
> The issues have all come from padding within an addressable object. I
> haven't tested Clang's behavior on this (and I have no kernel tests for
> this padding), but I do check for trailing padding, like:
> 
> struct test_trailing_hole {
>        char *one;
>        char *two;
>        char *three;
>        char four;
>        /* "sizeof(unsigned long) - 1" byte padding hole here. */
> };
> 
> -Kees
> 
> -- 
> Kees Cook



More information about the Gcc-patches mailing list