[Qemu-devel] dump-guest-memory command?

[Qemu-devel] dump-guest-memory command?

[Jun Koi]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

Hi,

Anybody please help me on this dump-guest-memory command? How does the
virtual memory map to the dumped file?

For example, if x86 register RIP points to 0x12345, how does that map to
the dump file? Meaning how can I find where this address 0x12345 in the
dump?

I tried, but couldnt find much documentation on this command.

Thank you a lot,
Jun

[-- Attachment #2: Type: text/html, Size: 484 bytes --]

Re: [Qemu-devel] dump-guest-memory command?

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Fri, 16 May 2014 14:24:16 +0800
Jun Koi <junkoi2004@gmail.com> wrote:
> Hi,
> 
> Anybody please help me on this dump-guest-memory command? How does the
> virtual memory map to the dumped file?
> 
> For example, if x86 register RIP points to 0x12345, how does that map to
> the dump file? Meaning how can I find where this address 0x12345 in the
> dump?
> 
> I tried, but couldnt find much documentation on this command.
> 
> Thank you a lot,
> Jun

Hi Jun,

The dump file is in ELF format and data is written in ELF notes.
Use readelf -a on the file and you'll get something like the
following at the end of the output:

...

Notes at offset 0x000001c8 with length 0x00000328:
  Owner                 Data size       Description
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  QEMU                 0x000001b0       Unknown note type: (0x00000000)

The registers sit in the NT_PRSTATUS note (hence somewhere offset
0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
header size). Be aware that intel is little endian: if RIP is 0x00012345,
you need to look for '45 23 01 00' in the file.

The attached script may help to display the dump file content.

Cheers.

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

[-- Attachment #2: elfnote --]
[-- Type: application/octet-stream, Size: 691 bytes --]

#!/bin/bash

usage() {
    cat<<EOF>&2
USAGE: elfnote <corefile> <note pattern>

example: elfnote ./vmcore PRSTATUS will show PRSTATUS (registers)
EOF
    exit 1
}

[[ -n "$1" ]] || usage
file="$1"
shift
[[ -n "$1" ]] || usage
pattern="$1"
shift

notes=( $(readelf -n $file | awk --non-decimal-data \
    "/Notes at offset/ { offset = \$4 } \
     /$pattern/ { print offset + 20 \":\" 0 + \$2 } \
     /CORE|QEMU/ { offset += 20 + \$2 }"))

for note in "${notes[@]}"
do
    offset=${note%:*}
    size=${note#*:}

    printf "offset: 0x%x size: 0x%x\n" $offset $size
    echo "------------------------------------------------------"
    od -A x -t x1 -j $offset -N $size $file
    echo
done

Re: [Qemu-devel] dump-guest-memory command?

[Jun Koi]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Fri, May 16, 2014 at 3:03 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:

> On Fri, 16 May 2014 14:24:16 +0800
> Jun Koi <junkoi2004@gmail.com> wrote:
> > Hi,
> >
> > Anybody please help me on this dump-guest-memory command? How does the
> > virtual memory map to the dumped file?
> >
> > For example, if x86 register RIP points to 0x12345, how does that map to
> > the dump file? Meaning how can I find where this address 0x12345 in the
> > dump?
> >
> > I tried, but couldnt find much documentation on this command.
> >
> > Thank you a lot,
> > Jun
>
> Hi Jun,
>
> The dump file is in ELF format and data is written in ELF notes.
> Use readelf -a on the file and you'll get something like the
> following at the end of the output:
>
> ...
>
> Notes at offset 0x000001c8 with length 0x00000328:
>   Owner                 Data size       Description
>   CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
>   QEMU                 0x000001b0       Unknown note type: (0x00000000)
>
> The registers sit in the NT_PRSTATUS note (hence somewhere offset
> 0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
> header size). Be aware that intel is little endian: if RIP is 0x00012345,
> you need to look for '45 23 01 00' in the file.
>
>
Thanks so much, but perhaps you misunderstood my question? What I want to
know is how to map 0x12345 (virtual address) back to the dump file.

For example, if 0x12345 was executing some filesystem code at the time I
dumped the VM, then I can locate exactly that code in the dumpfile, thanks
to the given RIP address (which is 0x12345 in this example)

I hope I explain my idea clear enough this time?

Thanks a lot,
Jun

[-- Attachment #2: Type: text/html, Size: 2402 bytes --]

Re: [Qemu-devel] dump-guest-memory command?

[Andreas Färber]

Am 16.05.2014 10:40, schrieb Jun Koi:
> What I want
> to know is how to map 0x12345 (virtual address) back to the dump file.
> 
> For example, if 0x12345 was executing some filesystem code at the time I
> dumped the VM, then I can locate exactly that code in the dumpfile,
> thanks to the given RIP address (which is 0x12345 in this example)
> 
> I hope I explain my idea clear enough this time?

Using dump-guest-memory sounds more complicated than needed. You can
just use the monitor commands for disassembling that address or the
built-in gdb stub (-s).

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] dump-guest-memory command?

[Jun Koi]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Fri, May 16, 2014 at 4:45 PM, Andreas Färber <afaerber@suse.de> wrote:

> Am 16.05.2014 10:40, schrieb Jun Koi:
> > What I want
> > to know is how to map 0x12345 (virtual address) back to the dump file.
> >
> > For example, if 0x12345 was executing some filesystem code at the time I
> > dumped the VM, then I can locate exactly that code in the dumpfile,
> > thanks to the given RIP address (which is 0x12345 in this example)
> >
> > I hope I explain my idea clear enough this time?
>
> Using dump-guest-memory sounds more complicated than needed.


No, this is important, since i can have a whole image to do offline
analysis.


> You can
> just use the monitor commands for disassembling that address


What is this command? I try "help" but cannot find any. Before I remember
we had "disas" or something like that, but I cannot find that again in
latest Qemu code.


> or the
> built-in gdb stub (-s).
>
>
Is this true that this only works for pure emulator, not for kvm-enable VM?

Thanks,
Jun

[-- Attachment #2: Type: text/html, Size: 1782 bytes --]

Re: [Qemu-devel] dump-guest-memory command?

[Greg Kurz]

On Fri, 16 May 2014 16:51:36 +0800
Jun Koi <junkoi2004@gmail.com> wrote:
> On Fri, May 16, 2014 at 4:45 PM, Andreas Färber <afaerber@suse.de> wrote:
> 
> > Am 16.05.2014 10:40, schrieb Jun Koi:
> > > What I want
> > > to know is how to map 0x12345 (virtual address) back to the dump file.
> > >
> > > For example, if 0x12345 was executing some filesystem code at the time I
> > > dumped the VM, then I can locate exactly that code in the dumpfile,
> > > thanks to the given RIP address (which is 0x12345 in this example)
> > >
> > > I hope I explain my idea clear enough this time?
> >
> > Using dump-guest-memory sounds more complicated than needed.
> 
> 
> No, this is important, since i can have a whole image to do offline
> analysis.
> 
> 
> > You can
> > just use the monitor commands for disassembling that address
> 
> 
> What is this command? I try "help" but cannot find any. Before I remember
> we had "disas" or something like that, but I cannot find that again in
> latest Qemu code.
> 

It is the 'x' command.

(qemu) x/i $pc

> 
> > or the
> > built-in gdb stub (-s).
> >
> >
> Is this true that this only works for pure emulator, not for kvm-enable VM?
> 

Dunno the status for intel targets... give it a try ! ;)

> Thanks,
> Jun

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

Re: [Qemu-devel] dump-guest-memory command?

[Greg Kurz]

On Fri, 16 May 2014 16:40:23 +0800
Jun Koi <junkoi2004@gmail.com> wrote:
> On Fri, May 16, 2014 at 3:03 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> 
> > On Fri, 16 May 2014 14:24:16 +0800
> > Jun Koi <junkoi2004@gmail.com> wrote:
> > > Hi,
> > >
> > > Anybody please help me on this dump-guest-memory command? How does the
> > > virtual memory map to the dumped file?
> > >
> > > For example, if x86 register RIP points to 0x12345, how does that map to
> > > the dump file? Meaning how can I find where this address 0x12345 in the
> > > dump?
> > >
> > > I tried, but couldnt find much documentation on this command.
> > >
> > > Thank you a lot,
> > > Jun
> >
> > Hi Jun,
> >
> > The dump file is in ELF format and data is written in ELF notes.
> > Use readelf -a on the file and you'll get something like the
> > following at the end of the output:
> >
> > ...
> >
> > Notes at offset 0x000001c8 with length 0x00000328:
> >   Owner                 Data size       Description
> >   CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
> >   QEMU                 0x000001b0       Unknown note type: (0x00000000)
> >
> > The registers sit in the NT_PRSTATUS note (hence somewhere offset
> > 0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
> > header size). Be aware that intel is little endian: if RIP is 0x00012345,
> > you need to look for '45 23 01 00' in the file.
> >
> >
> Thanks so much, but perhaps you misunderstood my question? What I want to
> know is how to map 0x12345 (virtual address) back to the dump file.
> 

Heh... sorry for that, morning isn't the best time to answer questions I guess ;)

> For example, if 0x12345 was executing some filesystem code at the time I
> dumped the VM, then I can locate exactly that code in the dumpfile, thanks
> to the given RIP address (which is 0x12345 in this example)
> 
> I hope I explain my idea clear enough this time?
> 

Yeah. Maybe the crash utility (http://people.redhat.com/anderson) can help.

> Thanks a lot,
> Jun



-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

Re: [Qemu-devel] dump-guest-memory command?

[Jun Koi]

[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]

On Fri, May 16, 2014 at 5:51 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:

> On Fri, 16 May 2014 16:40:23 +0800
> Jun Koi <junkoi2004@gmail.com> wrote:
> > On Fri, May 16, 2014 at 3:03 PM, Greg Kurz <gkurz@linux.vnet.ibm.com>
> wrote:
> >
> > > On Fri, 16 May 2014 14:24:16 +0800
> > > Jun Koi <junkoi2004@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > Anybody please help me on this dump-guest-memory command? How does
> the
> > > > virtual memory map to the dumped file?
> > > >
> > > > For example, if x86 register RIP points to 0x12345, how does that
> map to
> > > > the dump file? Meaning how can I find where this address 0x12345 in
> the
> > > > dump?
> > > >
> > > > I tried, but couldnt find much documentation on this command.
> > > >
> > > > Thank you a lot,
> > > > Jun
> > >
> > > Hi Jun,
> > >
> > > The dump file is in ELF format and data is written in ELF notes.
> > > Use readelf -a on the file and you'll get something like the
> > > following at the end of the output:
> > >
> > > ...
> > >
> > > Notes at offset 0x000001c8 with length 0x00000328:
> > >   Owner                 Data size       Description
> > >   CORE                 0x00000150       NT_PRSTATUS (prstatus
> structure)
> > >   QEMU                 0x000001b0       Unknown note type: (0x00000000)
> > >
> > > The registers sit in the NT_PRSTATUS note (hence somewhere offset
> > > 0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
> > > header size). Be aware that intel is little endian: if RIP is
> 0x00012345,
> > > you need to look for '45 23 01 00' in the file.
> > >
> > >
> > Thanks so much, but perhaps you misunderstood my question? What I want to
> > know is how to map 0x12345 (virtual address) back to the dump file.
> >
>
> Heh... sorry for that, morning isn't the best time to answer questions I
> guess ;)
>
> > For example, if 0x12345 was executing some filesystem code at the time I
> > dumped the VM, then I can locate exactly that code in the dumpfile,
> thanks
> > to the given RIP address (which is 0x12345 in this example)
> >
> > I hope I explain my idea clear enough this time?
> >
>
> Yeah. Maybe the crash utility (http://people.redhat.com/anderson) can
> help.
>
>
but my VM is not Linux, so is this tool helpful?

some questions:

- is it true that dump-guest-memory just write down physical memory page,
and does not consider the virtual-memory concept?

- if above is true, how can i translate virtual address to physical
address? (since only after that i can map my virtual address to its
position in the dumpfile)

thanks!
Jun



>
> --
> Gregory Kurz                                     kurzgreg@fr.ibm.com
>                                                  gkurz@linux.vnet.ibm.com
> Software Engineer @ IBM/Meiosys                  http://www.ibm.com
> Tel +33 (0)562 165 496
>
> "Anarchy is about taking complete responsibility for yourself."
>         Alan Moore.
>
>

[-- Attachment #2: Type: text/html, Size: 4605 bytes --]

Re: [Qemu-devel] dump-guest-memory command?

[Greg Kurz]

On Fri, 16 May 2014 17:59:25 +0800
Jun Koi <junkoi2004@gmail.com> wrote:

> On Fri, May 16, 2014 at 5:51 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> 
> > On Fri, 16 May 2014 16:40:23 +0800
> > Jun Koi <junkoi2004@gmail.com> wrote:
> > > On Fri, May 16, 2014 at 3:03 PM, Greg Kurz <gkurz@linux.vnet.ibm.com>
> > wrote:
> > >
> > > > On Fri, 16 May 2014 14:24:16 +0800
> > > > Jun Koi <junkoi2004@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Anybody please help me on this dump-guest-memory command? How does
> > the
> > > > > virtual memory map to the dumped file?
> > > > >
> > > > > For example, if x86 register RIP points to 0x12345, how does that
> > map to
> > > > > the dump file? Meaning how can I find where this address 0x12345 in
> > the
> > > > > dump?
> > > > >
> > > > > I tried, but couldnt find much documentation on this command.
> > > > >
> > > > > Thank you a lot,
> > > > > Jun
> > > >
> > > > Hi Jun,
> > > >
> > > > The dump file is in ELF format and data is written in ELF notes.
> > > > Use readelf -a on the file and you'll get something like the
> > > > following at the end of the output:
> > > >
> > > > ...
> > > >
> > > > Notes at offset 0x000001c8 with length 0x00000328:
> > > >   Owner                 Data size       Description
> > > >   CORE                 0x00000150       NT_PRSTATUS (prstatus
> > structure)
> > > >   QEMU                 0x000001b0       Unknown note type: (0x00000000)
> > > >
> > > > The registers sit in the NT_PRSTATUS note (hence somewhere offset
> > > > 0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
> > > > header size). Be aware that intel is little endian: if RIP is
> > 0x00012345,
> > > > you need to look for '45 23 01 00' in the file.
> > > >
> > > >
> > > Thanks so much, but perhaps you misunderstood my question? What I want to
> > > know is how to map 0x12345 (virtual address) back to the dump file.
> > >
> >
> > Heh... sorry for that, morning isn't the best time to answer questions I
> > guess ;)
> >
> > > For example, if 0x12345 was executing some filesystem code at the time I
> > > dumped the VM, then I can locate exactly that code in the dumpfile,
> > thanks
> > > to the given RIP address (which is 0x12345 in this example)
> > >
> > > I hope I explain my idea clear enough this time?
> > >
> >
> > Yeah. Maybe the crash utility (http://people.redhat.com/anderson) can
> > help.
> >
> >
> but my VM is not Linux, so is this tool helpful?
> 
> some questions:
> 
> - is it true that dump-guest-memory just write down physical memory page,
> and does not consider the virtual-memory concept?
> 
> - if above is true, how can i translate virtual address to physical
> address? (since only after that i can map my virtual address to its
> position in the dumpfile)
> 
> thanks!
> Jun
> 

from dump.c:

static int write_elf64_load(DumpState *s, MemoryMapping *memory_mapping,
                            int phdr_index, hwaddr offset,
                            hwaddr filesz)
{
    Elf64_Phdr phdr;
    int ret;
    int endian = s->dump_info.d_endian;

    memset(&phdr, 0, sizeof(Elf64_Phdr));
    phdr.p_type = cpu_convert_to_target32(PT_LOAD, endian);
    phdr.p_offset = cpu_convert_to_target64(offset, endian);
    phdr.p_paddr = cpu_convert_to_target64(memory_mapping->phys_addr, endian);
    phdr.p_filesz = cpu_convert_to_target64(filesz, endian);
    phdr.p_memsz = cpu_convert_to_target64(memory_mapping->length, endian);
    phdr.p_vaddr = cpu_convert_to_target64(memory_mapping->virt_addr, endian);

It looks like the information is part of the ELF program header.

Cheers.

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

Re: [Qemu-devel] dump-guest-memory command?

[Laszlo Ersek]

On 05/16/14 11:59, Jun Koi wrote:

> - is it true that dump-guest-memory just write down physical memory
> page, and does not consider the virtual-memory concept?

No, it isn't.

Basically, "dump-guest-memory" supports two modes of operation, "paging
enabled" and "paging disabled".

Many (most?) people dump for the "crash" utility, which is super smart,
and extra paging info is not needed. For "crash" we just dump the
guest-phys memory ranges the way the guest sees them, and that's it;
"crash" figures out everything from that.

If you want to use "gdb" rather than "crash", or need the guest-virtual
addresses in the ELF vmcore for some other reason, then you should
invoke "dump-guest-memory" with paging enabled.

Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
the "-p" option.

Laszlo

Re: [Qemu-devel] dump-guest-memory command?

[Jun Koi]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Fri, May 16, 2014 at 7:30 PM, Laszlo Ersek <lersek@redhat.com> wrote:

> On 05/16/14 11:59, Jun Koi wrote:
>
> > - is it true that dump-guest-memory just write down physical memory
> > page, and does not consider the virtual-memory concept?
>
> No, it isn't.
>
> Basically, "dump-guest-memory" supports two modes of operation, "paging
> enabled" and "paging disabled".
>
> Many (most?) people dump for the "crash" utility, which is super smart,
> and extra paging info is not needed. For "crash" we just dump the
> guest-phys memory ranges the way the guest sees them, and that's it;
> "crash" figures out everything from that.
>
> If you want to use "gdb" rather than "crash", or need the guest-virtual
> addresses in the ELF vmcore for some other reason, then you should
> invoke "dump-guest-memory" with paging enabled.
>
> Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
> the "-p" option.
>

so i suppose this works for all kind of OS in guest VM, not only Linux
guest?

thanks so much,
Jun

[-- Attachment #2: Type: text/html, Size: 1571 bytes --]

Re: [Qemu-devel] dump-guest-memory command?

[Laszlo Ersek]

On 05/16/14 15:01, Jun Koi wrote:
> 
> 
> 
> On Fri, May 16, 2014 at 7:30 PM, Laszlo Ersek <lersek@redhat.com
> <mailto:lersek@redhat.com>> wrote:
> 
>     On 05/16/14 11:59, Jun Koi wrote:
> 
>     > - is it true that dump-guest-memory just write down physical memory
>     > page, and does not consider the virtual-memory concept?
> 
>     No, it isn't.
> 
>     Basically, "dump-guest-memory" supports two modes of operation, "paging
>     enabled" and "paging disabled".
> 
>     Many (most?) people dump for the "crash" utility, which is super smart,
>     and extra paging info is not needed. For "crash" we just dump the
>     guest-phys memory ranges the way the guest sees them, and that's it;
>     "crash" figures out everything from that.
> 
>     If you want to use "gdb" rather than "crash", or need the guest-virtual
>     addresses in the ELF vmcore for some other reason, then you should
>     invoke "dump-guest-memory" with paging enabled.
> 
>     Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
>     the "-p" option.
> 
> 
> so i suppose this works for all kind of OS in guest VM, not only Linux
> guest?

far as I remember, it should; the virtual mappings "in effect" are
searched starting from cr3:

qmp_dump_guest_memory() [dump.c]
  dump_init()
    qemu_get_guest_memory_mapping() [memory_mapping.c]
      for (almost) all VCPUs:
        cpu_get_memory_mapping() [qom/cpu.c]
          x86_cpu_get_memory_mapping()
                                     [target-i386/arch_memory_mapping.c]
            check cr3, cr4; walk page tables etc

There are some caveats / limitations: search "qapi-schema.json" for the
string "dump-guest-memory", and read that section.

Laszlo