Some confusion about how to get KLEE to perform symbolic execution on a file (or a function) in redis (llvm bitcode generation)
yinluming13579 opened this issue · comments
Hello! I am a postgraduate student from China and I am currently researching symbolic execution and learning the KLEE tool. I recently read the KLEE team's paper "Combining Static Analysis Error Tracking and Dynamic Symbolic Execution" (Experience Paper) and I was interested in the part of the paper that proposed combining CSA and KLEE, so I pulled down the source code and gave it a try.The main idea of the thesis is to first check the source program using CSA and generate a bug report, subsequently inject the bug report into the source code and subsequently use KLEE to explore and verify the correctness of the bugs based on the paths marked in the source code.
The test set used in the thesis is coreutils, and the thesis script converts the c files in the coreutils dataset into executable files by modifying the makefile file and using the wllvm tool, and subsequently converts the executable files into llvm bitcode files. almost every c file in coreutils is converted into the corresponding llvm bitcode file (e.g. cat.bc).
After reading the paper, I'm going to use KLEE from the article to check redis in the same way: I marked a path in the acl.c file in the redis project that can cause errors (equivalent to injecting the error path reported by the CSA into the source code).
What followed was an exploration of this function using KLEE, and when I compiled redis to llvm bitcode using the following statement: tar -zxvf redis-6.2.1.tar.gz cd redis-6.2.1 make CC=wllvm MALLOC=libc cd src ls, I found that unlike in coreutils, wllvm only generates a few executables and no executable for acl.c. Naturally, there is no way to get the acl.bc file, and here is the information about the compiled file.
Makefile bio.o crc16.d endianconv.o intset.d lzf.h networking.d rdb.c redis-trib.rb server.o sparkline.h tls.c acl.c bitops.c crc16.o evict.c intset.h lzfP.h networking.o rdb.d redisassert.h setcpuaffinity.c sparkline.o tls.d acl.d bitops.d crc16_slottable.h evict.d intset.o lzf_c.c notify.c rdb.h redismodule.h setcpuaffinity.d stream.h tls.o acl.o bitops.o crc64.c evict.o latency.c lzf_c.d notify.d rdb.o release.c setcpuaffinity.o syncio.c tracking.c adlist.c blocked.c crc64.d expire.c latency.d lzf_c.o notify.o redis-benchmark release.d setproctitle.c syncio.d tracking.d adlist.d blocked.d crc64.h expire.d latency.h lzf_d.c object.c redis-benchmark.bc release.h setproctitle.d syncio.o tracking.o adlist.h blocked.o crc64.o expire.o latency.o lzf_d.d object.d redis-benchmark.c release.o setproctitle.o t_hash.c util.c adlist.o childinfo.c crcspeed.c fmacros.h lazyfree.c lzf_d.o object.o redis-benchmark.d replication.c sha1.c t_hash.d util.d ae.c childinfo.d crcspeed.d geo.c lazyfree.d memtest.c pqsort.c redis-benchmark.o replication.d sha1.d t_hash.o util.h ae.d childinfo.o crcspeed.h geo.d lazyfree.o memtest.d pqsort.d redis-check-aof replication.o sha1.h t_list.c util.o ae.h cli_common.c crcspeed.o geo.h listpack.c memtest.o pqsort.h redis-check-aof.bc rio.c sha1.o t_list.d valgrind.sup ae.o cli_common.d db.c geo.o listpack.d mkreleasehdr.sh pqsort.o redis-check-aof.c rio.d sha256.c t_list.o version.h ae_epoll.c cli_common.h db.d geohash.c listpack.h module.c pubsub.c redis-check-aof.d rio.h sha256.d t_set.c ziplist.c ae_evport.c cli_common.o db.o geohash.d listpack.o module.d pubsub.d redis-check-aof.o rio.o sha256.h t_set.d ziplist.d ae_kqueue.c cluster.c debug.c geohash.h listpack_malloc.h module.o pubsub.o redis-check-rdb scripting.c sha256.o t_set.o ziplist.h ae_select.c cluster.d debug.d geohash.o localtime.c modules quicklist.c redis-check-rdb.bc scripting.d siphash.c t_stream.c ziplist.o anet.c cluster.h debug.o geohash_helper.c localtime.d monotonic.c quicklist.d redis-check-rdb.c scripting.o siphash.d t_stream.d zipmap.c anet.d cluster.o debugmacro.h geohash_helper.d localtime.o monotonic.d quicklist.h redis-check-rdb.d sds.c siphash.o t_stream.o zipmap.d anet.h config.c defrag.c geohash_helper.h lolwut.c monotonic.h quicklist.o redis-check-rdb.o sds.d slowlog.c t_string.c zipmap.h anet.o config.d defrag.d geohash_helper.o lolwut.d monotonic.o rand.c redis-cli sds.h slowlog.d t_string.d zipmap.o aof.c config.h defrag.o gopher.c lolwut.h mt19937-64.c rand.d redis-cli.bc sds.o slowlog.h t_string.o zmalloc.c aof.d config.o dict.c gopher.d lolwut.o mt19937-64.d rand.h redis-cli.c sdsalloc.h slowlog.o t_zset.c zmalloc.d aof.o connection.c dict.d gopher.o lolwut5.c mt19937-64.h rand.o redis-cli.d sentinel.c solarisfixes.h t_zset.d zmalloc.h asciilogo.h connection.d dict.h help.h lolwut5.d mt19937-64.o rax.c redis-cli.o sentinel.d sort.c t_zset.o zmalloc.o atomicvar.h connection.h dict.o hyperloglog.c lolwut5.o multi.c rax.d redis-sentinel sentinel.o sort.d testhelp.h bio.c connection.o endianconv.c hyperloglog.d lolwut6.c multi.d rax.h redis-sentinel.bc server.c sort.o timeout.c bio.d connhelpers.h endianconv.d hyperloglog.o lolwut6.d multi.o rax.o redis-server server.d sparkline.c timeout.d bio.h crc16.c endianconv.h intset.c lolwut6.o networking.c rax_malloc.h redis-server.bc server.h sparkline.d timeout.o
I asked my lab brother about this, and my lab brother thinks that the reason why coreutils generates a corresponding bc file for each c file is because of the specificity of the coreutils project: almost every c file in coreutils has a main function, so it can all generate a bc file independently, whereas the redisx acl.c file does not have a main function, and therefore cannot get the corresponding bc file. I'm not sure if this is the reason, or maybe I'm using the wrong instructions for wllvm.
Based on the above, I have some questions here: if I want to check a function in the acl.c file in the redis project (there is no main function in acl.c), can wllvm generate the acl.bc file and KLEE start symbolic execution from a function in the acl.c file that I specify? If wllvm cannot generate the acl.bc file, how should I proceed if I want KLEE to start symbolic execution from a function in acl.c (or the acl.c file)?
Additional information: getting KLEE to execute along the marked route is a function that has been implemented by KLEE in the thesis. My query is that I have marked an error path for the acl.c file in the redis project, but I am currently unable to get KLEE to execute symbolically only on the acl.c file. The reason I am unable to get KLEE to execute symbolically only on the acl.c file is that I am unable to generate the acl.bc file, my confusion is whether the inability to get the acl.bc file is because I am doing something wrong or because acl.bc does not have a main function? If I can't generate a bc file from a c file without a main function, what should I do if I want to explore the c file or function specified in rredis?
can wllvm generate the acl.bc file
For a single file you can just use clang, e.g.:
> clang -emit-llvm -fno-discard-value-names -g -O1 -Xclang -disable-llvm-passes -D__NO_STRING_INLINES -D_FORTIFY_SOURCE=0 -U__OPTIMIZE__ -c acl.cand KLEE start symbolic execution from a function in the acl.c file
See KLEE's --entry-point flag. However, the easiest way is to write a stub program (with main) that calls the relevant function, has the necessary includes + dependencies linked, and symbolises all interesting inputs.
thank you!
It looks like we can close this issue. Please use the KLEE mailing list for future questions (https://klee.github.io/getting-involved/)