[llvm-commits] Specification for Run-time Checks

[Santosh Nagarakatte]

John,

I read your proposal. I have described below the checks that would be
useful to SoftBoundCETS (http://www.cis.upenn.edu/acg/softbound/)

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

Additionally softboundcets would want to pass extra identifier
metadata with fastlscheck.
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.

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

Thanks,
Santosh


On Mon, May 14, 2012 at 2:15 PM, John Criswell <criswell at illinois.edu> wrote:
> Dear Santosh,
>
> For a GSoC project and for a discussion on llvm-commits about adding simple
> memory safety checks to Clang, I've written a first draft proposal for a
> common set of run-time checks and instrumentation for memory safety tools.
>  The goal is to provide a common infrastructure for adding and optimizing
> memory safety checks on LLVM IR code; the goal is to be able to have common
> optimizations that apply to tools like ASan, SoftBound, and SAFECode.
>
> If you'd be willing to review it, I'd like your feedback (positive or
> negative) on the proposal.  You can find the proposal at
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142532.html
> along with some feedback from Kostya (the primary ASan guy) from Google.
>
> If you do decide to comment on the proposal, would you be able to CC your
> comments to llvm-commits?  I'd like the discussion of the proposal to stay
> on llvm-commits so that others in the LLVM community see the input on the
> proposal and can know how much support it has among those of us building
> memory safety tools.
>
> -- John T.
>



-- 
Santosh G Nagarakatte,
PhD Student,
Computer and Information Science Department
University of Pennsylvania,
Philadelphia-19104
http://www.cis.upenn.edu/~santoshn