search

eurecom-s3 / symcc

SymCC: efficient compiler-based symbolic execution
http://www.s3.eurecom.fr/tools/symbolic_execution/symcc.html
GNU General Public License v3.0
776 stars 135 forks source link

Make tests endianness-agnostic #20

Closed mephi42 closed 4 years ago

mephi42 commented 4 years ago

Currently tests take binary input in little-endian format and thus fail on big-endian systems.

Fix by converting inputs to network byte order, using ntohl() in tests and providing the symbolic ntohl() wrapper. Other functions from this family could be similarly added as well, but it is not required for this fix.

sebastianpoeplau commented 4 years ago

Cool, thanks! May I ask which big-endian architecture you're using SymCC on?

mephi42 commented 4 years ago

I'm trying to use it on IBM Z (aka s390). AFL's LLVM mode already works there, so after your FuzzCon presentation I thought I could try improving the fuzzing results with symcc. The first step was to build it and try the test suite - there is by the way a small linker problem with missing set_curterm and other libtinfo symbols when linking with libSymRuntime, which I solved in my setup by just adding -ltinfo to symcc.in - but I'm not sure whether this is the right solution. I haven't finished doing all the stuff described in Fuzzing.txt yet, but plan to do so in the near future.

Thanks for the fixes - I haven't realized that _sym_get_parameter_expression() returns nullptr for concrete values (now I see that its return value comes from getSymbolicExpressionOrNull()).

sebastianpoeplau commented 4 years ago

I'm trying to use it on IBM Z (aka s390).

Nice! Let me know how it goes :)

The first step was to build it and try the test suite - there is by the way a small linker problem with missing set_curterm and other libtinfo symbols when linking with libSymRuntime, which I solved in my setup by just adding -ltinfo to symcc.in - but I'm not sure whether this is the right solution.

I've had a similar problem recently when building on another system. I think it's because libSymRuntime is linked against libLLVMSupport, which in turn requires libtinfo. When LLVM is built statically, however, our build system misses the fact that libtinfo should be included. I'll look into it - for now, a good workaround for me was to add "tinfo" here.

Actually, there's something else regarding endianness that came to my mind: _sym_read_memory and _sym_write_memory take a parameter little_endian that we currently set to true whenever integers are accessed in memory. I guess we'll need to make the input dependent on __BYTE_ORDER__ instead... I don't have a big-endian setup to test at the moment though.