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

[Kees Cook]

On Tue, Jul 13, 2021 at 02:29:33PM -0700, Kees Cook wrote:
> I've extracted the kernel test to build for userspace, and it behaves
> the same way. See attached "stackinit.c".

I've adjusted this slightly (the "static" tests weren't testing the
correct thing, but the results remained the same). Here's what I see.

This is the variable on the stack:

struct test_small_hole {
        size_t                     one;                  /*     0     8 */
        char                       two;                  /*     8     1 */

        /* XXX 3 bytes hole, try to pack */

        int                        three;                /*    12     4 */
        long unsigned int          four;                 /*    16     8 */

        /* size: 24, cachelines: 1, members: 4 */
        /* sum members: 21, holes: 1, sum holes: 3 */
        /* last cacheline: 24 bytes */
};

The above is 0x18 in size.

0000000000405370 <leaf_small_hole_static_all.constprop.0>:
  405370:       40 0f b6 c7             movzbl %dil,%eax
  405374:       41 89 f1                mov    %esi,%r9d
  405377:       48 8d 74 24 b8          lea    -0x48(%rsp),%rsi

-0x48(%rsp) is the location of the variable.

  40537c:       44 0f be c7             movsbl %dil,%r8d
  405380:       48 b9 01 01 01 01 01    movabs $0x101010101010101,%rcx
  405387:       01 01 01 
  40538a:       49 89 c2                mov    %rax,%r10
  40538d:       48 c7 44 24 b8 00 00    movq   $0x0,-0x48(%rsp)
  405394:       00 00 

8 byte move of 0 to -0x48(%rsp) through -0x41

  405396:       48 f7 e1                mul    %rcx
  405399:       c6 44 24 c0 00          movb   $0x0,-0x40(%rsp)

1 byte move of 0 to -0x40(%rsp)

  40539e:       4c 0f af d1             imul   %rcx,%r10
  4053a2:       c7 44 24 c4 00 00 00    movl   $0x0,-0x3c(%rsp)
  4053a9:       00 

4 byte move of 0 to -0x3c through -0x39 (note that -0x3f, -0x3e,
-0x3d is _not_ written, which maps to the 3 byte struct hole).

  4053aa:       48 c7 44 24 c8 00 00    movq   $0x0,-0x38(%rsp)
  4053b1:       00 00 

8 byte move of 0 to -0x38(%rsp) through -0x31.

  4053b3:       48 89 35 d6 9c 00 00    mov    %rsi,0x9cd6(%rip) # 40f090 <target_start>

variable address is saved to global.

  4053ba:       4c 01 d2                add    %r10,%rdx
  4053bd:       48 89 44 24 d8          mov    %rax,-0x28(%rsp)
  4053c2:       48 c7 05 b3 9c 00 00    movq   $0x18,0x9cb3(%rip) # 40f080 <target_size>
  4053c9:       18 00 00 00 

variable size is saved to global.

  4053cd:       48 89 54 24 e0          mov    %rdx,-0x20(%rsp)
  4053d2:       48 89 44 24 e8          mov    %rax,-0x18(%rsp)
  4053d7:       48 89 54 24 f0          mov    %rdx,-0x10(%rsp)
  4053dc:       45 84 c9                test   %r9b,%r9b
  4053df:       75 1d                   jne    4053fe <leaf_small_hole_static_all.constprop.0+0x8e>
  4053e1:       48 8b 44 24 c8          mov    -0x38(%rsp),%rax
  4053e6:       66 0f 6f 44 24 b8       movdqa -0x48(%rsp),%xmm0
  4053ec:       48 89 05 bd 9c 00 00    mov    %rax,0x9cbd(%rip) # 40f0b0 <check_buf+0x10>
  4053f3:       44 89 c0                mov    %r8d,%eax
  4053f6:       0f 29 05 a3 9c 00 00    movaps %xmm0,0x9ca3(%rip) # 40f0a0 <check_buf>

Here's the unrolled memcpy (8 bytes and 16 bytes) to the global buffer,
taking the "uninitialized" padding with it.

  4053fd:       c3                      ret    

-- 
Kees Cook
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stackinit.c
Type: text/x-csrc
Size: 12763 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210713/c3b647e1/attachment-0001.bin>