[LLVMdev] Secure Virtual Machine

[John Criswell]

Sandro Magi wrote:
> SVA looks very promising. It would be great to be able to run
> unmodified C safely!
>
> However, it does not seem to address my original question: how can I
> ensure that code  cannot DoS either the memory subsystem, or the CPU?
>   
To be honest, while I understand your questions, I do not understand the
context in which you are asking them. Are you asking if LLVM provides
any facilities to provide these protections, or are you asking if we've
added any special features to LLVM (or to SVA; our research work based
on LLVM) to provide these protections beyond what is commonly provided
by systems today? Can you provide more information on how you want to
use LLVM for your project?

To answer the first question, yes, there are simple ways in which LLVM
can provide these protections. Programs compiled to LLVM bytecode are
either translated to native code ahead of time or run with a JIT. Either
way, each program is run within a separate process which has its own set
of operating system imposed memory limits and CPU time limits. Code can
execute the fork() and clone() system calls to create new threads and
processes (I'm not sure if our JIT can handle multi-threaded code, but
in theory, it could). You could, in fact, write an LLVM transformation
pass that inserts calls to fork()/clone()/pthread_create()/etc. to
create new processes/threads as needed to enforce your policies. In
short, a program compiled to LLVM bytecode gets whatever protections the
OS itself provides against such attacks, and I believe these guarantees
extend to the JIT as well as to the code running within the JIT.

To answer the second question, no, we have not done any research into
how to provide more fine grained protections against these attacks in
our Secure Virtual Architecture (which is based on LLVM). In particular,
there is nothing that ensures that there are any protections against
these sort of attacks on kernel level code compiled for SVA, and we have
not done any work to ensure that our JIT, if run below the OS, would be
immune to such attacks.

However, I suspect that adding such features would be an interesting
research question. I would think that static program analysis could be
used to determine code follows a particular memory allocation/CPU usage
policy. I think it would also be possible to use automatic program
transformation to modify code to have run-time checks to ensure that
such policies were followed. However, I'm not familiar with the work in
this area, so I don't know what has been done or what challenges one
would need to overcome.

-- John T.
> In my proposal, I could execute said code in a concurrent process with
> a memory quota. How would SVA address that problem?
>
> Sandro
>
> On 6/2/07, Vikram S. Adve <vadve at uiuc.edu> wrote:
>   
>> We have a research project that is developing a Secure Virtual
>> Architecture using LLVM as the instruction set, and implementing via
>> a VM which we call a Secure Virtual Machine.  The memory safety
>> foundations of this work are based on Dinakar Dhurjati's thesis and
>> publications:
>> 	http://llvm.org/pubs/
>>
>> SVA is at a very preliminary stage but some slides about it are
>> attached.
>>
>>     
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>