search for: coyotos

...lly malicious code safely, no existing VM is sufficiently safe, since the malicious code can still DoS the CPU and the memory subsystems. This is because all VMs of which I'm aware provide insufficient resource accounting; the only efforts to minimize these DoS opportunities are CapROS/EROS and Coyotos secure operating systems (that I'm aware). Secure mobile code will remain a pipe dream until such isolation is addressed. So I was proposing an extension to LLVM to address the problem, and asking about the feasibility of the extension as detailed in the above message. Static analyses are cer...

...afely, no existing VM is sufficiently safe, since the > malicious code can still DoS the CPU and the memory subsystems. This > is because all VMs of which I'm aware provide insufficient resource > accounting; the only efforts to minimize these DoS opportunities are > CapROS/EROS and Coyotos secure operating systems (that I'm aware). > Secure mobile code will remain a pipe dream until such isolation is > addressed. Personally, I wonder it may be a little bit too early for LLVM to meet these fine-grained confinement problems before the SVA gets mature. Real world virtual mach...

...other ways, but I believe it currently lacks even the base constructs necessary to even build a secure VM on top of it. [4] I can explain space banks and keepers concepts further, but just think of them as stateful exception handlers specific to a process. The concepts come from the KeyKOS/EROS and Coyotos secure operating systems.

On Apr 17, 2008, at 13:00, Jonathan S. Shapiro wrote: > On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > >> On Thu, 17 Apr 2008, guan mailist wrote: >> >>> Does anyone have good ideas to dynamically measure the stack size >>> of a >>> program by using LLVM. I am trying to add some new intrinsic >>> functions after each

...t; > > The GC infrastructure exposes this information in a framework suitable > > for emitting metadata tables from a compiler plugin, if your interest > > lies in that direction. > > That too, but my immediate interest was computing an upper bound on > stack size for the Coyotos kernel. Does 'llvm.frameaddress' work for this purpose? Have you tried it? It seems 'llvm.frameaddress' is not very precise. Is it possible to compute the upper bound of stack size in bits? Many thanks, GUan -------------- next part -------------- An HTML attachment was scru...

...it > currently lacks even the base constructs necessary to even build a > secure VM on top of it. > [4] I can explain space banks and keepers concepts further, but just > think of them as stateful exception handlers specific to a process. > The concepts come from the KeyKOS/EROS and Coyotos secure operating > systems. >

On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > On Thu, 17 Apr 2008, guan mailist wrote: > > Does anyone have good ideas to dynamically measure the stack size of a > > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do

...it > currently lacks even the base constructs necessary to even build a > secure VM on top of it. > [4] I can explain space banks and keepers concepts further, but just > think of them as stateful exception handlers specific to a process. > The concepts come from the KeyKOS/EROS and Coyotos secure operating > systems. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

...ly lacks even the base constructs necessary to even build a >> secure VM on top of it. >> [4] I can explain space banks and keepers concepts further, but just >> think of them as stateful exception handlers specific to a process. >> The concepts come from the KeyKOS/EROS and Coyotos secure operating >> systems. >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

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