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.1903262321390.1789@nanos.tec.linutronix.de>
Date:   Tue, 26 Mar 2019 23:25:45 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andi Kleen <ak@...ux.intel.com>
cc:     Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as
 .text

Andi.

On Tue, 26 Mar 2019, Andi Kleen wrote:
> On Tue, Mar 26, 2019 at 06:03:59PM +0100, Thomas Gleixner wrote:
> > On Thu, 21 Mar 2019, Andi Kleen wrote:
> > 
> > > With gcc 8 toplevel assembler statements that do not mark themselves
> > > as .text may end up in other sections.
> > 
> > Which is clearly a change in behaviour. Is that intended or just yet
> > another feature of GCC?
> 
> I'm not sure it's a new behavior, but I've seen it first
> with gcc 8.

Ok.

> > Your subject says: 'x86, lto:'
> > 
> > So is this a LTO related problem or is the section randomization
> > independent of LTO?
> 
> The basic behavior is independent of LTO, but I've only seen
> failures with LTO. But I believe in theory it could lead
> to failures even without LTO.

Well, we better should know the real reason for this wreckage. I mean, the
default section for text is suprisingly .text. I don't see a reason why
this would be any different for an assembly function implemented in a C
file.

So the question is whether GCC does something silly in general which gets
'repaired' silentely by the linker or whether it's just an LTO issue.

If it's the former, then we must backport those fixes.

Could you please verify with the GCC people as you seem to have a
reproducer of some sort.

Thanks,

	tglx