From: Qing Zhao <qing.zhao@oracle.com>
To: Kees Cook <keescook@chromium.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
Richard Sandiford <richard.sandiford@arm.com>,
gcc-patches Qing Zhao via <gcc-patches@gcc.gnu.org>
Subject: Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
Date: Mon, 12 Jul 2021 20:28:55 +0000 [thread overview]
Message-ID: <80CAE4C0-237B-4F1A-9569-7EC789563CB8@oracle.com> (raw)
In-Reply-To: <202107121030.295D4E590@keescook>
Hi, Kees,
Thanks a lot for your testing on kernel testing cases.
I have some question in below:
> On Jul 12, 2021, at 12:56 PM, Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Jul 07, 2021 at 05:38:02PM +0000, Qing Zhao wrote:
>> Hi,
>>
>> This is the 4th version of the patch for the new security feature for GCC.
>>
>> I have tested it with bootstrap on both x86 and aarch64, regression testing on both x86 and aarch64.
>> Also compile and run CPU2017, without any issue.
>>
>> Please take a look and let me know your comments and suggestions.
>
> Thanks for the update!
>
> It looks like padding initialization has regressed to where things where
> in version 1[1] (it was, however, working in version 2[2]). I'm seeing
> these failures again in the kernel self-test:
>
> test_stackinit: small_hole_static_all FAIL (uninit bytes: 3)
> test_stackinit: big_hole_static_all FAIL (uninit bytes: 61)
> test_stackinit: trailing_hole_static_all FAIL (uninit bytes: 7)
> test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3)
> test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61)
> test_stackinit: trailing_hole_dynamic_all FAIL (uninit bytes: 7)
Are the above failures for -ftrivial-auto-var-init=zero or -ftrivial-auto-var-init=pattern? Or both?
For the current implementation, I believe that all paddings should be initialized with this option,
for -ftrivial-auto-var-init=zero, the padding will be initialized to zero as before, however, for
-ftrivial-auto-var-init=pattern, the padding will be initialized to 0xFE byte-repeatable patterns.
>
> In looking at the gcc test cases, I think the wrong thing is
> being checked: we want to verify the padding itself. For example,
> in auto-init-17.c, the actual bytes after "four" need to be checked,
> rather than "four" itself.
******For the current auto-init-17.c
1 /* Verify zero initialization for array type with structure element with
2 padding. */
3 /* { dg-do compile } */
4 /* { dg-options "-ftrivial-auto-var-init=zero" } */
5
6 struct test_trailing_hole {
7 int one;
8 int two;
9 int three;
10 char four;
11 /* "sizeof(unsigned long) - 1" byte padding hole here. */
12 };
13
14
15 int foo ()
16 {
17 struct test_trailing_hole var[10];
18 return var[2].four;
19 }
20
21 /* { dg-final { scan-assembler "movl\t\\\$0," } } */
22 /* { dg-final { scan-assembler "movl\t\\\$20," } } */
23 /* { dg-final { scan-assembler "rep stosq" } } */
~
******We have the assembly as: (-ftrivial-auto-var-init=zero)
.file "auto-init-17.c"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $40, %rsp
leaq -160(%rbp), %rax
movq %rax, %rsi
movl $0, %eax
movl $20, %edx
movq %rsi, %rdi
movq %rdx, %rcx
rep stosq
movzbl -116(%rbp), %eax
movsbl %al, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section .note.GNU-stack,"",@progbits
From the above, we can see, “zero” will be used to initialize 8 * 20 = 16 * 10 bytes of memory starting from the beginning of “var”, that include all the padding holes inside
This array of structure.
I didn’t see issue with padding initialization here.
Do I miss anything here?
For pattern initialization, since we currently initialize all paddings with 0xFE byte-repeatable patterns, if the testing case still assumes zero initialization, then the testing cases
Need to be updated with this fact.
> For example, something like this:
>
> struct test_trailing_hole {
> int one;
> int two;
> int three;
> char four;
> /* "sizeof(unsigned long) - 1" byte padding hole here. */
> };
>
> #define offsetofend(STRUCT, MEMBER) \
> (__builtin_offsetof(STRUCT, MEMBER) + sizeof((((STRUCT *)0)->MEMBER)))
>
> int foo ()
> {
> struct test_trailing_hole var[10];
> unsigned char *ptr = (unsigned char *)&var[2];
> int i;
>
> for (i = 0; i < sizeof(var[2]) - offsetofend(typeof(var[2]), four); i++) {
> if (ptr[i] != 0)
> return 1;
> }
> return 0;
> }
>
> But this isn't actually sufficient because they may _accidentally_
> be zero already. The kernel tests specifically make sure to fill the
> about-to-be-used stack with 0xff before calling a function like foo()
> above.
>
> (And as an aside, it seems like naming the test cases with some details
> about what is being tested in the filename would be nice -- it was
> a little weird having to dig through their numeric names to find the
> padding tests.)
Yes, I will fix the testing names to more reflect the testing details.
thanks.
Qing
>
> Otherwise, this looks like it's coming along; I remain very excited!
> Thank you for sticking with it. :)
>
> -Kees
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565840.html
> [2] https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567754.html
>
> --
> Kees Cook
next prev parent reply other threads:[~2021-07-12 20:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 17:38 Qing Zhao
2021-07-08 13:29 ` Martin Jambor
2021-07-08 15:00 ` Qing Zhao
2021-07-08 21:10 ` Qing Zhao
2021-07-09 16:18 ` Martin Jambor
2021-07-09 18:52 ` Qing Zhao
2021-07-12 7:51 ` Richard Sandiford
2021-07-12 15:31 ` Qing Zhao
2021-07-12 17:06 ` Martin Jambor
2021-07-12 18:13 ` Qing Zhao
2021-07-12 17:56 ` Kees Cook
2021-07-12 20:28 ` Qing Zhao [this message]
2021-07-13 21:29 ` Kees Cook
2021-07-13 23:09 ` Kees Cook
2021-07-13 23:16 ` Qing Zhao
2021-07-14 2:42 ` Kees Cook
2021-07-14 7:14 ` Richard Biener
2021-07-14 14:09 ` Qing Zhao
2021-07-14 19:11 ` Kees Cook
2021-07-14 19:30 ` Qing Zhao
2021-07-14 21:23 ` Kees Cook
2021-07-14 22:30 ` Qing Zhao
2021-07-15 7:56 ` Richard Biener
2021-07-15 14:16 ` Qing Zhao
2021-07-15 14:45 ` Qing Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80CAE4C0-237B-4F1A-9569-7EC789563CB8@oracle.com \
--to=qing.zhao@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=keescook@chromium.org \
--cc=richard.guenther@gmail.com \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).