[llvm-dev] When is a store not (memory) safe?
Jonas Wagner via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 4 00:54:28 PDT 2016
Hi,
My current approach would be to declare every pointer as unsafe that is
> computed somewhere by a GEP instruction with non constant indices, as well
> as constant indices that can be proven to be out of
> bounds (but that would be more a thing for the compiler to complain).
>
Are you assuming that you see the entire program (something like using
LTO)? Otherwise one of the main difficulties will be that the provenance of
pointers are unknown. For example, you might see a function that receives a
pointer argument, and have no idea where that function is called from. Or
some code might use a global, and you don't know what the value of the
global is. Or a pointer is read from memory, and you don't know which
instruction modified it.
There is definitely a lot of work already in this area. For large
real-world software, I believe the idea of proving memory safety is not
feasible yet; for those people tend to use dynamic (run-time) checks
instead, e.g., AddressSanitizer
<http://clang.llvm.org/docs/AddressSanitizer.html>.
For statically proving accesses, there are ideas such as abstract
interpretation, model checking, CEGAR, separation logic... I think a good
place to get an overview of current tools is the software verification
competition <https://sv-comp.sosy-lab.org/2016/>. Some of the participants
there are open-source and based on LLVM.
Cheers,
Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/48d1a008/attachment.html>
More information about the llvm-dev
mailing list