linux-kernel - Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as .text

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]

Message-ID: <alpine.DEB.2.21.1903271958320.1789@nanos.tec.linutronix.de>
Date:   Wed, 27 Mar 2019 20:08:23 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andi Kleen <ak@...ux.intel.com>
cc:     Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as
 .text

On Wed, 27 Mar 2019, Andi Kleen wrote:
> > From the GCC manual:
> > 
> >  "This attribute, attached to a global variable or function, nullifies the
> >   effect of the -fw hole-program command-line option, so the object remains
> >   visible outside the current compilation unit."
> > 
> > Neither the variable nor the data generated are global anymore. This data
> > is only used inside this compilation unit and I don't see why LTO needs a
> > reference outside of it. If so, then I really want to understand WHY
> > exactly.
> 
> The LTO code generation doesn't compile file by file, but reorders
> all the functions and other top level statements into "partitions".
> The partitions are ordered by call graph so that inlining and some
> other optimizations work efficiently
> 
> Then it finally runs multiple copies of the gcc code generator that
> generate code from these partitions, each generating an own assembler file.
> 
> The top level assembler is not part of the call graph that drives
> the partitioning.

There is no top level assembly anymore. It's static data in the .rodata
section which is completely uninteresting for a call graph. That data is
accessed by the C function.

It's static so it's scope is within the file and whatever GCC does with
that C function it has to respect that it accesses static data. If that's
not true then this really needs to be fixed at the compiler side and not in
the kernel.

Thanks,

	tglx