> On Jun 8, 2021, at 11:59 AM, Kees Cook <keesc...@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
