search for: capro

...execute potentially 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. Stati...

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

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

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