dr_query_memory_ex() should not fail on kernel memory

[derekbruening]

From m...@google.com on September 10, 2014 05:27:53

My config: Win 8.1 x64, using DynamoRIO for 32-bit processes DynamoRIO version: 4.2.2725

When I call dr_query_memory_ex() with 0x7fff0000 (== MmUserProbeAddress) as an argument it fails (returns false). There's no info in documentation about the function behavior if we pass kernel memory address as an argument. There's no way to retrieve MmUserProbeAddress from user mode, so now the only way to enumerate process memory is to ignore memory regions where dr_query_memory_ex() fails, but that looks like an ugly hack (I can miss other issues by silencing the error). The proposition from Derek was to return DR_MEMTYPE_KERNEL for kernel memory regions, which should solve the problem.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1538

[derekbruening]

From bruen...@google.com on September 10, 2014 08:27:54

On Windows, dr_query_memory_ex() uses the NtQueryVirtualMemory system call to obtain its information. The system call fails with STATUS_INVALID_PARAMETER if an address higher than MmHighestUserAddress (0x7ffeffff) is passed in.

To implement this feature request, dr_query_memory_ex() would have to distinguish STATUS_INVALID_PARAMETER due to a kernel address from all other possible invalid parameters and return something like DR_MEMTYPE_KERNEL. However, it would not have any further information on the memory being queried, as it is not possible to get that information from the kernel.

Labels: OpSys-Windows Component-API GoodContrib

[derekbruening]

From bruen...@google.com on September 19, 2014 14:01:09

Just to re-iterate, using something like VirtualQuery to walk the address space on Windows would have this same problem

Status: Accepted
Owner: bruen...@google.com

[derekbruening]

From derek.br...@gmail.com on September 23, 2014 12:34:32

This issue was closed by revision r2850 .

Status: Fixed

[derekbruening]

From m...@google.com on October 02, 2014 11:12:33

This still fails, but now for another address: 0x7fff1000. It returns false and sets type to DR_MEMTYPE_ERROR. The problem is probably in that the first call to VirtualQuery successes, but the following call fails (win32/os.c): 5071 if (query_virtual_memory(pb, &mbi, sizeof(mbi)) != sizeof(mbi)) 5072 break;

You should take into account the case when you start the loop within a correct user memory block and right after it you fall into kernel memory. In that case only subsequent calls to query_virtual_memory() will fail.

Please reopen the ticket.

[derekbruening]

From zhao...@google.com on October 05, 2014 11:27:27

Status: Accepted