got this from implementation of the Go language runtime: set rsp to the top of a "heap allocated stack" of size 0x10000 bytes function prologue compliant with Windows x86_64 calling conventions PEXCEPTION_RECORD, ULONG64, PCONTEXT, PVOID)ĪddVectoredExceptionHandler(1, GlobalExceptionHandler) Ĭode.asm EXTERN FrameExceptionHandler:PROC in real world it would just terminate the sandboxĮxtern "C" EXCEPTION_DISPOSITION _stdcall FrameExceptionHandler( of course this is just a stub to simplify the issue should be called afterwards on error and terminate the process LONG _stdcall GlobalExceptionHandler(_EXCEPTION_POINTERS*) should be called first on error and continue exception handling WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), just a low level helper to print "msg" The following is a working code snippet cut down to the core issues: So I thought I'll use the fantastic knowledge of Stack Overflow to get some opinions :-) I have checked the language implementations of Go and Factor which do similar things and with this help got something running.īut there are still some open questions and uncertainties. The sandbox is a separate process and simply gets killed in case of an error.)įurthermore, the sandboxed code should not use the host applications stack but run on some separate "stack" which is allocated by myself.Įxactly this combination (exception handling in presence of a custom allocated stack) is twisting my mind. So, one crucial step is to get Windows' structured exception handling right in order to catch errors (like invalid memory access or div by 0) and gracefully terminate the sandbox before Windows kills my host application. Unlike with NaCl, the untrusted code will not run in a separate process but the same process as the host application. I am currently investigating how to implement a sandbox (similar to Google's NaCl project ) where I can run untrusted x86 code (restricted instruction set) in such a way that it cannot harm the rest of my process.
0 kommentar(er)
