-
-
Notifications
You must be signed in to change notification settings - Fork 316
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
Fix frida libafl after #1523 #1560
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, sorry for that! The fix makes sense, LGTM!
// these references both into the struct that we return and the transformer callback | ||
// that we pass to frida-gum. | ||
// | ||
// These moves MUST occur before the runtimes are init-ed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! I'm wondering whether there's any way to enforce this invariant with types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. It was breaking things for me, very very subtley.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to suggestions for how to enforce this with types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how/why does it make a difference when you create the refcell? It really shouldn't, or we're holding it wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is another instance of frida/frida-rust#76. The lifetime of the ranges needs to outlive the lifetime of the transformer. Since ranges would otherwise be returned owned by the helper, their lifetime is tied to the lifetime of the helper. Ideally, we would need to then ensure the helper outlives the transformer. By using Rc
, we're just manually ensuring that the ranges can outlive the transformer even if the lifetime of the helper ends prematurely.
If the transformer could have a lifetime that's consumed by unfollow, and we can have that "owned" by the helper, then we could guarantee that the ranges outlive the helper just by owning both of these on the transformer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not just that. During runtime init, we build assembly sequences which refer to the addresses of their containing runtimes. So it is critical that runtime init happen after the final MOVE. Once we move into the refcell, we never move again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that sounds like something that could benefit from Pin
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, everything that's not pinned is free to be moved at any time, even if it's in a refcell. That it works right now is probably just accidental, but sounds like UB.
Let's Pin inside the refcell? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I never managed to wrap my head around Pin. @fabianfreyer do you want to take a stab at it?
This fixes Frida after PR #1523