On Thu, Jul 16, 2020 at 08:55:43AM +0200, Cornelia Huck wrote: > On Tue, 14 Jul 2020 18:40:11 +0530 (IST) > P J P <ppan...@redhat.com> wrote: > > <just commenting on this one> > > > * QEMU would abort(3), if a user attempts to start QEMU with insecure > > options > > like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ? > > > > * One way could be to abort(3) at options parsing stage, if 'security' > > flag > > is set to high(1) and continue further if it is low(0). > > 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.) 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
