-
Notifications
You must be signed in to change notification settings - Fork 5
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
Help compiling cgc programs #7
Comments
Hi, thanks for your test. Can you remove the
|
Thank you for the response! I am not sure if it solves the problem but we dont have the call to exit at main's head anymore. Can you give me an insight on what is happening how does this contribute to solving the issue? Does this still prune paths? |
It is the incompleteness issue of the bc files provided not including all the code that causes the reachability analysis not to find reachable paths to the target. Meanwhile, the reachability analysis has different granularity since different alternatives may perform better for diverse projects. Therefore, the main function can be pruned since it is not found through our backward propagation. You can refer to the answer in the FAQ and use our script that provides a different version of the reachability analysis (, which is also the one we used for the paper evaluation). PS: The correct compilation process that can include everything in one bc file seems to be a very crucial obstacle for using static analysis in real-world applications. |
Thank you for your response. Respectfully, I dont think this is the problem. The example above is a single-unit file, so I dont think there is incompleteness in terms of bitcode files in this particular example. Unless you mean the stdlib (which is the only thing missing here), then all programs will be missing that.. no? I think this maybe a bug, or I am misusing something.
Running all the commands above succeed. Yet Beacon still early-terminate at main function head. There is not indirect-calls, no inter-procedural dependency, no pointer deference. I am wondering if you can reproduce this or is it something with my tool chain or execution. Thanks for the help! |
Everything is working on my side. Here are the related files generated for your reference. Make sure you have the correct target location and the bc file with the debug info. |
Hmm. Something must off in my steps. Does my commands above looks correct? Could you please also upload log.txt, range_res.txt and the output bitcode of Beacon's Ins? I would like to compare with my output to know where I went wrong. If you used a different commands than mine above please let me know as well. I really appreciate your help and response! Thanks. |
My clang command does include the debug info and target location seem to be found with Beacon. Also, I seem to generate the same bbreaches.txt file, so thats why I want to compare the rest of the output files. Thanks again! |
As far as my environment, I am using the Beacon docker container and running the test above inside it. |
You should use the tool to compile the code from scratch. The version in the container has some bugs that have been modified. If you are still having issues, please let me know. I have been really busy recently and will come back to this issue afterward. Sorry. |
Hello!
I am trying to run Beacon against cgc benchmarks. For about 100 of them which are the ones I tested Beacon against, Beacon seems to just insert an exit call right at the beginning of the main function, deeming the binary useless. I only run Beacon against linked llvm bitcodes so everything should be there and the binaries are small enough for static analysis I think. I am wondering if I am doing something wrong? Let me put up a case here as an example with the simplest cgc binary CADET_00001. Its source code (with all needed library, in one unit):
service.c:
The target here is server.c:88; a simple buffer overflow. Here is the exact commands I ran afterwards:
This gives out a working
service
binary. Now for Beacon:Non of those commands fail, all complete successfully as far as return codes. However, as I said in my intro, we can see the exit call inserted by Beacon in
fuzz-Beacon-CADET_00001-instrumented.bc
; the output of Beacon'sIns
.Any chance you can give me a clue what contributes to this? I am open to suggestions even as far as minor modification of the code being tested to maybe remove problamatic library calls that impact static analysis this severely even on a very basic binary.
Thank you so much for your help!
The text was updated successfully, but these errors were encountered: