-
Nadav Har'El authored
Call the new poweroff() function after the payload finishes running. Makes sense on a cloud (why would you want to pay the provider after your workload is done?) as well as for our benchmarking, where we want qemu to exit after running the benchmark. When the "--leak" option is used, instead of calling poweroff(), we call hang(), so that QEMU continues to run and we can attach the debugger to run "osv leak show". Note that before this patch, if the payload spawned threads, they could continue running after the payload's main() return. This is no longer the case - after main() returns, the entire virtual machine is shut down (or just hung). This is reasonable behavior, though: If the payload needs some threads to continue running, it should join() them before returning. The behavior on Linux (and Posix threads in general) is identical to our new behavior: When main() of a multithreaded program returns, all threads are killed.
Nadav Har'El authoredCall the new poweroff() function after the payload finishes running. Makes sense on a cloud (why would you want to pay the provider after your workload is done?) as well as for our benchmarking, where we want qemu to exit after running the benchmark. When the "--leak" option is used, instead of calling poweroff(), we call hang(), so that QEMU continues to run and we can attach the debugger to run "osv leak show". Note that before this patch, if the payload spawned threads, they could continue running after the payload's main() return. This is no longer the case - after main() returns, the entire virtual machine is shut down (or just hung). This is reasonable behavior, though: If the payload needs some threads to continue running, it should join() them before returning. The behavior on Linux (and Posix threads in general) is identical to our new behavior: When main() of a multithreaded program returns, all threads are killed.