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

qsym vs klee #10

Open
oneCoderMan opened this issue Sep 26, 2020 · 8 comments
Open

qsym vs klee #10

oneCoderMan opened this issue Sep 26, 2020 · 8 comments

Comments

@oneCoderMan
Copy link

the klee can't scale to real soft, I want to know why not choose qsym ?

@junxzm1990
Copy link
Collaborator

junxzm1990 commented Sep 26, 2020 via email

@oneCoderMan
Copy link
Author

thanks a lot

@oneCoderMan
Copy link
Author

I'm new to this field。After getting crash, what kind of tools are used to analyze? Is GDB used to analyze vulnerability location?

thanks a lot again!

@evanmak
Copy link
Owner

evanmak commented Sep 28, 2020

GDB is fine. BTW, it is pretty easy to integrate QSYM into SAVIOR, we have an internal support for that, it will be released soon, stay tune!

@LebronX
Copy link

LebronX commented Sep 30, 2020

I fully agree QSYM is also a very good choice, but I did not see a major difference in "scalability" between KLEE and QSYM. And the truth is our klee-concolic-executor is optimized to be faster than QSYM. We are open to further discussions -:)

-Jun
________________________________ From: oneCoderMan [email protected] Sent: Saturday, September 26, 2020 3:40 AM To: evanmak/savior-source [email protected] Cc: Subscribed [email protected] Subject: [evanmak/savior-source] qsym vs klee (#10) the klee can't scale to real soft, I want to know why not choose qsym ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fevanmak%2Fsavior-source%2Fissues%2F10&data=02%7C01%7Cjxu69%40stevens.edu%7Cdf415b763d9e4ad293b908d862089351%7C8d1a69ec03b54345ae21dad112f5fb4f%7C0%7C0%7C637367136254924818&sdata=6%2BPHnWv75CLxKVgtMaXqrl6QH1eN7vz0QyYFyK5TS%2Bg%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABMOZAMLO5GSRLYXUURXRHDSHXAJPANCNFSM4R22JEMA&data=02%7C01%7Cjxu69%40stevens.edu%7Cdf415b763d9e4ad293b908d862089351%7C8d1a69ec03b54345ae21dad112f5fb4f%7C0%7C0%7C637367136254934813&sdata=r1VdGtJfZybOxl5Iq6r0Ha3Tr9orv1IGHi9ztxHqan0%3D&reserved=0.

It surprise me that the optimized version of KLEE is even better than QSYM

@junxzm1990
Copy link
Collaborator

junxzm1990 commented Sep 30, 2020 via email

@LebronX
Copy link

LebronX commented Sep 30, 2020

I remember a paper last year evaluate the inflation rate of LLVM instruction and machine instruction and it does not look like the difference between the amount of these two kinds of instruction is that big. Perhaps KLEE's simplified version of library functions indeed saves much time.
Systematic Comparison of Symbolic Execution Systems:
Intermediate Representation and its Generation

Anyway, looking forward to the release of your optimized version of KLEE with fork-server mode.

@junxzm1990
Copy link
Collaborator

I remember a paper last year evaluate the inflation rate of LLVM instruction and machine instruction and it does not look like the difference between the amount of these two kinds of instruction is that big. Perhaps KLEE's simplified version of library functions indeed saves much time.
Systematic Comparison of Symbolic Execution Systems: Intermediate Representation and its Generation

Anyway, looking forward to the release of your optimized version of KLEE with fork-server mode.

That's an interesting paper, despite my experience was the difference might be larger.

We have not done a systematic comparison, but when we evaluated SAVIOR against QSYM, our KLEE can run a much larger corpus of seeds.

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

4 participants