Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 9/16/12 7:23 AM, Martin Richtarsky wrote:
> On 15.09.2012 21:50, John Criswell wrote:
> > On 9/15/12 2:07 PM, Martin Richtarsky wrote:
> > > Hi,
> > >
> > > is it posible to use SAFECode with LLVM 3.1 or even trunk?
> >
> > We're currently in the process of updating SAFECode to LLVM mainline 
> > (i.e., trunk).  We're hoping to have something basic working by early 
> > next week.  After the update is done, we'll be tracking mainline 
> > until LLVM 3.2 is released.
>
> Hi John,
>
> that sounds great. Is it planned to make SAFECode a part of future 
> LLVM releases (after 3.2)?

Currently, no, but that is primarily because SAFECode users have not 
voiced a strong desire for SAFECode to be integrated into the main LLVM 
distribution.  I tried getting SAFECode integrated into LLVM about a 
year ago and was told that we needed to have a user base before we could 
get included.

So, if you're using SAFECode (especially if you're using SAFECode 
regularly) and want to see it included in LLVM, please email llvmdev and 
say so!  If we don't get support from users, SAFECode won't be included 
as a part of LLVM.

> Does SAFECode currently implement all of the techniques mentioned here?
> http://safecode.cs.illinois.edu/

The code for all of those techniques is implemented and available in the 
public SAFECode repository and release tarballs.  However, the automatic 
pool allocation and type-safe load/store check elimination optimizations 
are currently disabled because they are not sufficiently robust for 
everyday use, so SAFECode is not enforcing sounds points-to analysis or 
partial type safety at present. Bringing those two optimizations back 
online is on our TODO list.

Just as an FYI, we have an experimental but promising new implementation 
of the SAFECode run-time (written by Baozeng Ding, Alex Miller, and 
Arushi Aggarwal) and some new optimizations developed by Ott Tinn.  Both 
should hopefully improve the performance of SAFECode'ed executables.

Of course, we do accept patches, so if anyone wants to work on any of 
the missing optimizations, please email the svadev list and start hacking!

> What is the extent of the bounds checking? Are objects tracked with 
> their corresponding memory accesses?

Yes, exact object bounds are tracked, and all pointer arithmetic 
operations (i.e., LLVM GEP instructions) are checked at run-time if not 
proven safe statically.

> From the papers on the site it sounds like it (and this would beat the 
> generic redzone-type tracking done by valgrind or Address Sanitizer ).

Yes, SAFECode's exact bounds checking feature is a feature that is 
missing from tools like Valgrind and Address Sanitizer (ASan) (SAFECode 
also checks indirect function calls; I'm not sure if Valgrind or ASan 
check that).

ASan, I believe, has a feature that allows a user to configure the 
amount of space between allocated objects which increases the likelihood 
of catching larger buffer overflows, but even then, it's always possible 
for a pointer to "jump" from one memory object to another.  SAFECode 
doesn't permit such jumping but checks more operations at run-time as a 
consequence.

I think what would make sense is to have an option like the -O option 
that specifies the level of checking desired.  A default level might 
check only loads and stores while a higher level would check loads, 
stores, and GEPs.

-- John T.
> Best regards,
> Martin
>
>
> _______________________________________________
> svadev mailing list
> svadev AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/svadev