0

I am trying to get the (physical) location associated with a particular byte inside a file. How would I go about doing that?

I can't do this in C, because I would have to read the file into a buffer and if I tried getting the physical (not virtual) address in RAM I would get the address of the buffer not the particular byte that is in the file.

Help would be greatly appreciated.

Thanks

Matt
  • 22,721
  • 17
  • 71
  • 112
Falcata
  • 679
  • 1
  • 15
  • 23
  • 1
    Bytes in files do not have addresses as you are thinking of them. They are stored on a disk, not in RAM, and you are asking for an address in RAM. – Dark Falcon Apr 18 '12 at 19:41
  • I have the file "temporarily" store in /shmem which is essentially mapped to RAM. – Falcata Apr 18 '12 at 19:43
  • A byte in a file does not have a memory address unless you read the file's contents to a buffer or map it using mmap. – smichak Apr 18 '12 at 19:46
  • @Falcata: OK, so it is in RAM. Why do you need the physical address? Normally nothing but the OS itself deals with the physical address. – Dark Falcon Apr 18 '12 at 19:47
  • 1
    I know there is a problematic bit in memory, which is causing device errors. Now normally on an embedded system I would run memory tests with nothing else on the device, but in this particular case this is a secure device...so not a lot of options. I've narrowed down the fault to a location, and I've been able to find a location within RAM by writing out to /shmem and reading it back in. Now I want to get the physical address of the byte where the problem occurs. – Falcata Apr 18 '12 at 19:51
  • You need to be able to run privileged (kernel-level) instructions on your CPU. I suppose you can't do that on a "secure" device. – n. m. could be an AI Apr 18 '12 at 19:57
  • Get your best reworker to swap all the RAM chips. If they're encased in epoxy, securely scrap the board. It's not worth fiddling about. If one bit is duff, the whole batch of RAM chips is suspect. If you don't want this thing back for repair again in a month, swap out all the RAM chips or scrap. – Martin James Apr 18 '12 at 21:28

2 Answers2

2

Map the shared memory into your process via mmap, access the page containing the bad data, then read /proc/self/pagemap to find information about how the virtual memory page maps to physical memory.

 * /proc/pid/pagemap.  This file lets a userspace process find out which
   physical frame each virtual page is mapped to.  It contains one 64-bit
   value for each virtual page, containing the following data (from
   fs/proc/task_mmu.c, above pagemap_read):

    * Bits 0-54  page frame number (PFN) if present
    * Bits 0-4   swap type if swapped
    * Bits 5-54  swap offset if swapped
    * Bits 55-60 page shift (page size = 1<<page shift)
    * Bit  61    reserved for future use
    * Bit  62    page swapped
    * Bit  63    page present

   If the page is not present but in swap, then the PFN contains an
   encoding of the swap file number and the page's offset into the
   swap. Unmapped pages return a null PFN. This allows determining
   precisely which pages are mapped (or in swap) and comparing mapped
   pages between processes.

   Efficient users of this interface will use /proc/pid/maps to
   determine which areas of memory are actually mapped and llseek to
   skip over unmapped regions.

Note: This seems to be on newer kernels only. Also, here is how to translate the PFN into a physical address.

Dark Falcon
  • 43,592
  • 5
  • 83
  • 98
0

In order to do that, you should inspect the filesystem directly through a device. Which means you should be able to locate bitmap tables, i-node tables, directory entries and similar things. This is not trivial at all with modern and upcoming filesystems (e.g. Btrfs).

Apart from that, you should have to deal with block and sector offsets or addresses (maybe LBA or maybe cylinder based).

So, in my opinion, the answer is no or, at least, its solution would be incredibly complex.

C2H5OH
  • 5,452
  • 2
  • 27
  • 39