Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux mode mem dumps do not contain all physical memory #219

Open
jasocrow opened this issue Nov 29, 2024 · 3 comments
Open

Linux mode mem dumps do not contain all physical memory #219

jasocrow opened this issue Nov 29, 2024 · 3 comments

Comments

@jasocrow
Copy link
Contributor

I plan to submit a PR for this at some point, but not sure when I'll be able to get it out.

You can see via the output below that the physical memory range for the target VM is from 0 to 0x1bfffffff. However, the Linux mode mem dump code only saves from 0 to 0xffffffff.

When dumping mem via pmemsave, pmemsave has a size limitation, only allowing a max size of 0xffffffff. So fixing the issue requires calling pmemsave multiple times.

root@linux:~# cat /proc/iomem
00000000-00000fff : Reserved
00001000-0009fbff : System RAM
0009fc00-0009ffff : Reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c99ff : Video ROM
000ca000-000cadff : Adapter ROM
000cb000-000cb5ff : Adapter ROM
000f0000-000fffff : Reserved
  000f0000-000fffff : System ROM
00100000-bffdffff : System RAM
  01000000-021fffff : Kernel code
  02200000-02890fff : Kernel rodata
  02a00000-02cba3ff : Kernel data
  034c9000-035fffff : Kernel bss
bffe0000-bfffffff : Reserved
c0000000-febfffff : PCI Bus 0000:00
  fd000000-fdffffff : 0000:00:02.0
  feb80000-febbffff : 0000:00:03.0
  febc0000-febdffff : 0000:00:03.0
    febc0000-febdffff : e1000
  febf0000-febf0fff : 0000:00:02.0
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : PNP0103:00
feffc000-feffffff : Reserved
fffc0000-ffffffff : Reserved
100000000-13fffffff : System RAM
  13fff0000-13fff03ff : IOAPIC 0
140000000-1bfffffff : PCI Bus 0000:00

This issue can cause inexplicable page faults, e.g.,

bochshooks: PhyAccessHook: Access 8 bytes to GPA 0x210ddefe0.
bochshooks: PhyAccessHook: Access 8 bytes to GPA 0x43fff2000.
wtf: cabi/mem-cabi.cc:34: static bool BX_MEM_C::dbg_fetch_mem(BX_CPU_C*, bx_phy_address, unsigned int, Bit8u*): Assertion `false' failed.
Aborted (core dumped)
@0vercl0k
Copy link
Owner

0vercl0k commented Dec 3, 2024

Sounds good - let me know if you need any help!

Cheers

@anvbis
Copy link

anvbis commented Jan 25, 2025

I've been dealing with this issue a lot recently, so I've actually already implemented a fix for this.

@jasocrow figured I'd run my approach by you first just to get your thoughts: instead of calling pmemsave multiple times, my approach calls dump-guest-memory and then converts the output elf to a raw memory dump. If you're happy with this I'll open a PR.

Either way I'm not a massive fan of pmemsave or converting the memory dump into a raw format - it tends to produce dump files that are much larger than the actual physical memory being captured. So this still feels like a temporary solution.

A better solution imo would be to implement a memory dump parser that handles ELF files, instead of using Windows memory dumps for Linux mode.

@jasocrow
Copy link
Contributor Author

@anvbis Seems like a decent approach to me. Thanks for taking a stab at it.

anvbis added a commit to anvbis/wtf that referenced this issue Jan 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants