Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass active cr3 info to page_cache_fetch function #4

Open
tklengyel opened this issue Aug 31, 2020 · 3 comments
Open

Pass active cr3 info to page_cache_fetch function #4

tklengyel opened this issue Aug 31, 2020 · 3 comments

Comments

@tklengyel
Copy link
Contributor

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.

@eqv
Copy link
Member

eqv commented Sep 1, 2020

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.

@tklengyel
Copy link
Contributor Author

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.

@eqv
Copy link
Member

eqv commented Sep 1, 2020

I don't think this is super relevant to our use case for the while being, but I would gladly merge a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants