linux-kernel - Re: [tip:x86/alternatives 14/14] arch/x86/kvm/kvm.o: warning: objtool: .altinstr_replacement+0xc5: call without frame pointer save/setup

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: <ZnGYsdiOYjLJBX1n@google.com>
Date: Tue, 18 Jun 2024 07:24:49 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Borislav Petkov <bp@...en8.de>, kernel test robot <lkp@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [tip:x86/alternatives 14/14] arch/x86/kvm/kvm.o: warning:
 objtool: .altinstr_replacement+0xc5: call without frame pointer save/setup

On Tue, Jun 18, 2024, Peter Zijlstra wrote:
> On Fri, Jun 14, 2024 at 05:22:28PM +0200, Borislav Petkov wrote:
> > On Fri, Jun 14, 2024 at 04:15:14PM +0800, kernel test robot wrote:
> You sure? Afaict the thing is:
> 
> $ OBJTOOL_ARGS="--verbose" make O=tmp-build/ arch/x86/kvm/
> ...
> arch/x86/kvm/kvm.o: warning: objtool: .altinstr_replacement+0xc5: call without frame pointer save/setup
> arch/x86/kvm/kvm.o: warning: objtool:   em_loop.part.0+0x29: (alt)
> arch/x86/kvm/kvm.o: warning: objtool:   em_loop.part.0+0x0: <=== (sym)
> 0000 0000000000028220 <em_loop.part.0>:
> 0000    28220:  0f b6 47 61             movzbl 0x61(%rdi),%eax
> 0004    28224:  3c e2                   cmp    $0xe2,%al
> 0006    28226:  74 2c                   je     28254 <em_loop.part.0+0x34>
> 0008    28228:  48 8b 57 10             mov    0x10(%rdi),%rdx
> 000c    2822c:  83 f0 05                xor    $0x5,%eax
> 000f    2822f:  48 c1 e0 04             shl    $0x4,%rax
> 0013    28233:  25 f0 00 00 00          and    $0xf0,%eax
> 0018    28238:  81 e2 d5 08 00 00       and    $0x8d5,%edx
> 001e    2823e:  80 ce 02                or     $0x2,%dh
> 0021    28241:  48 05 00 00 00 00       add    $0x0,%rax        28243: R_X86_64_32S     em_setcc
> 0027    28247:  52                      push   %rdx
> 0028    28248:  9d                      popf
> 0029    28249:  ff d0                   call   *%rax
> 002b    2824b:  90                      nop
> 002c    2824c:  90                      nop
> 002d    2824d:  90                      nop
> 002e    2824e:  31 d2                   xor    %edx,%edx
> 0030    28250:  84 c0                   test   %al,%al
> 0032    28252:  74 1d                   je     28271 <em_loop.part.0+0x51>
> 0034    28254:  55                      push   %rbp
> 0035    28255:  48 63 b7 d0 00 00 00    movslq 0xd0(%rdi),%rsi
> 003c    2825c:  48 03 b7 90 00 00 00    add    0x90(%rdi),%rsi
> 0043    28263:  48 89 e5                mov    %rsp,%rbp
> 0046    28266:  e8 05 fe ff ff          call   28070 <assign_eip>
> 004b    2826b:  5d                      pop    %rbp
> 004c    2826c:  e9 00 00 00 00          jmp    28271 <em_loop.part.0+0x51>      2826d: R_X86_64_PLT32   __x86_return_thunk-0x4
> 0051    28271:  89 d0                   mov    %edx,%eax
> 0053    28273:  e9 00 00 00 00          jmp    28278 <em_loop.part.0+0x58>      28274: R_X86_64_PLT32   __x86_return_thunk-0x4
> 0058    28278:  0f 1f 84 00 00 00 00 00         nopl   0x0(%rax,%rax,1)
> 
> Which is in fact test_cc() from em_loop().
> 
> Now, that .config is a FRAME_POINTER build, and the fast-call thing
> don't do frames, so it is right to complain. Big question is why it
> didn't complain previously I suppose.
> 
> Also, notably, this patch:
> 
>   https://lkml.kernel.org/r/20231204093732.323101886@infradead.org
> 
> cures things.

Speaking of that series, do you need/want any help pushing it along?  I ran into
build issues[*] and didn't have the cycles to fully figure things out at the time.
 
  This fails for some of my builds that end up with CONFIG_OBJTOOl=n.  Adding a
  stub for ASM_ANNOTATE() gets me past that:
  
  @@ -156,6 +171,7 @@
   #define STACK_FRAME_NON_STANDARD(func)
   #define STACK_FRAME_NON_STANDARD_FP(func)
   #define ANNOTATE_NOENDBR
  +#define ASM_ANNOTATE(x)
   #define ASM_REACHABLE
   #else
   #define ANNOTATE_INTRA_FUNCTION_CALL
  
  but then I run into other issues:
  
  arch/x86/kernel/relocate_kernel_32.S: Assembler messages:
  arch/x86/kernel/relocate_kernel_32.S:96: Error: Parameter named `type' does not exist for macro `annotate'
  arch/x86/kernel/relocate_kernel_32.S:166: Error: Parameter named `type' does not exist for macro `annotate'
  arch/x86/kernel/relocate_kernel_32.S:174: Error: Parameter named `type' does not exist for macro `annotate'
  arch/x86/kernel/relocate_kernel_32.S:200: Error: Parameter named `type' does not exist for macro `annotate'
  arch/x86/kernel/relocate_kernel_32.S:220: Error: Parameter named `type' does not exist for macro `annotate'
  arch/x86/kernel/relocate_kernel_32.S:285: Error: Parameter named `type' does not exist for macro `annotate'

[*] https://lore.kernel.org/all/ZXEEbrI7K6XGr2dN@google.com