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]

Date:   Tue, 26 Mar 2019 17:55:24 -0700
From:   Andi Kleen <andi@...stfloor.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andi Kleen <ak@...ux.intel.com>, 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

> 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.

What happens is that when the function before the asm changes
the section, gcc only changes it back for the next function/variable
with a different section. But it doesn't change it back for the asm.

e.g. here

__attribute__((section("foo"))) void func(void)
{
}

asm("foo:\n");

gives with gcc -S (might be different with optimization):

 .section foo,"ax",@progbits <----------------- sets the section
 .globl func
 .type func, @function
func:
.LFB0:
 .cfi_startproc
 pushq %rbp
 .cfi_def_cfa_offset 16
 .cfi_offset 6, -16
 movq %rsp, %rbp
 .cfi_def_cfa_register 6
 nop
 popq %rbp
 .cfi_def_cfa 7, 8
 ret
 .cfi_endproc
.LFE0:
 .size func, .-func
<--------------------------- no section reset before the asm
#APP
 foo:

 .ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)"
 .section .note.GNU-stack,"",@progbits

> 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.

The linker has no idea about the boundaries between functions and toplevel
asms. So if gcc doesn't reset the section they stay in the same.

My LTO build was just unlucky I think because it ended up with
asm next to initcall function, which is likely not common.

But gcc reorders functions even without LTO inside files,
so it could eventually happen.

> 
> 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.

Okay. I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89839

I thought I had already done that, but it seems I didn't.

-Andi