linux-kernel - Re: [PATCH] task_struct: Only use anon struct under randstruct plugin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzi0aUGuxDOwj1HkrP6r2Df2jk5F0HDTOQCG6_eeytbYw@mail.gmail.com>
Date:   Tue, 27 Mar 2018 14:22:31 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] task_struct: Only use anon struct under randstruct plugin

On Tue, Mar 27, 2018 at 1:03 PM, Andrew Morton
<akpm@...ux-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