> If we intend seccomp to protect against flaws during QEMU setup, then having > it earlier is neccessary. eg QEMU opening a corrupt qcow2 image which might > exploit QEMU before the guest CPUs start.
> If the latter is the case, then we could start with a relaxed seccomp > sandbox which included the setuid/chroot features, and then switch to a > more restricted one which blocked them before main_loop() runs. That's not possible. Seccomp will not be enforced until seccomp_load(ctx) is called, after which no new changes to the filter can be made.
