Re: Automatic module loading (was: [PATCH] qemu-config: load modules when instantiating option groups)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, May 19, 2021 at 03:14:54PM +0200, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@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 <pbonzini@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.ah2tz5vjz2ngfiyo@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: <YHAhQWdX15V54U8G@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 :|