[cfe-dev] Converting pointers to fat pointers

[Sai Charan]

LoadStoreChecks.cpp was a helpful pointer. For the record, in SafeBound
v1.2, lib/SoftBoundCETS/SafBoundCETS.cpp seems to the relevant portions.

Thank you.

Sai Charan,
CSE, UC Riverside.



On Mon, May 14, 2012 at 8:04 PM, John Criswell <criswell at illinois.edu>wrote:

>  On 5/14/12 9:57 PM, Sai Charan wrote:
>
> In the interest of time & effort, I am leaning on working at the LLVM IR
> level.
>
>  The code listing in section 3.1 of the SoftBound paper is precisely what
> I am looking to do. However, the listing is at the C source level, while
> section 6 says that the implementation has been done on the LLVM IR; I
> don't see how I can figure out pointer de-references in LLVM IR. Every
> alloca/load/store is via <ty>*.
>
>  In summary, how do I figure out pointer de-references in LLVM IR.
>
>
> Ignoring intrinsic functions, the only LLVM IR instructions that
> dereference pointers are load and store.
>
> The intrinsics that access memory via pointers should be pretty easy to
> spot when you read through the LLVM Language Reference Manual: things like
> the atomic intrinsics, the string manipulating intrinsics, etc.
>
> You can see what SAFECode does by looking at the LoadStoreChecks.cpp
> source code.  You can probably find the equivalent code in the SoftBound
> code, but I do not know myself where it is.
>
> -- John T.
>
>
>
>
> Sai Charan,
> CSE, UC Riverside.
>
>
>
> On Mon, May 14, 2012 at 7:23 PM, John Criswell <criswell at illinois.edu>wrote:
>
>>   On 5/14/12 8:11 PM, John McCall wrote:
>>
>>  On May 14, 2012, at 5:59 PM, Sai Charan wrote:
>>
>> I am looking at using LLVM/Clang to automatically convert pointer
>> declarations to fat pointers & the corresponding dereferences to something
>> appropriate. I am looking for guidance on doing this. Will an LLVM pass be
>> better suited to this or would this be better handled using Clang. Any
>> guidance on getting started would be helpful.
>>
>>
>>  It would be best handled by modifying Clang, both in semantic analysis
>> (to change the size of a pointer) and IR generation (to generate,
>> propagate, and consume your fat pointer values).  I'm afraid that clang's
>> IR generation widely assumes that pointers are represented as a single
>> llvm::Value, though, and you might be in for a lot of work.
>>
>>
>>  Converting to fat pointers can also be done at the LLVM IR level and,
>> in fact, there's a modern implementation of fat pointers at the LLVM IR
>> level in the SAFECode project (http://sva.cs.illinois.edu).  The
>> implementation is SoftBound from University of Pennsylvania, and it
>> implements what is essentially a fat pointer approach that does not modify
>> data structure layout.  You can read about SoftBound at
>> http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf.
>>
>> One of the problems with implementing fat pointers within clang is that
>> clang does not have the entire program, and so you cannot use whole program
>> analysis to determine if parts of the program are aware of the data
>> structure layout.  An LLVM IR analysis that is part of the link-time
>> optimization framework can, and so a transform at the LLVM IR level could
>> determine when it is safe to modify a data structure layout and when it is
>> not.
>>
>> All that said, if you're using a fat pointer method that doesn't modify
>> data structure layout (SoftBound has this feature; Xu et. al.'s work at
>> http://seclab.cs.sunysb.edu/seclab/pubs/fse04.pdf doesn't either, IIRC),
>> implementing it in Clang would also work.
>>
>> As an FYI, I'm advocating for a common infrastructure in LLVM for adding
>> and optimizing memory safety run-time checks; the idea is to have common
>> infrastructure that will work both for fat pointer approaches, object
>> metadata approaches, and other approaches.  You can find my proposal at
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142532.html.
>> I'd welcome any feedback or comments you may have on it.
>>
>> -- John T.
>>
>>
>>  John.
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing listcfe-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120515/3e1b3d56/attachment.html>