[llvm-commits] Specification for Run-time Checks

[John Criswell]

On 5/16/12 12:41 AM, Santosh Nagarakatte wrote:
> John,
>
> I read your proposal. I have described below the checks that would be
> useful to SoftBoundCETS (http://www.cis.upenn.edu/acg/softbound/)

Thank you for reviewing my proposal.

>
> 1) fastlscheck is good-- SoftBoundCETS passes everything in registers
> all the time. So a lscheck which pass things using memory is not
> useful.

I can see how the fastlscheck is useful since it can reduce the 
instrumentation that SoftBound needs to add.  Additionally, the 
pool_register optimizations may be indirectly useful.  If an 
optimization removes a pool_register call for an object, then all of the 
checks on that object can find the bounds of that object without any 
further instrumentation.  SoftBound may be able to take advantage of that.

I would also argue that lscheck is useful.  The lscheck essentially 
tells a tool where a load/store check must be performed.  Optimizations 
can remove them or hoist them out of loops.  Once that is done, 
SoftBound can add the instrumentation to propagate bounds information 
and then replace the lscheck with the code that checks to see if the 
pointer is within bounds.

Do you think these ideas will work, or are there problems with them 
(e.g., would doing things this way make SoftBound more complicated?)?
> 2) funccheck
> 3) freecheck
>
> Additionally softboundcets would want to pass extra identifier
> metadata with fastlscheck.

Is this for the CETS instrumentation?  Can a SoftBound-specific pass 
easily enhance the fastlscheck with the needed information?


> With the current interface, we can pass it using a shadow stack
> interface, however it introduces additional extra loads/stores with
> each check.
>
> If we can come up with a generic interface where
> softbound/safecode/asan can use different amounts of metadata for each
> check, it would be extremely useful.

I assume you mean that we need some way of adding additional parameters 
to each check for each tool.  My proposal calls for each tool to add 
those parameters to the checks after the tool-independent optimizations 
optimize the checks.  For example, SAFECode would use an additional pass 
to add pool handles to lscheck and gepcheck.

>
> Softboundcets would also benefit from a common check elimination framework.
>
> I personally think check inlining is extremely important. For example,
> SoftBoundCETS in the SafeCode trunk incurs 2.5-3x overhead over Spec
> 2k6/Spec 2k/Spec95.  On the other hand our inlined version of the
> checks (with separate compilation) incurs only 1.9-2x overhead.
> Relying primarily on the presence of libLTO is not helpful

I agree that relying on libLTO is problematic because:

1) Not all Linux systems ship with the gold linker; and
2) Clang doesn't seem to want to use anything other than the system 
linker; and
3) Because of 1 and 2, installing libLTO is a pain (and seems to require 
root access)

Another alternative is to have a pass insert the run-time check code 
into the program and inline it.  I wrote a small pass yesterday that 
inlines fastlscheck; if it looks like a performance win, we'll expand it 
to handle gepcheck in the future.  Inlining generic gepcheck and lscheck 
calls should probably be done tool-specific transforms since their 
implementation will differ widely between tools.

-- John T.