linux-kernel - Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions

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: <20220521105704.GE2578@worktop.programming.kicks-ass.net>
Date:   Sat, 21 May 2022 12:57:04 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "aik@...abs.ru" <aik@...abs.ru>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "naveen.n.rao@...ux.vnet.ibm.com" <naveen.n.rao@...ux.vnet.ibm.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        Sathvika Vasireddy <sv@...ux.ibm.com>
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions

On Sat, May 21, 2022 at 09:38:35AM +0000, Christophe Leroy wrote:

> I gave it a try this morning, I selected HAVE_OBJTOOL and 
> HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
> 
> 
> Seems like there are still some x86 arch specific stuff in common common 
> code and I get the following errors.

I'm assuming there's a metric ton of x86 specific stuff in there.
That'll take a while to clean out.

Mostly Josh's rewrite was centered around splitting out the runtime
options, but objtool is still always build with all options included,
even the ones you're not using for your arch, which is what's triggering
the problems you see here, I suppose...

> Also, is it normal to get those functions built allthough I have not 
> selected HAVE_STACK_VALIDATION ?
> 
>    CC      /home/chleroy/linux-powerpc/tools/objtool/check.o
> check.c: In function 'has_valid_stack_frame':
> check.c:2369:30: error: 'CFI_BP' undeclared (first use in this 
> function); did you mean 'CFI_SP'?
>   2369 |         if (cfi->cfa.base == CFI_BP &&
>        |                              ^~~~~~
>        |                              CFI_SP
> check.c:2369:30: note: each undeclared identifier is reported only once 
> for each function it appears in
> check.c:2371:44: error: 'CFI_RA' undeclared (first use in this 
> function); did you mean 'CFI_R3'?
>   2371 |             check_reg_frame_pos(&cfi->regs[CFI_RA], 
> -cfi->cfa.offset + 8))
>        |                                            ^~~~~~
>        |                                            CFI_R3
> check.c: In function 'update_cfi_state':
> check.c:2499:70: error: 'CFI_BP' undeclared (first use in this 
> function); did you mean 'CFI_SP'?
>   2499 |                         if (op->src.reg == CFI_SP && 
> op->dest.reg == CFI_BP &&
>        | 
>        ^~~~~~
>        | 
>        CFI_SP
> make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97: 
> /home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
> make[2]: *** [Makefile:54: 
> /home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
> make[1]: *** [Makefile:69: objtool] Error 2
> make: *** [Makefile:1337: tools/objtool] Error 2
> 
> 
> What would be the best approach to fix that ?

Define CFI_BP to your frame register (r2, afaict) I suppose. If you're
only using OBJTOOL_MCOUNT this code will never run, so all you have to
ensure is that it compiles, not that it makes sense (-:

The very long and complicated way would be to propagate the various
CONFIG_HAVE_* build time things to the objtool build and librally
sprinkle a lot of #ifdef around.