Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Crash Utility (http://www.linux-archive.org/crash-utility/)
-   -   DD image (http://www.linux-archive.org/crash-utility/513301-dd-image.html)

Amer Aljaedi 04-12-2011 06:38 PM

DD image
 
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


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 04-12-2011 08:05 PM

DD image
 
----- 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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

04-13-2011 03:48 PM

DD image
 
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

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

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 04-13-2011 04:39 PM

DD image
 
----- 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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Scott Edwards 04-13-2011 04:46 PM

DD image
 
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@redhat.com> 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@redhat.com

> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

"Bryn M. Reeves" 04-13-2011 04:52 PM

DD image
 
On 04/13/2011 05:46 PM, Scott Edwards wrote:
> 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.

Think the OP is talking about applications where the crashed kernel is dead and
gone but some embedded hardware support still permits an external debugger
(serial, JTAG or similar I guess?) to read out the content of physical memory.

The result of that is a file that's the equivalent of a dd image of /dev/mem
although it's not taken from the live system by reading /dev/mem from userspace.

Regards,
Bryn.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 04-14-2011 01:57 PM

DD image
 
----- 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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

05-24-2011 12:07 PM

DD image
 
Hello Dave,

>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.

I have chosen this way for my arm target. Though snap.c told me how to create an elf header,
it is too difficult for me to modify it to support ELF32 of ARM in addition to existing ELF64 support. So
I just prepend a fixed ELF header which generate_elf_header would create.

(1) I tried "an ELF header with just one PT_LOAD segment" vmcore file as you suggested and got the following,
---------------------
$ ./crash vmlinux vmcore
crash 5.1.5
Copyright (C) 2002-2011 Red Hat, Inc.
...
This program has absolutely no warranty. Enter "help warranty" for details.

crash: vmcore: not a supported file format

Usage:

crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)

Enter "crash -h" for details.
----------------------

The following is information of the file got by readelf command. Is there something wrong?

$ arm-eabi-readelf -a vmcore
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0 <corrupt: out of range>

There are no sections in this file.

There are no sections in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000054 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

------------------------------------------------
(2) Next I tried "an ELF header with an empty PT_NOTE segment and just one PT_LOAD segment"
This time readelf command shows
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0

And I could use this file as a core file for "arm-eabi-gdb vmlinux vmcore"
For example "show init_task" works normally.

Is this an expected behavior?

(3) Above vmcore file works for gdb, but it does not work for crash(5.1.5).
I got the following message and the crash command just exited.
crash: CONFIG_SPARSEMEM kernels not supported for this architecture

Would you please tell me how to support CONFIG_SPARSEMEM?

I tried to add "machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;" in arm.c and made some progress.
But still I cannot reach the crash prompt.

I will appreciate any suggestion.

Best Regard,

Takuo Koguchi




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

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

"Karlsson, Jan" 05-24-2011 12:24 PM

DD image
 
Hi

I had the same problem with CONFIG_SPARSEMEM and if I do not remember wrong I added:
machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
machdep->section_size_bits = _SECTION_SIZE_BITS;
to arm.c

and:
#define _SECTION_SIZE_BITS 22
#define _MAX_PHYSMEM_BITS 32
to defs.h in a section for ARM.

I am not certain what these figures stand for but they seems to work for me.

Jan Karlsson

-----Original Message-----
From: crash-utility-bounces@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of takuo.koguchi.sw@hitachi.com
Sent: tisdag den 24 maj 2011 14:07
To: crash-utility@redhat.com; amer4554@gmail.com
Subject: Re: [Crash-utility] DD image

Hello Dave,

>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.

I have chosen this way for my arm target. Though snap.c told me how to create an elf header,
it is too difficult for me to modify it to support ELF32 of ARM in addition to existing ELF64 support. So
I just prepend a fixed ELF header which generate_elf_header would create.

(1) I tried "an ELF header with just one PT_LOAD segment" vmcore file as you suggested and got the following,
---------------------
$ ./crash vmlinux vmcore
crash 5.1.5
Copyright (C) 2002-2011 Red Hat, Inc.
...
This program has absolutely no warranty. Enter "help warranty" for details.

crash: vmcore: not a supported file format

Usage:

crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)

Enter "crash -h" for details.
----------------------

The following is information of the file got by readelf command. Is there something wrong?

$ arm-eabi-readelf -a vmcore
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0 <corrupt: out of range>

There are no sections in this file.

There are no sections in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000054 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

------------------------------------------------
(2) Next I tried "an ELF header with an empty PT_NOTE segment and just one PT_LOAD segment"
This time readelf command shows
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0

And I could use this file as a core file for "arm-eabi-gdb vmlinux vmcore"
For example "show init_task" works normally.

Is this an expected behavior?

(3) Above vmcore file works for gdb, but it does not work for crash(5.1.5).
I got the following message and the crash command just exited.
crash: CONFIG_SPARSEMEM kernels not supported for this architecture

Would you please tell me how to support CONFIG_SPARSEMEM?

I tried to add "machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;" in arm.c and made some progress.
But still I cannot reach the crash prompt.

I will appreciate any suggestion.

Best Regard,

Takuo Koguchi




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

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Dave Anderson 05-24-2011 01:31 PM

DD image
 
----- Original Message -----
> Hello Dave,
>
> >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.
>
> I have chosen this way for my arm target. Though snap.c told me how to
> create an elf header,
> it is too difficult for me to modify it to support ELF32 of ARM in
> addition to existing ELF64 support. So
> I just prepend a fixed ELF header which generate_elf_header would
> create.
>
> (1) I tried "an ELF header with just one PT_LOAD segment" vmcore file
> as you suggested and got the following,
> ---------------------
> $ ./crash vmlinux vmcore
> crash 5.1.5
> Copyright (C) 2002-2011 Red Hat, Inc.
> ...
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> crash: vmcore: not a supported file format
>
> Usage:
>
> crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form)
> crash [OPTION]... [NAMELIST] (live system form)
>
> Enter "crash -h" for details.
> ----------------------
>
> The following is information of the file got by readelf command. Is
> there something wrong?
>
> $ arm-eabi-readelf -a vmcore
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: CORE (Core file)
> Machine: ARM
> Version: 0x1
> Entry point address: 0x0
> Start of program headers: 52 (bytes into file)
> Start of section headers: 0 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 1
> Size of section headers: 0 (bytes)
> Number of section headers: 0
> Section header string table index: 0 <corrupt: out of range>
>
> There are no sections in this file.
>
> There are no sections in this file.
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000054 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0
>
> There is no dynamic section in this file.
>
> There are no relocations in this file.
>
> There are no unwind sections in this file.
>
> No version information found in this file.
>
> ------------------------------------------------
> (2) Next I tried "an ELF header with an empty PT_NOTE segment and just
> one PT_LOAD segment"
> This time readelf command shows
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
> LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0

That's what you need -- it is presumed that there will be a minimum
of two program header sections:

(1) at least one PT_NOTE section (typically an NT_PRSTATUS note w/registers)
(2) at least one PT_LOAD section (which you have)

so without the empty PT_NOTE, it was failing here in is_netdump():

if ((elf32->e_ident[EI_CLASS] == ELFCLASS32) &&
(swap16(elf32->e_type, swap) == ET_CORE) &&
(swap32(elf32->e_version, swap) == EV_CURRENT) &&
(swap16(elf32->e_phnum, swap) >= 2)) {

because your elf32->e_phnum was 1:

> Number of program headers: 1

So, yes, adding an empty PT_NOTE should be OK to get by that error.

> And I could use this file as a core file for "arm-eabi-gdb vmlinux > vmcore"
> For example "show init_task" works normally.
>
> Is this an expected behavior?
>
> (3) Above vmcore file works for gdb, but it does not work for crash(5.1.5).
> I got the following message and the crash command just exited.
> crash: CONFIG_SPARSEMEM kernels not supported for this architecture
>
> Would you please tell me how to support CONFIG_SPARSEMEM?
>
> I tried to add "machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;" in
> arm.c and made some progress. But still I cannot reach the crash prompt.
>
> I will appreciate any suggestion.

As far as the CONFIG_SPARSEMEM failure, I'm not exactly sure why that's
happening.

Looking at the latest upstream kernel, CONFIG_SPARSEMEM is not supported
by the ARM architecture. This is "arch/arm/include/asm/sparsemem.h":

#ifndef ASMARM_SPARSEMEM_H
#define ASMARM_SPARSEMEM_H

#include <asm/memory.h>

/*
* Two definitions are required for sparsemem:
*
* MAX_PHYSMEM_BITS: The number of physical address bits required
* to address the last byte of memory.
*
* SECTION_SIZE_BITS: The number of physical address bits to cover
* the maximum amount of memory in a section.
*
* Eg, if you have 2 banks of up to 64MB at 0x80000000, 0x84000000,
* then MAX_PHYSMEM_BITS is 32, SECTION_SIZE_BITS is 26.
*
* Define these in your mach/memory.h.
*/
#if !defined(SECTION_SIZE_BITS) || !defined(MAX_PHYSMEM_BITS)
#error Sparsemem is not supported on this platform
#endif

#endif

And "arch/arm/include/asm/memory.h" does not define either
SECTION_SIZE_BITS or MAX_PHYSMEM_BITS.

In any case, the "CONFIG_SPARSEMEM kernels not supported..."
error message is printed in sparse_mem_init(). But that function
should return immediately because IS_SPARSEMEM() should be FALSE
because the SPARSEMEM bit should not be set:

#define IS_SPARSEMEM() (vt->flags & SPARSEMEM)

void
sparse_mem_init(void)
{
ulong addr;
ulong mem_section_size;
int dimension;

if (!IS_SPARSEMEM())
return;

... [ cut ] ...

if (!MAX_PHYSMEM_BITS())
error(FATAL,
"CONFIG_SPARSEMEM kernels not supported for this architecture
");

In your case, IS_SPARSEMEM() is returning TRUE because
the SPARSEMEM bit in vt->flags is getting set here:

if (kernel_symbol_exists("mem_section"))
vt->flags |= SPARSEMEM;

... [ cut ] ...

sparse_mem_init();

I have 3 sample ARM dumpfiles, versions 2.6.35-rc3, 2.6.36-rc6, and
2.6.38-rc2, and none of them have a "mem_section" variable, so it
does not make it to the "if (!MAX_PHYSMEM_BITS())" check above.

The kernel's "mem_section" variable is declared in mm/sparse.c:

#ifdef CONFIG_SPARSEMEM_EXTREME
struct mem_section *mem_section[NR_SECTION_ROOTS]
____cacheline_internodealigned_in_smp;
#else
struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]
____cacheline_internodealigned_in_smp;
#endif
EXPORT_SYMBOL(mem_section);

But the mm/Makefile only builds sparse.c into the kernel if
CONFIG_SPARSEMEM is turned on:

obj-$(CONFIG_SPARSEMEM) += sparse.o

So I don't understand how your kernel could have (and compile with)
a "mem_section" variable, since it needs MAX_PHYSMEM_BITS?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility


All times are GMT. The time now is 09:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.