Investigate a way to retrieve device physical memory ranges

[tandasat]

Attached code in How to hide a hook: A hypervisor for rootkits uses the below registry data to retrieve physical memory ranges.

• \Registry\machine\HARDWARE\RESOURCEMAP\System Resources\Physical Memory

It seems that it contains physical memory ranges for devices, which is not listed by MmGetPhysicalMemoryRanges(). If we can obtain device memory ranges, we may be able to delete EPT entries pre-allocation code because we could allocate all of them at initialization stage.

Investigate the contents of the registry data and update code if possible.

[tandasat]

I found a way to obtain ranges from a driver bud decided not to use the ranges and initialize all EPT entries for the ranges.

How to get ranges

This Source.cpp.txt lets you get ranges of RAM, Reserved, Loader Reserved and PCI memory ranges, which seem to cover all possible physical addresses that can be accessed by the kernel and devices. This
logs.txt is output from my laptop.

Consideration

Using the ranges and allocating all EPT entries would have some benefits. Primary one would be (1) taking off limitation in a number of EPT entries that can be allocated at the run-time. Currently, only kVmxpNumberOfPreallocatedEntries pages are allowed to use to build EPT entries at run-time. That could potentially cause a bug check when this limitation is exceeded. Secondly, (2) code with regard to pre-allocation for EPT entries could be taken off and simplified. Thirdly, (3) run-time guest performance, especially networking and disk I/O I guess, would be improved since no EPT violation would be caused for device memory ranges.

However, allocating all EPT entries for all those ranges would take significantly large amount of non paged pool. For example, the largest range in the attached log equals to 454912 pages, which takes 888+ (454912 / 512 .. 512 = a number of pages that can be managed with 4096 bytes of an EPT entry) pages of non paged pool to manage. Considering the fact that current code only takes 50 pages (defined by kVmxpNumberOfPreallocatedEntries) for EPT entries to manage those device ranges, this increase is significant.

Also, there is a limited benefit actually, I have seen neither a bug check due to (1) nor user perceived slowness due to (3), for example. While (2) is a benefit, taking off pre-allocation code could lead to a bug check when outside of the enumerated ranges is accessed for some reason (may be because the ranges do not cover all addresses, for example?).

Therefore, I do not think allocating all EPT entries based on the enumerated ranges and taking off pre-allocation code is not a sensitive approach.

[ionescu007]

Satoshi,

Using 2MB and 1GB mappings you can map MMIO very efficiently using only a minimal amount of NP. This is the approach SimpleVisor takes.

[tandasat]

I have been forgotten those options until I saw the updates in SimpleVisor.

At this time, priority of this enhancement is low since it is optimization (for readability and run-time performance) which does not provide any values directly, but it is an worthwhile idea., especially if we could achieve it with lower memory consumption.

I reopen the ticket for further investigation with the idea on large EPT mappings. Thanks!

[tandasat]

Instead re-using the same ticket, I have created #29 since it has an different goal from what this ticket intended for originally.