Ok, thank you for your explanation. Is it possible for forked processes to share data? Especially for the child process to send some data to the parent? -Frank 2010/7/18 Nick Lewycky <nicholas at mxc.ca>> Frank Fuchs wrote: > >> Hi, >> >> I'm doing some tests concerning the embedding of LLVM and clan in my >> application. >> Now I stumbled across the following ... which disturbs me. If the jitted >> program crashes, >> like e.g. if it contains an assert(0==1) or calls an external function >> which cannot be resolved, >> the hosting app goes down as well. There seems no error catch. >> >> Can this anyhow be circumvented? >> > > Fork? > > LLVM JIT is not a secure VM like Java. Programs running under the JIT are > free to make any memory operation or function call that the enclosing > program could, even _exit(). You can try to restrict function calls by > removing the name resolution: > > > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 > > and/or installing your own (see InstallLazyFunctionCreator), but ultimately > they're the same process/task from the point of view of the operating system > and there's no "llvm security model" or anything like that. > > If you're very determined, you could create an LLVM IR transformation pass > which checks every load/store/call and verifies that it's safe, and if it's > not verifiable at compile time makes it call back into your program at > runtime to do the check and proceed only if it is. > > Or if you don't need it to be in the same process, don't put it there and > let the OS handle the rest. > > Nick >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/a1ead956/attachment.html>
You could use shared memory or the equivalent of UNIX domain sockets. On a UNIX system, you will also probably want to catch SIGCHLD along with implementing "nowait" handling behavior in the parent. This is of course a low level approach. Higher level libraries that you may be using, or other OSs may provide their own wrappers. Garrison On Jul 19, 2010, at 4:05, Frank Fuchs wrote:> Ok, thank you for your explanation. Is it possible for forked processes to share data? Especially for the child process to send some data to the parent? > > -Frank > > 2010/7/18 Nick Lewycky <nicholas at mxc.ca> > Frank Fuchs wrote: > Hi, > > I'm doing some tests concerning the embedding of LLVM and clan in my application. > Now I stumbled across the following ... which disturbs me. If the jitted program crashes, > like e.g. if it contains an assert(0==1) or calls an external function which cannot be resolved, > the hosting app goes down as well. There seems no error catch. > > Can this anyhow be circumvented? > > Fork? > > LLVM JIT is not a secure VM like Java. Programs running under the JIT are free to make any memory operation or function call that the enclosing program could, even _exit(). You can try to restrict function calls by removing the name resolution: > > > http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 > > and/or installing your own (see InstallLazyFunctionCreator), but ultimately they're the same process/task from the point of view of the operating system and there's no "llvm security model" or anything like that. > > If you're very determined, you could create an LLVM IR transformation pass which checks every load/store/call and verifies that it's safe, and if it's not verifiable at compile time makes it call back into your program at runtime to do the check and proceed only if it is. > > Or if you don't need it to be in the same process, don't put it there and let the OS handle the rest. > > Nick > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/440bae8f/attachment.html>
Is there a way to intercept the calls to abort() or exit(), specifically ? Disabling all external symbol resolution seems not really feasable since I need some std libs. -Frank 2010/7/19 Garrison Venn <gvenn.cfe.dev at gmail.com>> You could use shared memory or the equivalent of UNIX domain sockets. On a > UNIX system, you will also probably want to catch > SIGCHLD along with implementing "nowait" handling behavior in the parent. > This is of course a low level approach. Higher level > libraries that you may be using, or other OSs may provide their own > wrappers. > > Garrison > > On Jul 19, 2010, at 4:05, Frank Fuchs wrote: > > Ok, thank you for your explanation. Is it possible for forked processes to > share data? Especially for the child process to send some data to the > parent? > > -Frank > > 2010/7/18 Nick Lewycky <nicholas at mxc.ca> > >> Frank Fuchs wrote: >> >>> Hi, >>> >>> I'm doing some tests concerning the embedding of LLVM and clan in my >>> application. >>> Now I stumbled across the following ... which disturbs me. If the jitted >>> program crashes, >>> like e.g. if it contains an assert(0==1) or calls an external function >>> which cannot be resolved, >>> the hosting app goes down as well. There seems no error catch. >>> >>> Can this anyhow be circumvented? >>> >> >> Fork? >> >> LLVM JIT is not a secure VM like Java. Programs running under the JIT are >> free to make any memory operation or function call that the enclosing >> program could, even _exit(). You can try to restrict function calls by >> removing the name resolution: >> >> >> >> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460 >> >> and/or installing your own (see InstallLazyFunctionCreator), but >> ultimately they're the same process/task from the point of view of the >> operating system and there's no "llvm security model" or anything like that. >> >> If you're very determined, you could create an LLVM IR transformation pass >> which checks every load/store/call and verifies that it's safe, and if it's >> not verifiable at compile time makes it call back into your program at >> runtime to do the check and proceed only if it is. >> >> Or if you don't need it to be in the same process, don't put it there and >> let the OS handle the rest. >> >> Nick >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/2b3ee1e1/attachment.html>