Alyssa Ross 7549149bb5 vmm: ensure signal handlers run on the right thread ... Despite setting up a dedicated thread for signal handling, we weren't making sure that the signals we were listening for there were actually dispatched to the right thread. While the signal-hook provides an iterator API, so we can know that we're only processing the signals coming out of the iterator on our signal handling thread, the actual signal handling code from signal-hook, which pushes the signals onto the iterator, can run on any thread. This can lead to seccomp violations when the signal-hook signal handler does something that isn't allowed on that thread by our seccomp policy. To reproduce, resize a terminal running cloud-hypervisor continuously for a few minutes. Eventually, the kernel will deliver a SIGWINCH to a thread with a restrictive seccomp policy, and a seccomp violation will trigger. As part of this change, it's also necessary to allow rt_sigreturn(2) on the signal handling thread, so signal handlers are actually allowed to run on it. The fact that this didn't seem to be needed before makes me think that signal handlers were almost _never_ actually running on the signal handling thread. Signed-off-by: Alyssa Ross <hi@alyssa.is>		2021-09-02 21:33:31 +01:00
..
bin	ch-remote: Add "add-user-device" subcommand	2021-08-12 13:19:04 +01:00
main.rs	vmm: ensure signal handlers run on the right thread	2021-09-02 21:33:31 +01:00