You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the page_cache_fetch function only receives a virtual address to be retrieved. While this is sufficient for small traces where the target process is known, if we are tracing across processes or between kernel and userspace, we need to know what table to use to translate the virtual address with to grab the underlying page. As this information is carried in the PT buffer, having an "active pt" variable should be very low overhead on the libxdc side.
The text was updated successfully, but these errors were encountered:
On the surface, that seems quite simple, but it becomes quite a bit more involved once we think about it: how do you handle address collisions in the disassembler? We would need to keep one CFG copy for each CR3 and we would need to switch between those, I guess. Would you also need one bitmap per CR3? Maybe, we could return from the decoder with a "(CR3 Switch to u64, decoding stopped here: u8*, size_remaining: usize)" tuple, allowing the logic to multiplex between different decoders, but that would be somewhat more involved.
Juggling multiple decoders would be fine if each is assosciated with an address space. In the long term this will be something we'll need as we would want to be able to fuzz code crossing address spaces.
Currently the
page_cache_fetch
function only receives a virtual address to be retrieved. While this is sufficient for small traces where the target process is known, if we are tracing across processes or between kernel and userspace, we need to know what table to use to translate the virtual address with to grab the underlying page. As this information is carried in the PT buffer, having an "active pt" variable should be very low overhead on thelibxdc
side.The text was updated successfully, but these errors were encountered: