[LLVMdev] Memory protection using run-time checks

Roman Levenstein romixlev at yahoo.com
Wed Dec 20 06:10:17 PST 2006


Hi,

I'm thinking about introducing some sort of memory protection into the
LLVM backend for my embedded target. The overall goal is to make some
regions of memory non-readable and/or non-writable. The bounds of these
memory regions are sometimes fixed and known in advance and in some
other cases can be dynamic (e.g. for heap or stack).

Since my target does not have an MMU and any sort of hardware based
memory protection, these checks should be implemented in software.

I see the following possibilities to achieve that:
1) Simply check every pointer before any indrect memory access. This is
very easy to implement, but is rather inefficient, because it has a
very big run-time overhead and bloats the generated code. This is how
it is done in our old compiler.

2) Use more advanced analysis and eliminate most of the checks if it
can be proved that a given pointer always has a "good" value at this
point.  

Since the idea of (2) is not so new, I guess that some work was already
done in LLVM in this direction. For example, I have found the following
papers:

 @InProceedings{DKAL:LCTES03,
    Author    = {Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and
Chris Lattner},
    Title     = "{Memory Safety Without Runtime Checks or Garbage
Collection}",
    Booktitle = "{Proc. Languages Compilers and Tools for Embedded
Systems 2003}",
    Address   = {San Diego, CA},
    Month     = {June},
    Year      = {2003},
    URL       =
{http://llvm.cs.uiuc.edu/pubs/2003-05-05-LCTES03-CodeSafety.html}
  }

and 

"Segment Protection for Embedded Systems Using Run-time Checks"
By Matthew Simpson, Bhuvan Middha and Rajeev Barua.
Proceedings of the ACM International Conference on Compilers,
Architecture, and Synthesis for Embedded Systems (CASES),
San Francisco, CA, September 25-27, 2005

If I understand correctly, they are related to DSA analysis.

So, I'd like to ask about the status and availability of such kinds of
analysis in LLVM. What are the analysis passes to look at? What are the
issues with them? What is a current status? Are there any problems
(e.g. patent issues like with DSA) that prevent from using them? 

Any feedback about this issues is very appriciated.

-Roman




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the llvm-dev mailing list