search

sslab-gatech / unisan

UniSan: Proactive Kernel Memory Initialization to Eliminate Data Leakages
MIT License
42 stars 20 forks source link

Type comparison used for global call-graph seems invalid, thus it generates incomplete call-graph #3

Open hal-ler opened 7 years ago

hal-ler commented 7 years ago

The different Modules loaded by UniSan use different LLVM contexts. In LLVM the basic types are only guaranteed to be unique within a given context. As such char* between two modules will have a different Type instance. See http://llvm.org/docs/doxygen/html/Type_8cpp_source.html#l00182 and http://llvm.org/docs/doxygen/html/LLVMContextImpl_8h_source.html#l00975 for an example.

Furthermore struct types are only deduplicated in the linker phase as far as I am aware of. Even if you use the same the context, you will get different type instances for the same struct declaration (see https://groups.google.com/forum/#!topic/llvm-dev/3Eud9pfFUr).

The test should be simple with an indirect call to a function defined in another bytecode file, which takes both primitive arguments (char, short) as well as a struct or stuct pointers.

As always, please provide updated coverage numbers after every fix (including issue 1). If the coverage does not change at all, then it is great and still important to see, since you have confirmation that the issue did not affect the security offered by UniSan.

hal-ler commented 7 years ago

Actually for the test you want to have the address taking operation in another bytecode file from the call-site, because those are the sources of the types that you are comparing.