linux-kernel - Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump

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: <20120422103340.GE12768@redhat.com>
Date:	Sun, 22 Apr 2012 13:33:40 +0300
From:	Gleb Natapov <gleb@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>, dzickus@...hat.com,
	luto@....edu, gregkh@...e.de, kvm@...r.kernel.org,
	joerg.roedel@....com, mtosatti@...hat.com,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	paul.gortmaker@...driver.com, zhangyanfei@...fujitsu.com,
	ebiederm@...ssion.com, ludwig.nussel@...e.de
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information
 for kdump

On Sun, Apr 22, 2012 at 12:58:35PM +0300, Avi Kivity wrote:
> On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> > From: Avi Kivity <avi@...hat.com>
> > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> > Date: Thu, 19 Apr 2012 15:08:00 +0300
> >
> > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> > >> >> It would be not helpful for the qemu crash case you are concerned
> > >> >> about. We want to use the guest state data to look into guest
> > >> >> machine's image in the crasshed qemu.
> > >> > 
> > >> > Why?
> > >> > 
> > >>
> > >> It seems natural to check the situation from guest machine's side when
> > >> qemu crashs. Suppose a service is running on the guest machine, and
> > >> then the qemu crash. Then, we may need to know the details of the
> > >> progress of the service if it's important. What has been successfully
> > >> done, and what has not yet.
> > > 
> > > How can a service on the guest be related to a qemu crash?  And how
> > > would guest registers help?
> >
> > I don't mean the service is related to qemu's crash. When qemu
> > crashes, then the guest machine also crashes (although it doesn't
> > notice anything). What I'm interested in here is guest machine side,
> > not qemu side. I want to debug guest machine, not qemu.
> 
> There is no bug in the guest, so why debug it?
> 
> It's similar to pulling out the power from a server and wanting to
> inspect the registers and memory at the time the cpu died.  Even if it's
> possible, you don't gain any information from it.
> 
> > > 
> > > You can extract the list of running processes from a qemu crash dump
> > > without looking at guest registers.  And most vcpus are running
> > > asynchronously to qemu, so their register contents is irrelevant (if a
> > > vcpu is running synchronously with qemu - it just exited to qemu and is
> > > waiting for a response - then you'd see the details in qemu's call stack).
> > > 
> >
> > Just as you say, we can refer to guest machine's memory without guest
> > registers.
> >
> > The definitely necessary data in vmcs are RSP and RIP, which are not
> > saved in anywhare of kvm module. The two registers are needed for back
> > tracing to determine what processsing is being done on the guest
> > machine at qemu crash.
> 
> What I don't understand is why you are interested in the guest machine
> at all, if it was qemu that crashed.
> 
It would be interesting to extract enough information from the core to be
able to restart the guest from the point where qemu crashed, but
decoding VMCS is not enough for that.

--
			Gleb.
--
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/