[LLVMdev] SAFECode Source Code Released

[John Criswell]

Török Edwin wrote:
> [snip]
>
> I applied the attached patch to make it compile on my box (Debian
> x86_64), only to find out that x86_64 is not supported :(
> This architecture is not supported by the pool allocator!
> Aborted
>   
Thanks for the patch.  What options do I give to the patch command to 
apply it to the source code?

Although there's no documentation about contributions to SAFECode as of 
yet, I'd like to follow the same policy that LLVM uses (notably that the 
copyright of contributions is passed to the University of Illinois).  Is 
this acceptable to you?

We haven't regularly tested SAFECode and Automatic Pool Allocation on 64 
bit architectures, so while it may work, we can't say for certain that 
it will.

This particular error is caused by the fact that the run-time does not 
know which allocator is best for allocating page-aligned sections of 
memory.  If you modify getPages() in 
runtime/BitmapPoolAllocator/PageManager.cpp to use mmap(), 
posix_memalign(), or valloc(), then it will fix this error and allow you 
to continue experimenting with Poolalloc/SAFECode in 64-bit mode.

Eventually, we should set up something in the configure script to find a 
usable default for this function.  This would be a simple autoconf 
change; it just hasn't been high on the priority list.
> I turned off Werror too because I was getting lots of aliasing violation
> warnings (with g++ 4.3.4).
> There are some "cast pointer to integer of different size" warnings, but
> they're all in SVA, and thats the kernel stuff that has nothing to do
> with safecode right?
>   
Which code are you referring to?  I don't believe any of the SVA 
specific code is compiled by default in the mainline SAFECode tree.
> So I've built SAFEcode in a 32-bit chroot (I get the aliasing warnings
> on 32-bit too).
>
> A simple test program works, however when trying to compile ClamAV I get
> an error right on startup, and it aborts!
> The docs say that if I don't use terminate it should go on.
>   
The -terminate option used to work but broke during some refactoring of 
the error reporting code.  Getting it to work again is on my TODO list.  
You can get the behavior you want, for now, by removing the abort() line 
from runtime/DebugRuntime/Report.cpp.

As far as the ClamAV error, are you sure it's a false positive (i.e., a 
bug in SAFECode)?  I ran SAFECode on the programs in 
MultiSource/Applications and found that quite a few programs have memory 
safety errors.

In the case of ClamAV, a false positive might occur if 1) the memory 
object is allocated by a library linked in as native code, or 2) the 
memory object is allocated via some C library function that SAFECode 
doesn't recognize as an allocator (e.g., getenv() or getpwent()).  
Handling the latter requires some simple changes to the DSA analysis and 
SAFECode so that it treats these functions as allocators.

> SAFECode:Violation Type 0x2 when accessing  0x832d228 at IP=0x812b531
>
> =======+++++++    SAFECODE RUNTIME ALERT +++++++=======
> = Error type                            :       Invalid Free Error
> = Program counter                       :       0x812b531
> = Faulting pointer                      :       0x832d228
>
> Program received signal SIGABRT, Aborted.
> 0xf7fdf430 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xf7fdf430 in __kernel_vsyscall ()
> #1  0xf7d713d0 in raise () from /lib/i686/cmov/libc.so.6
> #2  0xf7d74a85 in abort () from /lib/i686/cmov/libc.so.6
> #3  0x08214227 in
> safecode::ReportMemoryViolation(safecode::ViolationInfo const*) ()
> #4  0xf7fccea0 in ?? () from /usr/lib/libstdc++.so.6
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> I did compile ClamAV with -g, I even used -disable-opt for llvm-ld, but
> I still don't see line number error there (according to the docs I should).
>   

Hrm.  Yes.  This seems to be a missing feature.  I think I can add it 
relatively easily.

> $ ~/llvm2.6/obj32/projects/safecode/Release/bin/sc -rewrite-oob
> clamscan.bc -o clamscan_sc3.bc
> $ ~/llvm2.6/obj32/Release/bin/llc clamscan_sc3.bc -f
> $ gcc -o clamscan_sc3 clamscan_sc3.s
> ~/llvm2.6/obj32/projects/safecode/Release/lib/libsc_dbg_rt.a
> ~/llvm2.6/obj32/projects/safecode/Release/lib/libpoolalloc_bitmap.a
> -lstdc++ -lbz2 -pthread -lz ../libltdl/.libs/libltdlcS.o
>
> And I've built ClamAV like this:
> $ ./configure CC=llvm-gcc --disable-shared
> $ make CPPFLAGS="-O2 -g -emit-llvm" CFLAGS=
> CCLD="/home/edwin/llvm2.6/obj32/Release/bin/llvm-ld -disable-opt" -j8
>
>
> If I use addr2line on the IP printed by SAFEcode, I get this, but I
> don't see anything wrong there:
> foreach_dirinpath
> /home/edwin/clam/git/builds/sc/libltdl/../../../clamav-devel/libltdl/ltdl.c:717
>
> If I use the system's libltdl I get an invalid freee error here:
> optfree
> /home/edwin/clam/git/builds/sc/clamscan/../../../clamav-devel/shared/optparser.c:612
>
> Is there a way to disable these invalid free errors? They look like
> false positives to me (valgrind doesn't report them).
>   
Not currently.  SAFECode should not have false positives.  There is 
either a real error in ClamAV or a bug in SAFECode.
> I can send you clamscan.bc (it is 2.3M gzipped) if you want to.
>   
Let me first enhance the invalid free error reporting.  That may help 
you narrow down what SAFECode thinks the problem is and may help rule 
out the possibility of a real memory error in ClamAV.  After that, if 
SAFECode is still reporting an error, and you can't figure out why, I 
can add looking at the problem to my TODO list.

> P.S.: should I send "bugs" like this to you directly, or report them on
> LLVM bugzilla?
>   
I think it's actually best to file bug reports for each individual 
issue.  That way, we can track their progress, and they won't get lost 
in my email INBOX.

Thanks again for giving SAFECode a test drive.  I'll try to get the 
invalid free error reporting improved within the next day or two.  If 
you can let me know how to apply your patch (patch < patchfile isn't 
working for me), that'd be great too.

Thanks again!

-- John T.

> Best regards,
> --Edwin
>