[Crash-utility] DD image

Dave Anderson anderson at redhat.com
Thu Apr 14 13:57:04 UTC 2011


----- Original Message -----
> Hi Dave,
> 
> Thanks for your feedback , actually what I meant by minimizing the
> footprint that to not preform any action which requires instillation
> for any tool in order to image the memory. that to preserve the
> volatile data and not to overwrite information in memory such as
> terminated and cached processes. snap.so is good solution for live
> system but it first requires the instillation of crash in the
> investigated system which is not forensic sound. dd is small tool that
> comes with the most modern Linux destructions and forensic toolkits as
> it does not require instillation. if crash supports dd image then
> crach utility will be not only debugger but also forensic tool.
> 
> thanks,
> Amer

OK, so you *are* suggesting that the dumpfile would be created 
something like this:

  $ dd if=/dev/mem of=memory-image bs=<page-size>

What architecture is this for?

And can you confirm that the /dev/mem read_mem() function will
proceed without any of its error scenarios occurring before the
last page of physical memory is read?
                
There are these possible failures:

        if (!valid_phys_addr_range(p, count))
                return -EFAULT;

        if (!range_is_allowed(p >> PAGE_SHIFT, count))
                return -EPERM;

        ptr = xlate_dev_mem_ptr(p);
        if (!ptr)
                return -EFAULT;

        remaining = copy_to_user(buf, ptr, sz);
        unxlate_dev_mem_ptr(p, ptr);
        if (remaining)
                return -EFAULT;

First, the valid_phys_addr_range() restricts /dev/mem to
high_memory, or 896MB maximum on 32-bit architectures.  
The crash utility will still initialize, but several 
commands will fail if memory over that 896MB threshold
are required.

But more importantly, the xlate_dev_mem_ptr() call is the one 
that could possibly trip you up if the architecture is x86 or x86_64.
I don't have a machine on-hand to test that because RHEL/Fedora
kernels apply CONFIG_STRICT_DEVMEM, so /dev/mem is useless for
that purpose.

In any case, if the output file is page-for-page copy
of physical memory, then creating support for it would
be fairly easy.  But I really don't want to expend any effort
creating support for such a file format given the potential
problems with the use of /dev/mem.

On the other hand, it would also be fairly easy to create
a small utility function that simply pre-pends an ELF header
to the dumpfile -- one which has a single PT_LOAD section
that describes the physical memory as one large chunk.  
For this simple format, you could take the snap.c extension
module's generate_elf_header() function, have it create a
an ELF header with just one PT_LOAD segment, and fold it 
into a standalone program.  It has support for x86, x86_64,
ppc64 and ia64.

Dave




More information about the Crash-utility mailing list