Re: [Qemu-discuss] Regarding QEMU Monitor "x /fmt addr" command

[Jakob Bohm]

On 17/01/2019 19:57, Peter Maydell wrote:
> On Thu, 17 Jan 2019 at 18:54, Phil Jones <address@hidden> wrote:
> > Sorry, I meant address of an integer variable inside of a process. Thank you 
> > for the answers, that confirms my suspicions. If I were to translate guest 
> > process virtual address to Windows physical address, could I use that to read 
> > value?
> Only if you do the virtual-to-physical translation
> exactly at the point when the relevant process is
> in memory and when the memory is swapped in and not
> out on disk, and you don't let the guest run between
> the point when you do the translation and when you use
> it. (Otherwise windows could swap something out or
> change to a different process.) But if it worked to
> do that then the 'x' command would work too.
>
> thanks
> -- PMM

Note that on Windows, there are low level ways to get (and optionally
lock) a range of  process-address-space virtual memory addresses to
the (qemu virtualized) physical addresses.

These ways include:

1. Having a cooperating kernel module ("driver") make the appropriate
  calls, as if it was planning to pass this memory to a piece of non-
  standard DMA/bus-master hardware (not the higher level calls that
  refer to specific busses like PCI or devices like virtio disk 2).
   In the future, someone might add this to one of the qemu helper
  client drivers, as something accessible from the gdb stub.  Note
  that a few undocumented calls may be needed to get a pointer to a
  chosen process.  Also note kernel mode driver signing problems.

2. Using the builtin WinDbg stub in the Windows kernel.  This was
  always meant to be accessed from a different (Windows) machine,
  and as such can usually be mapped to a qemu device that can then
  be forwarded to another virtual machine running just WinDbg and
  associated data.  WinDbg has command line versions too (kd.exe
  for talking to the stub in the Windows kernel).

3. Using Windows-build specific symbol information (available via
  a special "debug use only" "public symbol server" service) to
  locate the memory mapping structures for processes and mapping
  it to "physical" addresses, this latter method is the one that
  has the fewest side effects on the virtual machine, but doing
  this reliably requires some deep experience, or helper scripts
  developed by someone else.

The above applies to all versions of NT-based Windows (not 100%
certain about the ARM ports though, but i386, AMD64, MIPS, PPC and
Alpha should be fine).  For the VxD based Windows (Windows 3.x in
"enhanced mode", Windows 95,98 and Me) each of the 3 methods are
somewhat different, and I don't think there is a command line
version of the kernel mode debugger clients (WDEB386.exe).

Windows 3.x in "standard mode" or "real mode" generally keeps a
mostly 1:1 virtual to physical mapping.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded