+-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+ | > Failing to start (with a message that explains why) if one of the command | > line options is not covered by a specified security policy is not | > unreasonable (after all, we fail to start for other cases of incompatible | > command line options as well.)
Yes, that's right. | > However, we also need to cover dynamically-added devices. Aborting seems | > very bad there, just failing to add the device seems like what we'd want. | | Yep, aborting is simply not an option for the inner code. It all has to | propagate to a proper Error **errp object. The ultimate entry-point at the | CLI vs QMP then decides whether to turn the error into an abort or feed back | to the client app. True, handling dynamic devices is tricky. Though it seems kind of uniform workflow to check for '--security' flag at options parsing OR while handling dynamic devices at run time; It is a huge task to cover all options/use-cases for all QEMU emulators across various architectures. * If this approach is reasonable, I'll try to make an initial patch towards it. * We'd still need to figure out similar way for compile time option, to exclude building insecure features at build time. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
