Memory trap/access size

[pwnosaur]

The theory is closely tied to how the operating system manages memory allocations and fragmentation.

The approach used by libVMI and DRAKVUF involves handling memory traps by modifying page permissions. When a page fault occurs, the OS checks if the Guest Frame Number (GFN) of the faulting page is listed among those with memory traps. If the GFN is found, the system triggers the associated callbacks for that GFN. These callbacks contain logic to handle the event and check the Physical Address (PA) where the fault occurred.

However, a key limitation exists in the mem_event structure: it lacks details about the size of the memory operation (i.e., how many bytes were read or written). This absence of size information could result in certain memory events being missed or misinterpreted.

Illustrative Example:
Consider a structure that occupies 50 bytes within a memory page, located at an offset of 100 from the beginning of a page. assuming the structure is being monitored for read/write access:

1. The entire page's permissions are adjusted to trigger a page fault upon access.
2. When the fault occurs, the callback checks the Physical Address (PA) of the fault to determine if it falls within the range of the structure.
3. If the fault’s PA is at offset 100 (where the structure begins) from the beginning of the page, it can be confidently concluded that the structure has been accessed, and an event is emitted.

The Problem:
If the fault’s PA is before the structure/memory range (within the same memory page) to be monitored and the operation is a read or write spanning 8 bytes (e.g., starting at offset 93) or more (e.g., using SIMD/AVX instructions), it could affect the monitored structure at offset 100. Since the size of the operation is unknown, it’s unclear whether the faulted access impacts the structure or the memory range being monitored.