linux-kernel - Re: ERROR: modpost: "kmsan_handle_dma" [drivers/virtio/virtio

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250218114857.oBuLvPYs@linutronix.de>
Date: Tue, 18 Feb 2025 12:48:57 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: kernel test robot <lkp@...el.com>
Cc: Peter Zijlstra <peterz@...radead.org>, llvm@...ts.linux.dev,
	oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: ERROR: modpost: "kmsan_handle_dma"
 [drivers/virtio/virtio_ring.ko] undefined!

On 2025-02-15 06:42:36 [+0800], kernel test robot wrote:
> >> arch/x86/kvm/cpuid.o: warning: objtool: do_cpuid_func+0x2428: undefined stack state

I have been staring at this and have no idea what to do. I get here:
| arch/x86/kvm/cpuid.o: warning: objtool: do_cpuid_func+0x21e1: undefined stack state

The assembly at this spot looks as from the .o:
|   110e4:       e8 00 00 00 00          call   110e9 <do_cpuid_func+0x21d9>
|                        110e5: R_X86_64_PLT32   __msan_metadata_ptr_for_load_4-0x4
|   110e9:       44 8b 38                mov    (%rax),%r15d
|   110ec:       48 85 db                test   %rbx,%rbx
|   110ef:       8b 1a                   mov    (%rdx),%ebx
|   110f1:       4c 8b 64 24 18          mov    0x18(%rsp),%r12
^^^ do_cpuid_func+0x21e1

|   110f6:       0f 85 72 01 00 00       jne    1126e <do_cpuid_func+0x235e>
|   110fc:       41 83 e7 fe             and    $0xfffffffe,%r15d
|   11100:       48 89 ef                mov    %rbp,%rdi
|   11103:       e8 00 00 00 00          call   11108 <do_cpuid_func+0x21f8>
|                        11104: R_X86_64_PLT32   __msan_metadata_ptr_for_store_4-0x4

I've been looking at .s file but this does not realy match the .o. The
registers are different, the offsets, too.
Anyway.

Looking at the opcodes it was processing "recently":
base: 4, offset 1109d Dest: 0 Src: 5 lea    0x10(%r14),%rax
base: 4, offset 110a1 Dest: 1 Src: 0 mov    %rax,0x20(%rsp)
base: 4, offset 110ae Dest: 0 Src: 0 mov    %rsp,%r8
base: 4, offset 1124b Dest: 0 Src: 1 mov    0x20(%rsp),%rsi
base: 4, offset 11253 Dest: 0 Src: 1 mov    0x8(%rsp),%rcx
base: 4, offset 11258 Dest: 0 Src: 0 mov    %r15,%rsp
-> set UNDEF
base: -1, offset 110f1 -> mov    0x18(%rsp),%r12
arch/x86/kvm/cpuid.o: warning: objtool: do_cpuid_func+0x21e1: undefined stack state 110f1

From the assembly it seems to make sense:
|   110ae:       49 89 e0                mov    %rsp,%r8
stash for later
|   110b1:       48 85 db                test   %rbx,%rbx
|   110b4:       c7 00 00 00 00 00       movl   $0x0,(%rax)
|   110ba:       45 89 7e 14             mov    %r15d,0x14(%r14)
|   110be:       0f 85 40 01 00 00       jne    11204 <do_cpuid_func+0x22f4>
…
|   11204:       44 8b 74 24 38          mov    0x38(%rsp),%r14d
|   11209:       44 89 f7                mov    %r14d,%edi
|   1120c:       4d 89 c7                mov    %r8,%r15

mov rsp to r15

|   1120f:       e8 00 00 00 00          call   11214 <do_cpuid_func+0x2304>
|                        11210: R_X86_64_PLT32   __msan_chain_origin-0x4
|   11214:       89 c7                   mov    %eax,%edi
|   11216:       e8 00 00 00 00          call   1121b <do_cpuid_func+0x230b>
|                        11217: R_X86_64_PLT32   __msan_warning-0x4
|   1121b:       44 89 f7                mov    %r14d,%edi
|   1121e:       e8 00 00 00 00          call   11223 <do_cpuid_func+0x2313>
|                        1121f: R_X86_64_PLT32   __msan_chain_origin-0x4
|   11223:       89 c7                   mov    %eax,%edi
|   11225:       e8 00 00 00 00          call   1122a <do_cpuid_func+0x231a>
|                        11226: R_X86_64_PLT32   __msan_warning-0x4
|   1122a:       44 89 f7                mov    %r14d,%edi
|   1122d:       e8 00 00 00 00          call   11232 <do_cpuid_func+0x2322>
|                        1122e: R_X86_64_PLT32   __msan_chain_origin-0x4
|   11232:       89 c7                   mov    %eax,%edi
|   11234:       e8 00 00 00 00          call   11239 <do_cpuid_func+0x2329>
|                        11235: R_X86_64_PLT32   __msan_warning-0x4
|   11239:       44 89 f7                mov    %r14d,%edi
|   1123c:       e8 00 00 00 00          call   11241 <do_cpuid_func+0x2331>
|                        1123d: R_X86_64_PLT32   __msan_chain_origin-0x4
|   11241:       89 c7                   mov    %eax,%edi
|   11243:       e8 00 00 00 00          call   11248 <do_cpuid_func+0x2338>
|                        11244: R_X86_64_PLT32   __msan_warning-0x4
|   11248:       4c 89 ef                mov    %r13,%rdi
|   1124b:       48 8b 74 24 20          mov    0x20(%rsp),%rsi
|   11250:       4c 89 e2                mov    %r12,%rdx
|   11253:       48 8b 4c 24 08          mov    0x8(%rsp),%rcx
|   11258:       4c 89 fc                mov    %r15,%rsp

restore rsp. I just don't see how rsp is destroyed but this could be
related to paravirt's xxl clobbing in__cpuid().

I miss 1120c in my output. I don't understand how it jumps from 110ae to
1124b. It misses the assignments in between but this might not be goal
here…

gcc does not cause objtool to produce the warning but then gcc does
shuffle rsp as much as llvm does.

Sebastian