-
Notifications
You must be signed in to change notification settings - Fork 750
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 restore causing unicorn cpu exception #892
Conversation
Also, I've added the new test_snapshot.py file to the linux script for running all its tests. I think the test should be capable of running on windows, but can't test that right now. The only reason why it might not run on windows is the hardcoded path separators which are different between linux and windows (but then again, python might be smart enough to convert them). |
The test should be in test_elf. but again, we already have the same test? any reason why we need a new code and there are no changes in the code ? |
There is a change to the code, see changes to file The reason that I created a separate test file instead of putting the test in |
besides moving the location for mem restore. i did not see any changes in core.py |
There are few similar snapshot test eg, Line 33 in 35db51a
will you be able to move it to your new snapshot test ? |
Moving the location of mem restore is the fix. That way memory is mapped before the GS register is loaded.
Yes, I can move that to the |
linux and windows test always seperate. due to dll restriction. So, you can either
method 1 is cleaner |
Now I'm thinking about this again. and I think option 1 is better, to put my test in I agree that the linux and windows tests should be separate, but I think that |
…exception When restoring a snapshot created with reg=True a unicorn cpu exception can be thrown when restoring the GS register. It looks like for at least 32bit mode on X86 processors unicorn will validate memory structures pointed to by loaded GS reg. If the memory is not loaded the validation will surely fail, and thus the exception. The fix is then to load the memory maps first, before loading the registers. Note, this validation does not happen when restoring via cpu_context. Included is a test case which will have errors if this fix is not applied.
da480ff
to
a97010c
Compare
There are some issue with elf test runs on windows. that is the reason why we did not run linux test on windows. |
What are some of the issues? |
checkout issue #333 or just run the test in windows. |
merge for now, thanks! |
When restoring a snapshot created with reg=True a unicorn cpu exception can
be thrown when restoring the GS register. It looks like for at least 32bit
mode on X86 processors unicorn will validate memory structures pointed to by
loaded GS reg. If the memory is not loaded the validation will surely fail,
and thus the exception. The fix is then to load the memory maps first,
before loading the registers. Note, this validation does not happen when
restoring via cpu_context.
Included is a test case which will have errors if this fix is not applied.
Checklist
Which kind of PR do you create?
Coding convention?
Extra tests?
Changelog?
Target branch?
One last thing