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: <20250218164724.uxcwotv3wgc5y3id@jpoimboe>
Date: Tue, 18 Feb 2025 08:47:24 -0800
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	kernel test robot <lkp@...el.com>, 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 Tue, Feb 18, 2025 at 02:28:55PM +0100, Peter Zijlstra wrote:
> 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 :/
> 
> > 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…

FYI, you can add OBJTOOL_ARGS="--backtrace" or OBJTOOL_VERBOSE=1 to the
cmdline to see how objtool got there.  On my build there were some
ALTERNATIVE()s involved which makes it trickier to follow.

There's definitely some weirdness going on, I'm also seeing the .s not
match the .o.  Maybe it's the __msan_*() stuff.  Still looking...

-- 
Josh