Sound messy, because a live /dev/mem is a moving target. Similar to taking an action photo with the shutter open too long. Just keeo this in mind.
Scott.
On Apr 13, 2011 11:40 AM, "Dave Anderson" <anderson@xxxxxxxxxx> wrote:
>
>
> ----- Original Message -----
>> Hi Dave,
>>
>> Crash utility support for such a raw dumpfile would be really useful
>> for some embedded devices.
>> Such device typically have no storage resource to write the dumpfile
>> in the supported format, but another CPU on the system can take out
>> the physical memory contents to a connected debugger PC. In this case,
>> only raw dumpfile is available since the latter CPU do not have the
>> knowledge of the crashed kernel.
>> Writing a small utility which converts a raw dump to one of the
>> supported format might be an idea. But it probably requires the
>> information from vmlinux.
>> So it seems natural to me that crash utility should support raw
>> dumpfile by itself.
>>
>> Best Regard,
>>
>> Takuo Koguchi
>
> The primary requirement for the various dumpfile headers is that
> they define a manner to find the location in the dumpfile of a
> particular page of physical memory.
>
> However, it sounds like this proposed dumpfile type would be a
> page-for-page copy of physical memory? Perhaps there might be empty
> memory holes in the file, but the file would be exactly equal in size
> to the physical memory of the embedded system?
>
> If that's true, it could be done in either of two ways:
>
> (1) If this raw dumpfile was created such that, for example,
> if the crash utility needed to read the page at physical
> address 0xfffe000, it simply had to lseek() in the raw dump
> to file offset 0xfffe000, then no header would be required.
> A new dumpfile type and a plug-in function for pc->readmem()
> would have to be created, and it should just work. But since
> the raw dumpfile type would not be readily recognized during
> invocation, it would have to be explicitly invoked, i.e.,
> something like:
>
> $ crash vmlinux --raw dumpfile
>
> It's a little more involved than that, but you basically would
> have to check all the places where dumpfile types are used, and:
>
> (a) #define'ing and adding the new type to the MEMORY_SOURCES and
> DUMPFILE_SOURCES #define's, and then
> (b) ook for all instances where there are "if" or "switch" statements
> are made for the various dumpfile types, and add code for the new
> type if necessary. It's not that hard, you can just emulate what
> is done for an existing type. For example, check the code for all
> instances of where the KDUMP #define and the KDUMP_DUMPFILE() macro
> are used, and then do the right thing (if necessary) for the new
> dumpfile type.
>
> (2) Or as you suggest, it would be fairly simple to create a
> utility that would pre-pend a simple ELF header that contained
> a single PT_LOAD segment that described the whole chunk of
> physical memory. That's essentially what the original NETDUMP
> format does.
>
> Dave
>
>>
>> >
>> >----- Original Message -----
>> >> Hi ,
>> >>
>> >>
>> >> recently, some forensic research suggested that utilizing Crash
>> >> utility as independent solution to parse Linux memory dump in order
>> >> to
>> >> extract forensic artifacts. but in real forensic cases where there
>> >> is
>> >> need for minimizing the footprint on the comprised system, the
>> >> forensic analyst would perform only one action, which is physical
>> >> memory capture to minimize the footprint with dd. I just wonder if
>> >> there any chance that Crach utility would support dd image.
>> >>
>> >> Thanks,
>> >> Amer
>> >
>> >Certainly there is no support for such a raw dumpfile format.
>> >
>> >But I don't really understand what you mean by saying that the
>> >use of dd "would minimize the footprint"? I presume that you
>> >are asking whether you could do something like this on a live
>> >system?:
>> >
>> > $ dd if=/dev/mem of=memory-image
>> > $ crash vmlinux memory-image
>> >
>> >Theoretically it could be done, presuming that the read_mem()
>> >function in the /dev/mem driver would never fail until it reached
>> >the end of physical memory, i.e., would create an exact page-by-page
>> >copy of all physical pages from 0 to the end of physical memory.
>> >
>> >But if that's the case, and you can run crash on the system that
>> >you want to dump, try the "snap.so" extension module that comes
>> >with the crash utility source package. It creates a dumpfile
>> >while running on a live system, in an ELF format that crash
>> >understands.
>> >
>> >Dave
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> ----- Original Message -----
>> Hi Dave,
>>
>> Crash utility support for such a raw dumpfile would be really useful
>> for some embedded devices.
>> Such device typically have no storage resource to write the dumpfile
>> in the supported format, but another CPU on the system can take out
>> the physical memory contents to a connected debugger PC. In this case,
>> only raw dumpfile is available since the latter CPU do not have the
>> knowledge of the crashed kernel.
>> Writing a small utility which converts a raw dump to one of the
>> supported format might be an idea. But it probably requires the
>> information from vmlinux.
>> So it seems natural to me that crash utility should support raw
>> dumpfile by itself.
>>
>> Best Regard,
>>
>> Takuo Koguchi
>
> The primary requirement for the various dumpfile headers is that
> they define a manner to find the location in the dumpfile of a
> particular page of physical memory.
>
> However, it sounds like this proposed dumpfile type would be a
> page-for-page copy of physical memory? Perhaps there might be empty
> memory holes in the file, but the file would be exactly equal in size
> to the physical memory of the embedded system?
>
> If that's true, it could be done in either of two ways:
>
> (1) If this raw dumpfile was created such that, for example,
> if the crash utility needed to read the page at physical
> address 0xfffe000, it simply had to lseek() in the raw dump
> to file offset 0xfffe000, then no header would be required.
> A new dumpfile type and a plug-in function for pc->readmem()
> would have to be created, and it should just work. But since
> the raw dumpfile type would not be readily recognized during
> invocation, it would have to be explicitly invoked, i.e.,
> something like:
>
> $ crash vmlinux --raw dumpfile
>
> It's a little more involved than that, but you basically would
> have to check all the places where dumpfile types are used, and:
>
> (a) #define'ing and adding the new type to the MEMORY_SOURCES and
> DUMPFILE_SOURCES #define's, and then
> (b) ook for all instances where there are "if" or "switch" statements
> are made for the various dumpfile types, and add code for the new
> type if necessary. It's not that hard, you can just emulate what
> is done for an existing type. For example, check the code for all
> instances of where the KDUMP #define and the KDUMP_DUMPFILE() macro
> are used, and then do the right thing (if necessary) for the new
> dumpfile type.
>
> (2) Or as you suggest, it would be fairly simple to create a
> utility that would pre-pend a simple ELF header that contained
> a single PT_LOAD segment that described the whole chunk of
> physical memory. That's essentially what the original NETDUMP
> format does.
>
> Dave
>
>>
>> >
>> >----- Original Message -----
>> >> Hi ,
>> >>
>> >>
>> >> recently, some forensic research suggested that utilizing Crash
>> >> utility as independent solution to parse Linux memory dump in order
>> >> to
>> >> extract forensic artifacts. but in real forensic cases where there
>> >> is
>> >> need for minimizing the footprint on the comprised system, the
>> >> forensic analyst would perform only one action, which is physical
>> >> memory capture to minimize the footprint with dd. I just wonder if
>> >> there any chance that Crach utility would support dd image.
>> >>
>> >> Thanks,
>> >> Amer
>> >
>> >Certainly there is no support for such a raw dumpfile format.
>> >
>> >But I don't really understand what you mean by saying that the
>> >use of dd "would minimize the footprint"? I presume that you
>> >are asking whether you could do something like this on a live
>> >system?:
>> >
>> > $ dd if=/dev/mem of=memory-image
>> > $ crash vmlinux memory-image
>> >
>> >Theoretically it could be done, presuming that the read_mem()
>> >function in the /dev/mem driver would never fail until it reached
>> >the end of physical memory, i.e., would create an exact page-by-page
>> >copy of all physical pages from 0 to the end of physical memory.
>> >
>> >But if that's the case, and you can run crash on the system that
>> >you want to dump, try the "snap.so" extension module that comes
>> >with the crash utility source package. It creates a dumpfile
>> >while running on a live system, in an ELF format that crash
>> >understands.
>> >
>> >Dave
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
