From: Kees Cook <keescook@chromium.org>
To: Joe Perches <joe@perches.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Dan Carpenter <error27@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
zhanglin <zhang.lin16@zte.com.cn>
Subject: Re: [PATCH] kernel: sys.c: Avoid copying possible padding bytes in copy_to_user
Date: Mon, 28 Oct 2019 11:58:34 -0700 [thread overview]
Message-ID: <201910281153.7B6F79DBD@keescook> (raw)
In-Reply-To: <92212e57d45f4410be654183f5dcb1e98d636ef2.camel@perches.com>
On Sun, Oct 27, 2019 at 03:47:21PM -0700, Joe Perches wrote:
> I think yes as at least it makes it consistent.
>
> From the link above, as I understand the __user
> gcc extension here
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c61f13eaa1ee17728c41370100d2d45c254ce76f
>
> gcc does not clear padding from initialized structs
> marked with __user.
It seems to depend on how complete the initialization is and/or how
large the structure is. AFAICT, based on the tests I wrote[1], if
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF (or ..._ALL) are used, even padding
will get initialized as long as things are in memory. (And the same is
true with Clang under CONFIG_INIT_STACK_ALL.)
> Though that doesn't force the compiler to not
> perform the possible register optimization shown
> in the first document above.
Right. This is the only case where things aren't clear. I haven't been
able to build a test where "store in registers" behavior is tripped.
-Kees
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/test_stackinit.c
--
Kees Cook
next prev parent reply other threads:[~2019-10-28 18:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-26 19:46 [PATCH] kernel: sys.c: Avoid copying possible padding bytes in copy_to_user Joe Perches
2019-10-27 5:47 ` Julia Lawall
2019-10-27 22:47 ` Joe Perches
2019-10-28 7:30 ` Dan Carpenter
2019-10-28 18:58 ` Kees Cook [this message]
2019-10-28 7:18 ` Dan Carpenter
2019-10-28 8:08 ` Joe Perches
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=201910281153.7B6F79DBD@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=error27@gmail.com \
--cc=joe@perches.com \
--cc=julia.lawall@lip6.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=zhang.lin16@zte.com.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.