linux-kernel - Re: objtool warnings for kernel/trace/trace_selftest

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: <20181218140105.ajuiglkpvstt3qxs@treble>
Date:   Tue, 18 Dec 2018 08:01:05 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Martin Jambor <mjambor@...e.cz>
Cc:     Miroslav Benes <mbenes@...e.cz>, Andi Kleen <ak@...ux.intel.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o

On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote:
> OK, I have read through it and with the caveats that I don't quite
> understand what the failure is, that also believe attribute noclone
> should not affect frame pointer generation, and that I don't quite get
> how LTO comes into play, my comments are the following:
> 
> I am the developer who introduced attribute noclone to GCC and also the
> one who advises against using it :-) ...at least without also using the
> noinline attribute, the combination means "I want only one or zero
> copies of this function in the compiled assembly" which you might need
> if you do fancy stuff in inline assembly, for example.
> 
> I believe that when people use noclone on its own, in 99 out 100 cases
> they actually want something else.  Usually there is something that
> references the function from code (such as assembly) or a tool that the
> compiler does know about and then they should use the "used" attribute.
> That is what I understood to be the use case here and therefore I
> recommended it.  In other cases people want all inter-procedural (IPA)
> analyses to stay away from a function and then they should use attribute
> noipa (or in older GCCs, the combination of noinline and noclone).
> 
> The attribute was introduced because it is useful in GCC testsuite, and
> although I think occasions when it is useful on its own elsewhere are
> very rare and quite obscure, they can happen.  But it really only means
> you want only one or zero *non-inlined* copies of the function.  For
> example if you have an asm in it that must appear in the compiled
> assembly only once but you are confident it will be optimized out in
> inlined instances.  Or if you play games with __builtin_return_address()
> and somehow have a very clear idea what the return values should be.
> 
> I'm afraid I cannot give an opinion what you should do in this case
> without understanding the problem better.  If you can isolate the case
> where noclone behaves weirdly into a self-contained testcase, I'd be
> happy to have a look at it.

I whittled it down to a small test case.  It turns out the problem is
caused by the "__optimize__("no-tracer")" atribute, which is used by our
__noclone macro:


# if __has_attribute(__optimize__)
#  define __noclone                     __attribute__((__noclone__, __optimize__("no-tracer")))
# else
#  define __noclone                     __attribute__((__noclone__))
# endif


Here's the test case.  Notice it skips the frame pointer setup before
the call to __sanitizer_cov_trace_pc():


$ cat test.c
__attribute__((__optimize__("no-tracer"))) int test(void)
{
	return 0;
}
$ gcc -O2 -fno-omit-frame-pointer -fsanitize-coverage=trace-pc -c -o test.o test.c
$ objdump -dr test.o

test.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <test>:
   0:	48 83 ec 08          	sub    $0x8,%rsp
   4:	e8 00 00 00 00       	callq  9 <test+0x9>
			5: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
   9:	31 c0                	xor    %eax,%eax
   b:	48 83 c4 08          	add    $0x8,%rsp
   f:	c3                   	retq   



It works if you remove the function attribute:

0000000000000000 <test>:
   0:	55                   	push   %rbp
   1:	48 89 e5             	mov    %rsp,%rbp
   4:	e8 00 00 00 00       	callq  9 <test+0x9>
			5: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
   9:	31 c0                	xor    %eax,%eax
   b:	5d                   	pop    %rbp
   c:	c3                   	retq




Apparently we are using "no-tracer" because of:


commit 95272c29378ee7dc15f43fa2758cb28a5913a06d
Author: Paolo Bonzini <pbonzini@...hat.com>
Date:   Thu Mar 31 09:38:51 2016 +0200

    compiler-gcc: disable -ftracer for __noclone functions

    -ftracer can duplicate asm blocks causing compilation to fail in
    noclone functions.  For example, KVM declares a global variable
    in an asm like

        asm("2: ... \n
             .pushsection data \n
             .global vmx_return \n
             vmx_return: .long 2b");

    and -ftracer causes a double declaration.

    Cc: Andrew Morton <akpm@...ux-foundation.org>
    Cc: Michal Marek <mmarek@...e.cz>
    Cc: stable@...r.kernel.org
    Cc: kvm@...r.kernel.org
    Reported-by: Linda Walsh <lkml@...nx.org>
    Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>


-- 
Josh