-
Notifications
You must be signed in to change notification settings - Fork 561
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
Error happens when elf app doesn’t have a rseq_cs struct #6802
Comments
Hi @VulnDetector ! Can you post the full output that you get after running
Is About getting the same error with |
Thanks for your reply. @edeiana The full output running that I get after running
The full output running that I get when I add
Test is my own app binary,and as illustrated, test doesn’t obey all the constraints in https://dynamorio.org/API_BT.html#sec_rseq, it doesn’t have a rseq_cs struct. So, I follow the https://dynamorio.org/API_BT.html#sec_rseq to set the
I think the problem occurs when I use DynamoRIO to run an app binary which doesn’t have rseq support in a rseq supported environment, the DynamoRIO exit itself. |
I can't test it on the "fortigate vm 7.2.4" and I am not able to reproduce it locally. Also, the reason for that message is that dynamorio/core/unix/rseq_linux.c Line 809 in ef1cd6f
That routine does quite a bit of logging, which you are not capturing, as you got:
My guess is that Is your goal to have your application work under DynamoRIO with |
Thanks a lot. @edeiana
I used DynamoRIO 10.0.0 release to run the command: By the way, there is another problem could you give me some guidance? I use |
You need to add
Pure-assembly apps with zero rseq usage run fine under DR so I do not think this is the problem. |
Thanks for your reply. @derekbruening In the fortigate environment, there is no strace command. So I run command: From the result, it doesn’t call the rseq syscall. I have to explain what I said :
It’s not I debug the DR and get the return value of the rseq_locate_tls_offset() , but I search the error sentence in DR sourcecode, and find the position where it may cause the error sentence. And what you said is also my concern. I think it might be the environment(sreq support environment) but not the app binary itself causing DR to call a |
I would suggest either stepping through |
Describe the bug
Running DynamoRIO to instrument any application on the fortigate(based on linux platform), a fault occurs.
./drrun -- test
(no client at all) results in an error:Restartable sequence behavior is not supported: struct rseq is not in static thread-local storage.
Note that running fortigate’s own app also result a error, include scp etc.
To Reproduce
Steps to reproduce the behavior:
./drrun -- test
Restartable sequence behavior is not supported: struct rseq is not in static thread-local storage
Expected behavior
No error, correct instrumentation.
Screenshots or Pasted Text
Versions
Tested the 10.0.0 release and also a fresh build on master.
Not tested.
Linux version 4.19.13 (root@build) (gcc version 10.3.0 (GCC)) instrument_post_syscall() should be called after post_system_call() processes the real result #1 SMP Tue Jan 31 05:32:20 UTC 2023.
64 bit.
Additional context
This is the same rseq issue as described in #5431.
The problem might be related to rseq. I found the test app have no rseq_cs struct for each rseq region, which is described in https://dynamorio.org/API_BT.html#sec_rseq as limitation 2. I tried to use -disable_rseq option, but it gets the same error.
I found in the #5431 discussing, abhinav92003 said “The final issue I'm running into is I think because the struct rseq is not in the static TLS anymore. (It causes an EINVAL in rseq tests and "struct rseq is not in static thread-local storage" in burst tests). This is as documented at https://sourceware.org/pipermail/libc-alpha/2021-November/133221.html. Also, https://lwn.net/Articles/883104/ says that the rseq registered by glibc is stored in the Thread Control Block maintained by glibc. I'm working on modifying rseq_locate_tls_offset for this.” Function rseq_locate_tls_offset returns 0, then drrun puts the error.
The text was updated successfully, but these errors were encountered: