Re: [Qemu-devel] [PATCH v4 0/8] KASLR kernel dump support

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jul 14, 2017 at 10:21:43PM +0200, Laszlo Ersek wrote:
> On 07/14/17 21:59, Michael S. Tsirkin wrote:
> > On Fri, Jul 14, 2017 at 08:20:03PM +0200, Marc-André Lureau wrote:
> >> Recent linux kernels enable KASLR to randomize phys/virt memory
> >> addresses. This series aims to provide enough information in qemu
> >> dumps so that crash utility can work with randomized kernel too (it
> >> hasn't been tested on other archs than x86 though, help welcome).
> >>
> >> The vmcoreinfo device is an emulated ACPI device that exposes a 4k
> >> memory range to the guest to store various informations useful to
> >> debug the guest OS. (it is greatly inspired by the VMGENID device
> >> implementation). The version field with value 0 is meant to give
> >> paddr/size of the VMCOREINFO ELF PT_NOTE, other values can be used for
> >> different purposes or OSes. (note: some wanted to see pvpanic somehow
> >> merged with this device, I have no clear idea how to do that, nor do I
> >> think this is a good idea since the devices are quite different, used
> >> at different time for different purposes. And it can be done as a
> >> future iteration if it is appropriate, feel free to send patches)
> > 
> > First, I think you underestimate the difficulty of maintaining
> > compatibility.
> > 
> > Second, this seems racy - how do you know when is guest done writing out
> > the data?
> 
> What data exactly?
> 
> The guest kernel module points the fields in the "vmcoreinfo page" to
> the then-existent vmcoreinfo ELF note. At that point, the ELF note is
> complete.

When does this happen?

> If we catch the guest with a dump request while the kernel module is
> setting up the fields (i.e., the fields are not consistent), then we'll
> catch that in our sanity checks, and the note won't be extracted.

Are there assumptions about e.g. in which order pa and size
are written out then? Atomicity of these writes?

> This
> is no different from the case when you simply dump the guest RAM before
> the module got invoked.
> 
> > Given you have very little data to export (PA, size - do
> > you even need size?)
> 
> Yes, it tells us in advance how much memory to allocate before we copy
> out the vmcoreinfo ELF note (and we enforce a sanity limit on the size).
> 
> > - how about just using an ACPI method do it,
> 
> Do what exactly?

Pass address + size to host - that's what the interface is doing,
isn't it?

> > instead of exporting a physical addess and storing address there.  This
> > way you can add more methods as you add functionality.
> 
> I'm not saying this is a bad idea (especially because I don't fully
> understand your point), but I will say that I'm quite sad that you are
> sending Marc-André back to the drawing board after he posted v4 -- also
> invalidating my review efforts. :/
> 
> Laszlo

You are right, I should have looked at this sooner. Early RFC
suggested writing into fw cfg directly. I couldn't find any
discussion around this - why was this abandoned?

-- 
MST