On Wed, May 19, 2021 at 03:14:54PM +0200, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > > > Right now the SPICE module is special cased to be loaded when processing > > of the -spice command line option. However, the spice option group > > can also be brought in via -readconfig, in which case the module is > > not loaded. > > > > Add a generic hook to load modules that provide a QemuOpts group, > > and use it for the "spice" and "iscsi" groups. > > > > Fixes: #194 > > Fixes: https://bugs.launchpad.net/qemu/+bug/1910696 > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > > What follows is not an objection to this patch. > > I think we have this kind of bugs because we're kind of wobbly on when > to load modules. > > On the one hand, we're trying to load modules only when needed. This is > obviously useful to conserve resources, and to keep the attack surface > small. Some background in > > Message-ID: <20210409064642.ah2tz5vjz2ngf...@sirius.home.kraxel.org> > https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01393.html
I'm not convinced by the runtime attack surface argument, because even if QEMU doesn't auto-load, if the attacker has gained enough control over QEMU that they can jump into code that is not otherwise enabled by QEMU config, then they can likely scribble into RAM in a way that triggers dlopen() of any .so on the filesystem, whether a QEMU module or not. IMHO the main benefit of modules is that you can avoid installing everything on disk, and thus avoid pulling in a long chain of deps, and thus get smaller containers, and avoid having to worry about software updates for CVEs in things you're not using. > On the other hand, we're trying to make modules transparent to > management applications, i.e. QEMU looks the same whether something was > compiled as a loadable module or linked into QEMU itself. See > > Message-ID: <yhahqwdx15v54...@redhat.com> > https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01450.html > > I'm afraid we sort of fail at both. > > Transparency to management applications requires us to load modules on > QOM introspection already. Yes, and bugs in the latter have already caused mis-behavior in libvirt. > Example: to answer "show me all QOM types", we need to load all modules > that could possibly register QOM types. As long as module code can do > whatever it wants, that means loading all of them. > > Example: to answer "show me QOM type FOO", where FOO is currently > unknown, we need to load all modules that could possible register QOM > type FOO. Again, that means loading all of them. > > We don't actually do this. Instead, we hardcode a map from type name to > module name[*], so we don't have to load them all, and we actually load > the module specified by this map only sometimes, namely when we call > module_object_class_by_name() instead of object_class_by_name(). I > can't discern rules when to call which one. Wobbly. > > Things other than QOM might be affected, too. > > QAPI introspection is not: the value of query-qmp-schema is fixed at > compile-time, and *how* something is compiled (loadable module > vs. linked into QEMU itself) does not affect it. > > I'd like us to develop a clearer understanding when exactly modules are > to be loaded. Agreed, we need much better defined behaviour here. 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 :|
