Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 7/11/11 12:13 PM, Adve, Vikram Sadanand wrote:
> It's not just for greatest safety: I think Option 2 is the *right* way to do 
> it and the other two are not -- they're just hacks to turn off the spurious 
> error.

It's somewhat of a moot point since we both think option 2 is what we 
should do, but I'm going to argue with you anyway so that others on the 
list can get a better understanding of when we relax our memory safety 
guarantees.

I would argue that all the options are "correct."  By correct, I mean 
that they maintain the memory safety guarantees as described in our SOSP 
2007 paper.  The only difference is whether these functions are treated 
as internal or external code.

Options 1 and 3 treat the call as a call to an external, unanalyzed 
function.  For such a function, we relax the safety guarantees because 
we don't understand what the code is doing.

Option 2 treats the call as internal code (which we can do since the 
semantics of C library functions is well defined).  Since it's internal 
code, the safety guarantees are more strict.

The problem right now is kind of like having half of SAFECode treat the 
C library time functions as internal code while the other half treats it 
as external code.  If we go all internal or all external, we're 
correct.  Treating the code as internal provides more stringent memory 
safety.

> How useful will exactcheck be?  I'm not sure it will provide much benefit 
> since these stdlib calls are likely to be called relatively infrequently in 
> terms of time between calls.

Without exactcheck, each gep that indexes into the returned structure 
and each load/store from/to it will induce an object lookup.  With 
exactcheck, the lookup is avoided, and since the geps probably have 
constant indices and the object size is known at compile-time, the 
exactcheck itself may be optimized away if it is inlined.  Furthermore, 
the registration of the memory object could be removed too if all checks 
requiring lookups are eliminated.

That said, you may be right; the objects may be accessed infrequently 
enough that the performance gain won't matter, but if it's easy enough 
to do, we should just do it.

-- John T.

> --Vikram
>
>
> On Jul 11, 2011, at 11:40 AM, John Criswell wrote:
>
> > On 7/11/11 11:23 AM, Matthew Wala wrote:
> > > On Mon, Jul 11, 2011 at 11:10 AM, John 
> > > Criswell<criswell AT illinois.edu>
> > >    wrote:
> > > > On 7/11/11 11:06 AM, Matthew Wala wrote:
> > > >
> > > > Hello everyone:
> > > > When I compile the attached test case with SAFECode (tried on asha and
> > > > bach) I get a large number of Out of Bounds / Load Store errors. The
> > > > test calls gmtime() which returns static memory. These errors also
> > > > occur if the function that is called is replaced with localtime().
> > > >
> > > > Check to see if gmtime() and localtime() are recognized by DSA's StdLib
> > > > pass.  If so, then what is probably happening is that they are being marked
> > > > complete, but since the memory objects aren't registered, you get an error.
> > > I did check, and there are entries for those functions in StdLibPass.
> > > There's also entries for ctime() and asctime(). It looks like all four
> > > of those functions have the same flags in the StdLibPass table, but
> > > despite that the error still occurs. Perhaps the flags are wrong.
> > So, you have a couple of options for how to fix this:
> >
> > 1) Modify the StdLibPass to mark the DSNode of the static memory with
> > the External flag.
> > 2) Modify SAFECode to register the memory returned by these functions
> > into a pool.
> > 3) Modify SAFECode's CompleteChecks pass to not make these memory
> > objects complete.
> >
> > Option 2 is probably the best as it will provide the greatest safety.
> >
> > It may also be worth enhancing the exactcheck optimization pass to treat
> > these functions like allocators.  I'd be willing to bet that many of
> > these memory objects are only accessed within the function in which they
> > are called and would benefit from the exactcheck optimization.
> >
> > -- John T.
> >
> > > I tested ctime() once more, and it looks that reading the output from
> > > ctime() actually does cause a Load / Store error.
> > > (The reason my previous testing didn't recognize this is that I did a
> > > simple printf("%s\n", ctime(...)); call, and it looks like the C
> > > frontend lowers such calls to puts(), which SAFECode doesn't currently
> > > handle (I think I should probably add support for puts() in the
> > > CStdLib pass for this reason). So the read of the value of ctime() was
> > > being done in external code, which is why it didn't raise any errors.)
> > >
> > > Matt
> > >
> > > > If other functions aren't recognized by DSA's StdLib pass, then the pointer
> > > > is being marked External, which means that SAFECode won't raise an error if
> > > > the memory object isn't found in the pool.
> > > >
> > > > -- John T.
> > > >
> > > > However, other time-related functions that return static memory like
> > > > ctime() (as well as the reentrant versions of gmtime() and
> > > > localtime()) do not cause SAFECode to complain.
> > > > Before filing a bug I'd like to know if there is a reason for this
> > > > behavior or if this is already known.
> > > >
> > > > Thanks,
> > > > Matt
> > > >
> > > >
> > > > _______________________________________________
> > > > svadev mailing list
> > > > svadev AT cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/svadev
> > _______________________________________________
> > svadev mailing list
> > svadev AT cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/svadev