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]

Date:	Fri, 14 Feb 2014 15:47:00 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Stefan Bader <stefan.bader@...onical.com>
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 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!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/