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" <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/crash-utility
-- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
