problem mapping physical address from /dev/mem

[rohan puri]

On Fri, Oct 7, 2011 at 3:29 PM, rohan puri <rohan.puri15 at gmail.com> wrote:

>
>
> On Fri, Oct 7, 2011 at 12:41 PM, Vaibhav Jain <vjoss197 at gmail.com> wrote:
>
>> On Thu, Oct 6, 2011 at 9:42 PM, rohan puri <rohan.puri15 at gmail.com>wrote:
>>
>>>
>>>
>>> On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain <vjoss197 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa <
>>>> mulyadi.santosa at gmail.com> wrote:
>>>>
>>>>> Hi...
>>>>>
>>>>> On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain <vjoss197 at gmail.com> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I am trying to run a program that scans memory from a given physical
>>>>> address
>>>>> > using /dev/mem.
>>>>> > It uses mmap to map physical address from /dev/mem. So to start with
>>>>> I used
>>>>> > /proc/iomem to look up the
>>>>> > physical memory mapping and found the address 00010000 to be the
>>>>> starting
>>>>> > address for System ram. But whenever I
>>>>> > provide this address to the program it throws an error of "Operation
>>>>> not
>>>>> > permitted".
>>>>>
>>>>> Probably this could also due to mmap NULL dereferencing protection (at
>>>>> least that's how I name it :) )
>>>>>
>>>>> By default, the lowest 65536 byte (10000 in hex) is protected from
>>>>> mapping etc. It practically render such null dererefencing useless.
>>>>>
>>>>>
>>>>> --
>>>>> regards,
>>>>>
>>>>> Mulyadi Santosa
>>>>> Freelance Linux trainer and consultant
>>>>>
>>>>> blog: the-hydra.blogspot.com
>>>>> training: mulyaditraining.blogspot.com
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I tried the same with other addresses (greater than 0x10000 ) also but
>>>> it is throwing the same error.
>>>> Is there a way to get over this ?
>>>>
>>>> Thanks
>>>> Vaibhav Jain
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>> Hi Vaibhav,
>>>
>>> This is how it can be done. Refer link
>>> http://www.theknotter.net/system-memory-dumps-on-linux/
>>>
>>> I have attached the modified code which disables the socket creation part
>>> and dumps the output in a file.
>>>
>>> Regards,
>>> Rohan Puri
>>>
>>
>>
>> Thanks Rohan for the code but I already have a code that reads memory
>> using /dev/mem and mmap.
>> Only difference is I have to manually change the starting address in
>> program. The problem is whenver I give
>> any System RAM address the mmap call fails with 'Operation not permitted'.
>> I googled a little and found that normally
>> this operation is not allowed and the kernel has to be compiled with
>> CONFIG_STRICT_DEVMEM disabled to read any memory
>> location in this way. I also found out about the boot option
>> 'strict-devmem =0'. I tried both these options but none of them seems to
>> working.
>> So I am trying to figure out if there is some other setting that I need to
>> change.
>> I am doing this on Fedora 15 - 2.6.38 kernel.
>>
>> Thanks
>> Vaibhav Jain
>>
>>
> Hi Vaibhav,
>
> My iomem file : -
>
> 00000000-0000ffff : reserved
> *00010000-0009f3ff : System RAM*
> 0009f400-0009ffff : reserved
> 000c0000-000c7fff : Video ROM
> 000cc000-000ccfff : Adapter ROM
> 000cd000-000cffff : pnp 00:0c
> 000e0000-000effff : pnp 00:0c
> 000f0000-000fffff : reserved
>   000f0000-000fffff : System ROM
> *00100000-cf6dffff : System RAM*
>   01000000-015dadf2 : Kernel code
>   015dadf3-01ab907f : Kernel data
>   01bb1000-01d04fff : Kernel bss
>
> Now the program which i sent you, with that I am able to read the 1st part
> of System RAM successfully. I am getting the operation not permitted error
> from mmap  for second part of System RAM. Can you verify the same on your
> system. I mean are you able to read the 1st part (if your System RAM is
> divided) or not ?
>
> Regards,
> Rohan Puri
>

Another way to get the memory map is install crash module on your system and
access the memory by accessing the new device /dev/crash instead of /dev/mem

Regards,
Rohan Puri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111007/2aa89126/attachment.html