Re: uniquely identifying KDUMP files that originate from QEMU

From: Petr Tesarik <ptesarik@suse.cz>
To: Laszlo Ersek <lersek@redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, kexec@lists.infradead.org
Subject: Re: uniquely identifying KDUMP files that originate from QEMU
Date: Wed, 12 Nov 2014 19:43:25 +0100	[thread overview]
Message-ID: <20141112194325.246ff381@hananiah.suse.cz> (raw)
In-Reply-To: <546373B8.70103@redhat.com>

V Wed, 12 Nov 2014 15:50:32 +0100
Laszlo Ersek <lersek@redhat.com> napsáno:

> On 11/12/14 09:04, Petr Tesarik wrote:
> > On Wed, 12 Nov 2014 12:08:38 +0900 (JST)
> > HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> 
> >> Anyway, phys_base is kernel information. To make it available for qemu
> >> side, there's need to prepare a mechanism for qemu to have any access
> >> to it.
> > 
> > Yes. I wonder if you can have access without some sort of co-operation
> > from the guest kernel itself. I guess not.
> 
> Propagating any kind of additional information from the guest kernel
> (which is unprivileged and potentially malicious) to the host-side qemu
> process (which is by definition more privileged, although still confined
> by various measures) is something we'd explicitly like to avoid.
> 
> Think of it like this. I throw a physical box at you, running Linux,
> that has frozen in time. Can "crash" work with nothing else but the
> contents of the memory, and information about the CPUs?

If only you could save the _complete_ state of the CPU... For example
the content of CR3 would be quite useful.

Petr T

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec