linux-kernel - Re: new objtool warnings again...

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: <20160923211437.bnp6qqwafvyp5kek@treble>
Date:   Fri, 23 Sep 2016 16:14:37 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 01:33:45PM -0700, Linus Torvalds wrote:
> Josh,
> 
>  the current F24 toolchain causes
> 
>     kernel/signal.o: warning: objtool: .altinstr_replacement+0x54:
> call without frame pointer save/setup
> 
> during a regular allmodconfig build.
> 
> Doing an objdump says:
> 
> ...
>   54:   e8 00 00 00 00          callq  59 <.altinstr_replacement+0x59>
>                         55: R_X86_64_PC32       copy_user_generic_string-0x4
>   59:   e8 00 00 00 00          callq  5e <.altinstr_replacement+0x5e>
>                         5a: R_X86_64_PC32
> copy_user_enhanced_fast_string-0x4
> ...
> 
> so it seems to come from the alternative_call_2() in copy_user_generic().
> 
> It's somewhere in copy_siginfo_to_user(), so I assume it's just the
> 
>         if (from->si_code < 0)
>                 return __copy_to_user(to, from, sizeof(siginfo_t))
>                         ? -EFAULT : 0;
> 
> case.  Looking at the code generation, it looks like the frame pointer
> generation in that function has been moved down past this code, so the
> objtool warning seems to be correct, but this indicates that gcc has
> decided that we don't need a frame for that alternative_call_2()
> thing.
> 
> So this code is clearly missing the magic to tell gcc that the asm
> needs a frame pointer.
> 
> What was that magic again? Mind sending a patch?

Is this with your latest pushed master branch?  I have F24, but I don't
see the warning.

In any case, I'll come up with a patch for you to test.

-- 
Josh