Git Product home page Git Product logo

beacon_artifact's People

Contributors

5hadowblad3 avatar qhjchc avatar yiyuaner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

beacon_artifact's Issues

Traverse icfg

Hi!
I'm very interested in your research, and I have a question about tool implementation.
The functions doDfsCFL and getReachableNodesForTarget in the source code are both used to obtain reachable nodes. Is there any difference between the two? Specifically, I observed that the function doDfsCFL additionally considers the loop situation of the function call graph. What impact will this have on the analysis?

Segfault

Hi,
when I used Titan for one of my fuzzing targets, the static analysis crashed with a segfault. As the precondInfer is inherited by Beacon, I'm posting this here.
With some further investigation I found out that the crash appeared in file AbstractState.cpp, line 236 in function AbstractState::set:

if (valRange.empty() && memRange.empty()) {
    const Value *placeHodler = *valKeys.begin();
    valRng.insert({placeHodler, Interval::createTop(placeHodler->getType()->getIntegerBitWidth(), true)});
  }

gdb showed that variable placeHodler is a nullpointer, which is then dereferenced in the next line causing the segfault.
The CPP reference states for cases as this that "If the container is empty, the returned iterator value shall not be dereferenced." which is the case here.
I am not sure, why valKeys is empty though and if this might be an error in my configuration, but the other targets worked just fine so far.

My fuzzing target was flex with the following cstest.txt:

misc.c:106
skeletons.c:103
header_nr_main.c:34
bison_yylval_main.c:32
cxx_multiple_scanners_main.cc:46
dfa.c:147
no_bison_stub.c:36
bison_yylval_main.c:39
main.c:350
multiple_scanners_nr_main.c:42
mywc.c:11
header_r_main.c:65
bison_yylloc_main.c:28
bison_yylval_main.c:31
bison_yylloc_main.c:39
skeletons.c:108
libyywrap.c:27
tblcmp.c:597
tblcmp.c:652
sym.c:114
yylex.c:109
ccl.c:195
tables.c:409
mywc.c:14
multiple_scanners_nr_main.c:41
nfa.c:373
ccl.c:49
multiple_scanners_r_main.c:47
buf.c:61
buf.c:82
dfa.c:469
scanflags.c:66
bison_yylloc_main.c:32
bison_nr_main.c:31
header_r_main.c:53
scanflags.c:42
dfa.c:1037
tables_shared.c:68
scanflags.c:67
dfa.c:319
malloc.c:15
malloc.c:6
bison_yylval_main.c:27
tblcmp.c:465
filter.c:148
regex.c:140
no_bison_stub.c:26
main.c:1684
mywc.c:13
misc.c:270
libyywrap.c:26
dfa.c:536
gen.c:53
tables.c:225
skeletons.c:101
header_nr_main.c:35
bison_nr_main.c:30
gen.c:635
cxx_multiple_scanners_main.cc:38
mywc.c:17
nfa.c:602
scanflags.c:56
buf.c:91
top_main.c:53
regex.c:56
misc.c:255
tables_shared.c:65
misc.c:157
misc.c:330
multiple_scanners_r_main.c:48
ecs.c:145
malloc.c:16
tables.c:118
filter.c:153
sym.c:81
ccl.c:142
malloc.c:14
no_bison_stub.c:28
tblcmp.c:368
libyywrap.c:24
sym.c:132
misc.c:422
multiple_scanners_r_main.c:30
top_main.c:65
misc.c:610
regex.c:129
gen.c:179
sym.c:92
scanflags.c:48
gen.c:444
multiple_scanners_nr_main.c:43
cxx_multiple_scanners_main.cc:37
header_r_main.c:52
header_nr_main.c:30
tables.c:235
header_r_main.c:62
regex.c:51
scanopt.c:617
main.c:1459
header_r_main.c:33
libmain.c:26
buf.c:53
realloc.c:15
tblcmp.c:778
main.c:757
skeletons.c:223
misc.c:625
skeletons.c:143
yylex.c:48
misc.c:396
options.c:49
libmain.c:33
yylex.c:51
no_bison_stub.c:30
gen.c:956
options.c:186
tables.c:150

Version of LLVM and SVF user in paper evaluation

I'm trying to reproduce some results from the Titan paper and I'm using the external script for reachability analysis (https://github.com/5hadowblad3/Beacon_artifact/blob/986979a3660288c7b35de3bcf785de65382f1a8c/scripts/icfg_index.py) with LLVM 15 and a recent commit from SVF.

I'm running into an issue on libxml2 (from the MAGMA benchmark) where a function in the C++ standard library (std::numeric_limits<int>::max) is inlined with LLVM 15 and not inlined with LLVM 4. The compiler flags are identical. Because of this Beacon prunes some paths that it should not.

The README mentions:

Moreover, we noticed that with better static reachability analysis, e.g., an upgraded version of SVF with a higher LLVM version, the results can improved with minor analysis overhead. You can also try our [script](scripts/icfg_index.py) for reachability analysis based on the dot files exported by any version of SVF, which could have better precision, which is used in the evaluation for the paper. We are also looking forward to any optimized static analysis techniques proposed to improve Beacon! Drop me an email (hhuangaz at cse dot ust dot hk) if you have any thoughts or ideas ~

What is the version of LLVM and SVF used for reachability analysis in the papers?

bot & top

Kudos to your work first!
I'm new to abstract interpretation. Recently, while reading the source code of beacon, I had doubts about the bottom and top attributes of the interval. What are the stages of analysis where the difference between the two is reflected?

    bool IsTop() const {
      unsigned w = getLB().getBitWidth();
      return getLB() == getMinVal(w, isSigned) && getUB() == getMaxVal(w, isSigned);
    }

    bool IsBot() const {
      return range_gt(getLB(), getUB(), isSigned);
    }

Looking forward to your reply!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.