linux-kernel - Re: [PATCH 0/8] linker-section array fix and clean ups

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 23 Nov 2020 11:39:33 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Jessica Yu <jeyu@...nel.org>
Cc:     Johan Hovold <johan@...nel.org>, linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        David Miller <davem@...emloft.net>,
        Jakub Jelinek <jakub@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Kurtz <djkurtz@...omium.org>,
        linux-arch@...r.kernel.org, linux-m68k@...ts.linux-m68k.org
Subject: Re: [PATCH 0/8] linker-section array fix and clean ups

On Fri, Nov 13, 2020 at 03:18:36PM +0100, Johan Hovold wrote:
> On Wed, Nov 11, 2020 at 04:47:16PM +0100, Jessica Yu wrote:
> 
> > Thanks for providing the links and references. Your explanation and
> > this reply from Jakub [1] clarified things for me. I was not aware of
> > the distinction gcc made between aligned attributes on types vs. on
> > variables. So from what I understand now, gcc suppresses the
> > optimization when the alignment is specified in the variable
> > declaration, but not necessarily when the aligned attribute is just on
> > the type.
> > 
> > Even though it's been in use for a long time, I think it would be
> > really helpful if this gcc quirk was explained just a bit more in the
> > patch changelogs, especially since this is undocumented behavior.
> > I found the explanation in [1] (as well as in your cover letter) to be
> > sufficient. Maybe something like "GCC suppresses any optimizations
> > increasing alignment when the alignment is specified in the variable
> > declaration, as opposed to just on the type definition. Therefore,
> > explicitly specify type alignment when declaring entries to prevent
> > gcc from increasing alignment."
> 
> Sure, I can try to expand the commit messages a bit.

I've amended the commit messages of the relevant patches to make it more
clear that the optimisation can be suppressed by specifying alignment
when declaring variables, but without making additional claims about the
type attribute. I hope the result is acceptable to you.

Perhaps you can include a lore link to the patches when applying so that
this thread can be found easily if needed.

Johan