All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Raslan, KarimAllah" <karahmed@amazon.de>
To: "jmattson@google.com" <jmattson@google.com>,
	"dvyukov@google.com" <dvyukov@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"syzbot+cc483201a3c6436d3550@syzkaller.appspotmail.com"
	<syzbot+cc483201a3c6436d3550@syzkaller.appspotmail.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"syzkaller-bugs@googlegroups.com"
	<syzkaller-bugs@googlegroups.com>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>
Subject: Re: general protection fault in vmx_vcpu_run
Date: Sat, 30 Jun 2018 08:09:23 +0000	[thread overview]
Message-ID: <1530346163.13559.75.camel@amazon.de> (raw)
In-Reply-To: <CALMp9eSDP3XRMU-ZvSPRqgyQrtOCajz90HyQ8GM7Mg2oNuBAHw@mail.gmail.com>

Looking also at the other crash [0]:

        msr_bitmap = to_vmx(vcpu)->loaded_vmcs->msr_bitmap;
ffffffff811f65b7:       e8 44 cb 57 00          callq  ffffffff81773100
<__sanitizer_cov_trace_pc>
ffffffff811f65bc:       48 8b 54 24 08          mov    0x8(%rsp),%rdx
ffffffff811f65c1:       48 b8 00 00 00 00 00    movabs
$0xdffffc0000000000,%rax
ffffffff811f65c8:       fc ff df
ffffffff811f65cb:       48 c1 ea 03             shr    $0x3,%rdx
ffffffff811f65cf:       80 3c 02
00             cmpb   $0x0,(%rdx,%rax,1)        <- fault here.
ffffffff811f65d3:       0f 85 36 19 00 00       jne    ffffffff811f7f0f
<vmx_vcpu_run+0x236f>

%rdx should contain a pointer to loaded_vmcs. It is directly loaded 
from the stack [0x8(%rsp)]. This same stack location was just used 
before the inlined assembly for VMRESUME/VMLAUNCH here:

        vmx->__launched = vmx->loaded_vmcs->launched;
ffffffff811f639f:       e8 5c cd 57 00          callq  ffffffff81773100
<__sanitizer_cov_trace_pc>
ffffffff811f63a4:       48 8b 54 24 08          mov    0x8(%rsp),%rdx
ffffffff811f63a9:       48 b8 00 00 00 00 00    movabs
$0xdffffc0000000000,%rax
ffffffff811f63b0:       fc ff df
ffffffff811f63b3:       48 c1 ea 03             shr    $0x3,%rdx
ffffffff811f63b7:       80 3c 02
00             cmpb   $0x0,(%rdx,%rax,1)        <- used here.

... and this stack location was never touched by anything in between! 
So something must have corrupted the stack itself not really the 
kvm_vc
pu struct.

Obviously the inlined assembly block is using the stack as well, but I 
can not see anything that would cause this corruption there.

That being said, looking at the %rsp and %rbp values that are dumped
in the stack trace:

RSP: ffff8801b7d7f380
RBP: ffff8801b8260140

... they are almost 4.8 MiB apart! Should not these two register be a 
bit closer to each other? :)

So 2 possibilities here:

1- %rsp is wrong

That would explain why the loaded_vmcs was NULL. However, it is a bit 
harder to understand how it became wrong! It should have been restored 
during the VMEXIT from the HOST_RSP value in the VMCS!

Is this a nested setup?

2- %rbp is wrong

That would also explain why the loaded_vmcs was NULL. Whatever
corrupted the stack that caused loaded_vmcs to be NULL could have also
corrupted the %rbp saved in the stack. That would mean that it happened
during a function call. All function calls that happened between the
point when the stack was sane (just before the "asm" block for
VMLAUNCH) and the crash-site are only kcov related. Looking at kcov, I
can not see where the stack would get corrupted though! Obviously
another source of corruption can be a completely unrelated thread
directly corruption this thread's memory.

Maybe it would be easier to just try to repro it first and see which 
one is true (if at all).

[0] https://syzkaller.appspot.com/bug?extid=cc483201a3c6436d3550


On Thu, 2018-06-28 at 10:18 -0700, Jim Mattson wrote:
>   22: 0f 01 c3              vmresume
>   25: 48 89 4c 24 08        mov    %rcx,0x8(%rsp)
>   2a: 59                    pop    %rcx
> 
> <rip>:
>   2b: 0f 96 81 88 56 00 00 setbe  0x5688(%rcx)
>   32: 48 89 81 00 03 00 00 mov    %rax,0x300(%rcx)
>   39: 48 89 99 18 03 00 00 mov    %rbx,0x318(%rcx)
> 
> %rcx should be pointing to the vcpu_vmx structure, but it's not even
> canonical: 1ffff10035842e78.
> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

  reply	other threads:[~2018-06-30  8:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12  9:45 general protection fault in vmx_vcpu_run syzbot
2018-04-14  1:07 ` syzbot
2018-06-28  5:27   ` Dmitry Vyukov
2018-06-28 17:18     ` Jim Mattson
2018-06-30  8:09       ` Raslan, KarimAllah [this message]
2018-07-04 19:31         ` Raslan, KarimAllah
2018-07-05  5:32           ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1530346163.13559.75.camel@amazon.de \
    --to=karahmed@amazon.de \
    --cc=dvyukov@google.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=syzbot+cc483201a3c6436d3550@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.