[LLVMdev] Clang + SAFECode Release Announcement

[John Criswell]

Dear All,

We have a new release of Clang with SAFECode technology for detecting
memory safety errors. Memory safety checking (SAFECode for short) can be
turned on with a single command line switch to clang/clang++. The
SAFECode techniques do not change the behavior of the clang/clang++
compilers in any way when the switch is turned off, so this can be used
as a drop-in replacement for clang/clang++.

Clang with SAFECode has the following advantages over tools such as
Valgrind:

o) It is faster since it does not use dynamic binary translation and can
optimize away some run-time checks.
o) It is more accurate since it knows the boundaries of individual stack
and global objects (Valgrind's ptrcheck tool needs to use heuristics to
find these boundaries).
o) It provides better error diagnostics that give more useful
information about each memory safety violation.

The current release primarily detects dereferences of pointers that are
generated from buffer overflows. There are many features from the LLVM
2.7 version of SAFECode that we are updating to work with LLVM mainline
and will be incorporating into our version of Clang soon. These
features include:

o) Detecting invalid memory accesses (e.g., dangling pointer dereferences)
o) Detecting invalid calls to free()
o) Detecting uses of uninitialized pointers
o) Detecting memory errors caused by misuse of C standard library functions
o) Several optimizations, including type-safe load/store check removal
and a loop hoisting optimization

Clang with SAFECode is available for download either in source form for
Linux and Mac OS X or as a pre-built Mac OS X binary at
http://sva.cs.illinois.edu/downloads.html. The source code is also
available directly from our SAFECode Subversion repository; download
directions are given on the web page above.

We're very interested in feedback (positive, negative, or otherwise).

Regards,

John Criswell

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Duncan Sands]

Hi John,

> We have a new release of Clang with SAFECode technology for detecting
> memory safety errors. Memory safety checking (SAFECode for short) can be
> turned on with a single command line switch to clang/clang++. The
> SAFECode techniques do not change the behavior of the clang/clang++
> compilers in any way when the switch is turned off, so this can be used
> as a drop-in replacement for clang/clang++.

sounds great! However, do you have to use clang (making it useless for
Fortran etc), or can it work on LLVM IR too?

Ciao, Duncan.

[John Criswell]

On 8/18/11 10:17 AM, Duncan Sands wrote:
> Hi John,
>
>> We have a new release of Clang with SAFECode technology for detecting
>> memory safety errors. Memory safety checking (SAFECode for short) can be
>> turned on with a single command line switch to clang/clang++. The
>> SAFECode techniques do not change the behavior of the clang/clang++
>> compilers in any way when the switch is turned off, so this can be used
>> as a drop-in replacement for clang/clang++.
> sounds great! However, do you have to use clang (making it useless for
> Fortran etc), or can it work on LLVM IR too?

All of the analysis and transforms work on LLVM IR and are, therefore,
language independent(*). We simply integrated the LLVM passes into
Clang so that they are easier to use.

-- John T.

(*) One caveat here is that we need to know the name of the functions
used for allocating and freeing memory. These tend to differ between
languages, but enhancing the code to recognize them is trivial.

[Kostya Serebryany]

On Thu, Aug 18, 2011 at 7:56 AM, John Criswell <cris...@illinois.edu> wrote:

Dear All,

We have a new release of Clang with SAFECode technology for detecting
memory safety errors. Memory safety checking (SAFECode for short) can be
turned on with a single command line switch to clang/clang++. The
SAFECode techniques do not change the behavior of the clang/clang++
compilers in any way when the switch is turned off, so this can be used
as a drop-in replacement for clang/clang++.

Clang with SAFECode has the following advantages over tools such as
Valgrind:

o) It is faster since it does not use dynamic binary translation and can
optimize away some run-time checks.

John, 

Do you have performance figures for SAFECode, e.g. on Spec CPU2006 or similar benchmarks?

Valgrind shows 20x on CPU2006, DrMemory shows 10x (http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf).

AddressSanitizer (which finds a different set of bugs compared to Valgrind/DrMemory, but very similar to SAFECode) has less than 2x overhead (http://code.google.com/p/address-sanitizer/wiki/PerformanceNumbers).

Thanks, 

--kcc 

[Chuck Zhao]

John,

The release source code (sc-main.tar) won't compile cleanly under
Debian6-i386 (gcc/g++: 4.4.5).
The compiler back trace is attached.
Please fix it/them and repost.

Or, 64b system is a requirement?

Thank you

Chuck

llvm[4]: Compiling TypeRuntime.cpp for Release+Asserts build (PIC)
cc1plus: warnings being treated as errors
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:52:
error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:99:
error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:110:
error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:
In function ‘uintptr_t maskAddress(void*)’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:102:
error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:
In function ‘void shadowInit()’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:110:
error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:
In function ‘void getTypeTag(void*, uint64_t, TypeTagTy*, uint32_t)’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:223:
error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:223:
error: comparison of unsigned expression < 0 is always false
make[4]: ***
[/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime/DynamicTypeChecks/Release+Asserts/TypeRuntime.o]
Error 1
make[4]: Leaving directory
`/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime/DynamicTypeChecks'

make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc'
make[1]: *** [all] Error 1
make[1]: Leaving directory
`/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects'
make: *** [all] Error 1
1836.706u 195.512s 9:33.06 354.6% 0+0k 304384+3596928io 1604pf+0w

[Will Dietz]

Hi,

My apologies for the trouble.

I've disabled building DynamicTypeChecks for now (r138224) and now it
builds cleanly on 32bit for me here.

As for SAFECode support for 32bit vs 64bit, I believe 32bit should
work just fine although I haven't personally tested this.

Let me know if you have any further issues/questions.

~Will

[John Criswell]

On 8/21/11 5:37 PM, Will Dietz wrote:
> Hi,
>
> My apologies for the trouble.
>
> I've disabled building DynamicTypeChecks for now (r138224) and now it
> builds cleanly on 32bit for me here.

Thanks, Will.

Just as an FYI to everyone, SAFECode does not depend upon everything
within the poolalloc project. The code that Will disabled is actually
from another project and is not (currently) used by SAFECode.

>
> As for SAFECode support for 32bit vs 64bit, I believe 32bit should
> work just fine although I haven't personally tested this.

SAFECode was originally built on 32-bit systems, so I think it should
still work. Chuck, if you find any more problems compiling or using
SAFECode on 32-bit systems, please let us know. We need to support both
32- and 64- bit systems.

Regarding the rebuilding of the source tarball, I'll go ahead and update
it since I'd like it to build on 32-bit systems. That said, in general,
I prefer people to update from SVN. Is that something that you can do?

-- John T.