Svadev mailing list

[Thomas Sanchez <thomas.sanchz AT gmail.com>]

Thanks for all the explanation (I understood everything :)), it is
very interesting and I will follow the project. Maybe one day I'll be
able to contribute :)

I'm testing it today.

2011/8/19 John Criswell 
<criswell AT illinois.edu>:
> On 8/19/11 10:31 AM, John Criswell wrote:
>>
>> On 8/18/11 11:35 PM, Thomas Sanchez wrote:
>>>
>>> 2011/8/18 John 
>>> Criswell<criswell AT illinois.edu>:
>>>>
>>>> Dear Thomas,
>>>>
>>>> Just an update on this issue.  I successfully got the CompleteChecks
>>>> pass to
>>>> work on your test case, so the invalid load is detected and reported.
>>>>
>>> Awesome!
>>
>> I just realized that I forgot to commit a file in the poolalloc project
>> that is required to get this working.  Please svn up the poolalloc
>> project if you've already gotten the code from SVN and rebuild.
>>
>
> One other thing I forgot: you need to add -emit-llvm to your command line:
>
> clang -g -fmemsafety -emit-llvm -o test test.cpp ...
>
> The -emit-llvm option will induce LLVM link time transforms (including the
> CompleteChecks pass).
>
> -- John T.
>
>
>
>>>> The code may still have some issues, but if you want to try it out, you
>>>> can
>>>> do the following (assuming you are using Mac OS X):
>>>>
>>>> 1) Check out and build SAFECode from the SVN repository.
>>>> 2) Make a backup copy of /usr/lib/libLTO.dylib.
>>>> 3) Copy the libLTO.dylib from the SAFECode build directory (usually
>>>> Debug+Asserts/lib/libLTO.dylib) into /usr/lib.
>>>> 4) Recompile using the new clang compiler you built.
>>>>
>>> I'll do it ASAP, thank you !
>>>
>>>> Be sure to read the Install Guide
>>>> (http://sva.cs.illinois.edu/docs/Install.html) if you attempt to do
>>>> this.
>>>>
>>> By the way, if you don't mind I'm interested by the explanation even
>>> if I won't understand everything :)
>>>
>> Great!
>>
>> So, one of the problems with doing memory safety in a compiler is that
>> there is code that is not compiled along with the program but is instead
>> linked in as native code.  Examples include any of the native code
>> libraries in /usr/lib on most Unix systems.  We call such code external
>> code.  Worse yet, when compiling one source file at a time, the compiler
>> can't tell whether a function is just inside another compilation unit or
>> if it is external code.  Only during the final link phase (in libLTO)
>> can we do whole program analysis and tell the difference.
>>
>> The specific problem in SAFECode's case is that external code can
>> allocate memory objects and return them to the program.  External code
>> can also free objects allocated by the program.
>>
>> So, when you have a pointer and want to know whether it points into a
>> valid memory object, you have a problem: if you can't find the memory
>> object, is it because the pointer is invalid, or is it because the
>> pointer is pointing into a memory object created by external code that
>> the compiler did not analyze and instrument?
>>
>> To get around this, SAFECode has two types of checks: incomplete and
>> complete.  Complete checks fail and report an error if they cannot find
>> the memory object.  Incomplete checks will do the best they can to
>> ensure safety, but if they can't find a corresponding memory object for
>> the pointer, they assume that the pointer points to some unknown memory
>> object and conservatively pass.  Note that incomplete array bounds
>> checking is still quite useful but that incomplete load/store checks are
>> nearly useless.
>>
>> The instrumentation passes in Clang insert incomplete checks by default
>> because code is compiled one source file at a time; it's not possible to
>> figure out what is external code and what is not.  However, libLTO,
>> during the final link phase, *can* determine which pointers can be
>> influenced by external code and which cannot (because it can do whole
>> program analysis).  Therefore, we added a pass called CompleteChecks in
>> libLTO that converts incomplete checks to complete checks when possible.
>>
>> When I fixed CompleteChecks and put it into libLTO, it went and make the
>> load/store checks that Clang was already putting into your program
>> complete, so now they actually catch the error because they know for
>> *sure* that any memory object pointed to by the pointer should have been
>> registered with the SAFECode run-time.
>>
>> BTW, I should warn you that CompleteChecks uses DSA to determine which
>> pointers are influenced by external code and which are not.  DSA is a
>> unification-based points-to analysis, and there has been some concern
>> that it may be covered by the Steensgaard patent.  That's one of the
>> reasons why DSA is not part of LLVM.
>>
>> -- John T.
>>
>> _______________________________________________
>> svadev mailing list
>> svadev AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/svadev
>
>



-- 
Thomas Sanchez
Epitech Paris, Promo 2012
UNIX/C/C++ Teacher Assistant
Laboratory System {Epita,Epitech}.
dotCloud.