From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH] task_struct: Only use anon struct under randstruct plugin
Date: Tue, 27 Mar 2018 14:22:31 -1000 [thread overview]
Message-ID: <CA+55aFzi0aUGuxDOwj1HkrP6r2Df2jk5F0HDTOQCG6_eeytbYw@mail.gmail.com> (raw)
In-Reply-To: <20180327160342.e2bc9a15afda5823c8daf4fb@linux-foundation.org>
On Tue, Mar 27, 2018 at 1:03 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> Why? What caused this padding? It happens in all configs?
I assume what happens is that the anonymous struct ends up containing
fields that are cacheline-aligned, and then the whole anonymous struct
is cacheline-aligned.
Which is all kinds of stupid, since the anonymous struct itself does
not exist outside of the outer struct. So it would be entirely
sufficient to just make the outer struct cacheline aligned (like it
used to be), but not align the inner anonymous one - just the fields
in it.
But there may be "reasons" why the inner anonymous one needs to be
aligned. Maybe it's some standards requirement, or maybe it's just an
internal gcc implementation detail.
Regardless, it's a bit sad. It also means that when randomization is
on, that unnecessary padding will be there.
I wonder if there is some acceptable trick to avoid it. Maybe the
anonymous struct can be marked as not needing alignment, even if the
fields inside of it would still need to be aligned wrt the outer
struct.
>> Instead,
>> move the anonymous struct to being only used when struct layout
>> randomization is enabled.
>
> So the mysterious 40 byte bloat is still present in this case?
Almost certainly. And the struct randomization will possibly add much
*more* padding elsewhere, since at least some of our structures are
laid out to try to avoid padding, and then the randomization might be
breaking that.
Linus
next prev parent reply other threads:[~2018-03-28 0:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-27 21:36 [PATCH] task_struct: Only use anon struct under randstruct plugin Kees Cook
2018-03-27 23:03 ` Andrew Morton
2018-03-28 0:22 ` Linus Torvalds [this message]
2018-03-28 9:51 ` Peter Zijlstra
2018-03-28 0:30 ` Kees Cook
2018-03-28 1:34 ` Andrew Morton
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=CA+55aFzi0aUGuxDOwj1HkrP6r2Df2jk5F0HDTOQCG6_eeytbYw@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
/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 NNTP newsgroup(s).