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

[Markus Armbruster <armbru@redhat.com>]

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

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.

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.


[*] qom_modules[] in util/module.c.  This is a basically an (unchecked)
assertion that the (unrelated!) module code won't register anything
else.  Ugh!