linux-kernel - Re: Another preempt folding issue?

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: <52FE4C28.1080500@canonical.com>
Date:	Fri, 14 Feb 2014 18:02:32 +0100
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kvm@...r.kernel.org, Marcelo Tosatti <mtosatti@...hat.com>,
	MASAO TAKAHASHI <masao-takahashi@...no.co.jp>,
	Joerg Roedel <joro@...tes.org>
Subject: Re: Another preempt folding issue?

On 14.02.2014 15:47, Borislav Petkov wrote:
> On Fri, Feb 14, 2014 at 03:24:09PM +0100, Stefan Bader wrote:
>> Actually, this code just makes so much more sense if I let objdump do
>> relocation info...
> 
> Ok, we're pretty sure you have an MFENCE there in resched_task but can
> you confirm it please.
> 
> First, does /proc/cpuinfo have the "sse2" string? It should but nowadays
> I don't trust anything.
> 
> Then, can you boot that kernel in qemu with the -gdb flag so that it
> starts the gdb stub, here's the manpage about it:
> 
>        -gdb dev
>            Wait for gdb connection on device dev. Typical connections will likely be
>            TCP-based, but also UDP, pseudo TTY, or even stdio are reasonable use case.
>            The latter is allowing to start QEMU from within gdb and establish the
>            connection via a pipe:
> 
>                    (gdb) target remote | exec qemu-system-i386 -gdb stdio ...
> 
>        -s  Shorthand for -gdb tcp::1234, i.e. open a gdbserver on TCP port 1234.
> 
> then boot the guest and when it is up, do
> 
> $ gdb ./vmlinux
> $ target remote localhost:1234
> 
> and type in the prompt
> 
> $ (gdb) x/50i resched_task
> 
> It gives here:
> 
> (gdb) x/50i resched_task
>    0xffffffff810836f0 <resched_task>:   data32 data32 data32 xchg %ax,%ax
>    0xffffffff810836f5 <resched_task+5>: push   %rbp
>    0xffffffff810836f6 <resched_task+6>: mov    0x85e123(%rip),%r10d        # 0xffffffff818e1820 <debug_locks>
>    0xffffffff810836fd <resched_task+13>:        mov    %rsp,%rbp
>    0xffffffff81083700 <resched_task+16>:        push   %r12
>    0xffffffff81083702 <resched_task+18>:        test   %r10d,%r10d
>    0xffffffff81083705 <resched_task+21>:        push   %rbx
>    0xffffffff81083706 <resched_task+22>:        mov    %rdi,%rbx
>    0xffffffff81083709 <resched_task+25>:        jne    0xffffffff81083760 <resched_task+112>
>    0xffffffff8108370b <resched_task+27>:        mov    0x8(%rbx),%rax
>    0xffffffff8108370f <resched_task+31>:        mov    0x10(%rax),%rdx
>    0xffffffff81083713 <resched_task+35>:        and    $0x8,%edx
>    0xffffffff81083716 <resched_task+38>:        jne    0xffffffff8108373c <resched_task+76>
>    0xffffffff81083718 <resched_task+40>:        lock orb $0x8,0x10(%rax)
>    0xffffffff8108371d <resched_task+45>:        mov    0x8(%rbx),%rax
>    0xffffffff81083721 <resched_task+49>:        mov    0x18(%rax),%r12d
>    0xffffffff81083725 <resched_task+53>:        callq  0xffffffff812d8fc0 <debug_smp_processor_id>
>    0xffffffff8108372a <resched_task+58>:        cmp    %r12d,%eax
>    0xffffffff8108372d <resched_task+61>:        je     0xffffffff810837a0 <resched_task+176>
>    0xffffffff8108372f <resched_task+63>:        mfence
>    						^^^^^^
> I want to make sure the smp_mb() is really replaced with an MFENCE there.
> 
> Thanks!
> 
Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu info. And
there is a mfence in the disassembly:

   0xc107dcb0 <resched_task>:	push   %ebp
   0xc107dcb1 <resched_task+1>:	mov    %esp,%ebp
   0xc107dcb3 <resched_task+3>:	lea    %ds:0x0(%esi,%eiz,1),%esi
   0xc107dcb8 <resched_task+8>:	mov    0x4(%eax),%edx
   0xc107dcbb <resched_task+11>:	mov    0x8(%edx),%ecx
   0xc107dcbe <resched_task+14>:	and    $0x8,%ecx
   0xc107dcc1 <resched_task+17>:	jne    0xc107dce7 <resched_task+55>
   0xc107dcc3 <resched_task+19>:	orb    $0x8,%ds:0x8(%edx)
   0xc107dcc8 <resched_task+24>:	mov    0x4(%eax),%edx
   0xc107dccb <resched_task+27>:	mov    %fs:0xc1a71010,%ecx
   0xc107dcd2 <resched_task+34>:	mov    0x10(%edx),%edx
   0xc107dcd5 <resched_task+37>:	cmp    %ecx,%edx
   0xc107dcd7 <resched_task+39>:	je     0xc107dd00 <resched_task+80>
   0xc107dcd9 <resched_task+41>:	mfence
   0xc107dcdc <resched_task+44>:	mov    %esi,%esi
   0xc107dcde <resched_task+46>:	mov    0x4(%eax),%eax
   0xc107dce1 <resched_task+49>:	testb  $0x4,0xc(%eax)
   0xc107dce5 <resched_task+53>:	je     0xc107dcf0 <resched_task+64>
   0xc107dce7 <resched_task+55>:	pop    %ebp
   0xc107dce8 <resched_task+56>:	ret
   0xc107dce9 <resched_task+57>:	lea    0x0(%esi,%eiz,1),%esi
   0xc107dcf0 <resched_task+64>:	mov    %edx,%eax
   0xc107dcf2 <resched_task+66>:	call   *0xc1917950
   0xc107dcf8 <resched_task+72>:	pop    %ebp

Thinking about it, I guess Peter is quite right saying that I likely will end on
the patch that converted preempt_count to percpu.

One thing I likely should do is to reinstall the exact same laptop with 64bit
kernel and userspace... maybe only 64bit kernel first... and make sure on my
side that this does not show up on 64bit, too. I took the word of reporters for
that (and the impression that otherwise many more people would have complained).



Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)