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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250218132855.GE40464@noisy.programming.kicks-ass.net>
Date: Tue, 18 Feb 2025 14:28:55 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
	oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: ERROR: modpost: "kmsan_handle_dma"
 [drivers/virtio/virtio_ring.ko] undefined!

On Tue, Feb 18, 2025 at 12:48:57PM +0100, Sebastian Andrzej Siewior wrote:
> 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
> 

> 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

This, objtool doesn't track this one. It only does:

 mov %rsp, reg

 mov reg, %rsp

I'm not entirely sure how painful it would be to teach objtool about
this case. Horrible code it is :/

> |   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