<span style="font-family: Arial; font-size: 13px;">I'm interested in making vbox more secure for sandboxing untrusted<br>compute-bound code.  I want to make it something like linux's seccomp,<br>so that the guest OS sends a signal to the VMM, probably by a specially<br>crafted vmexit event, indicating that any subsequent vmexit results in<br>the guest being shut down unless<br><br>  1) it's one of the "innocuous" vmexits which results in jumps to the<br>     ResumeExecution label in the *R0RunGuestCode functions in<br>     src/VBox/VMM/VMMR0/HW*R0.cpp,<br>  <br>  2) it's an event which can result from pure computation of the type<br>     "seccomp" is intended to allow (i.e., no attempt to access system<br>     resources) (I could use some help defining this whitelist.)<br><br>  3) it results from exercising any communication channels that the<br>     guest OS had estabilshed prior to sending the vmexit event.<br><br>The next step for me would be to learn to use the vbox logging/debugging<br>facilities to flesh out a whitelist covering scenarios (2) and (3).  If<br>I can do that, I will put a new branch at the top of the huge switches<br>on exitReason in the *R0RunGuestCode functions, testing for the special<br>vmexit event.  That branch will set a "seccomp" flag which will turn on<br>the whitelist of vmexit events allowing scenarios (2) and (3).  It will<br>probably also turn off pVM->hwaccm.s.fTRPPatchingAllowed as well.  Just<br>prior to the exitReason switch will be the whitelist code, which will<br>execute if the "seccomp" flag is set, and will kill the guest if the<br>vmexit event isn't on the whitelist.<br><br>This plan is based on studying the vbox source code for a bit less than<br>a day, and may well be wrongheaded.  If you can shoot it down or point<br>out any likely pitfalls (especially security flaws), you'll be doing me<br>a big favor. :-)<br><br>Jason<br><br><br></span>