similar to: [LLVMdev] Secure Virtual Machine

Let me cut it down to the core problem: I'm asking about the feasibility of extending LLVM with constructs to manage separate heaps. Given my current understanding of LLVM, I can see this done in two ways: 1. Add heap management instructions to the core instructions, modify allocation routines to explicitly name heaps or modify the runtime to rebind the allocation routines depending on some

Sandro Magi wrote: > Let me cut it down to the core problem: I'm asking about the > feasibility of extending LLVM with constructs to manage separate > heaps. Given my current understanding of LLVM, I can see this done in > two ways: > If you just need to partition the heap into multiple heaps, then the easiest thing to do would be to replace the use of malloc/free

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.

On 6/5/07, John Criswell <criswell at cs.uiuc.edu> wrote: > > 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

On 6/6/07, Sandro Magi <naasking at gmail.com> wrote: > On 6/5/07, John Criswell <criswell at cs.uiuc.edu> wrote: > > > > 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 > >

Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a

To this end, are there any implicit allocations being done by generated LLVM code, other than the system stack? Sandro On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: > Given my recent posts, I think it's obvious that I'm trying to figure > out how to build a resource-aware VM for a high-level language. > > I've figured out adequate solutions for most of the

On Wed, 20 Jun 2007, Sandro Magi wrote: > To this end, are there any implicit allocations being done by > generated LLVM code, other than the system stack? heap allocations? Only malloc/free. Note that the compiler does generate calls to runtime libraries (e.g. libstdc++ and libgcc), we don't have control over when they do allocations. The libstdc++ calls show up in the .ll file,

On Sun, 8 Jul 2007, Sandro Magi wrote: > How about if I were to use LLVM's JIT? I suspect plenty of allocations > are performed in the JIT. The JIT does a ton of heap allocation. There is no way to approximate it from the code you give it. -Chris > Sandro > > On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: >> On Wed, 20 Jun 2007, Sandro Magi wrote:

Where does the storage for large bit width integers come from? Are very large numbers heap allocated? Sandro

How about if I were to use LLVM's JIT? I suspect plenty of allocations are performed in the JIT. Sandro On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Jun 2007, Sandro Magi wrote: > > To this end, are there any implicit allocations being done by > > generated LLVM code, other than the system stack? > > heap allocations? Only malloc/free. Note

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? 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

Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >

On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: > On Sun, 8 Jul 2007, Sandro Magi wrote: > > How about if I were to use LLVM's JIT? I suspect plenty of allocations > > are performed in the JIT. > > The JIT does a ton of heap allocation. There is no way to approximate it > from the code you give it. I don't need to approximate it, but I'd like to

Sandro Magi wrote: >Where does the storage for large bit width integers come from? Are >very large numbers heap allocated? > > The ConstantInt class stores integer values. Large or not they are stored using an APInt object. APInt (lib/Support/APInt.cpp) uses an array of uint64_t if more than two are needed or an inline uint64_t in the APInt object. So, yes, they are heap

On Tue, 10 Jul 2007, Sandro Magi wrote: > On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: >> On Sun, 8 Jul 2007, Sandro Magi wrote: >>> How about if I were to use LLVM's JIT? I suspect plenty of allocations >>> are performed in the JIT. >> The JIT does a ton of heap allocation. There is no way to approximate it >> from the code you give it.

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

On Mon, 18 Jun 2007, Sandro Magi wrote: > Ok, so if I needed very precise control over the allocation of memory, > then I should avoid using integers with bit widths larger than 64 bits > (or perhaps 128)? Is there a hard rule for an integer being stack > allocated, ie. one that doesn't depend on the current implementation > details? In the generated code, or in the compiler

On 2/27/06, Chris Lattner <sabre at nondot.org> wrote: > > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > > > I haven't seen an adequate explanation of these, but I'm guessing: > > void *V: value being written to the field > > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > > upon entry to llvm_gc_write)

On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote: > You at least increase the memory footprint by doubling the stack sizes. Not quite. The space overhead is constant for each stack frame - you just need to keep track of the top of two stacks, rather than one. The important overhead is that you reduce locality of reference. You will need a minimum of two cache