----- 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
