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

when guards are dropped out of order the original function is never restored #6

Open
kazcw opened this issue Nov 10, 2018 · 2 comments

Comments

@kazcw
Copy link

kazcw commented Nov 10, 2018

This is inherent to the API, as there's no reasonable interpretation of what version to "restore" in such a case; so it might just be one for the "no monkey business" section of the manual

@mehcode
Copy link
Owner

mehcode commented Nov 10, 2018

We should probably at least use a mutex keyed to the target function address.

@kazcw
Copy link
Author

kazcw commented Nov 10, 2018

Stacked patches of the same function would trigger Mutex::lock's unspecified behavior, and dynamically-created mutexes wouldn't help the thread safety issues.

If there were a singleton Patcher object, the borrow checker could ensure stacked guards aren't dropped out of order. Sharing the Patcher between threads would require protecting it with a Mutex, which would eliminate some of the possible race conditions (the read/write one, and also the mprotect/write one, but not the write/execute one).

kazcw added a commit to kazcw/guerrilla that referenced this issue Nov 10, 2018
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