[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic module loading (was: [PATCH] qemu-config: load modules whe
From: |
Daniel P . Berrangé |
Subject: |
Re: Automatic module loading (was: [PATCH] qemu-config: load modules when instantiating option groups) |
Date: |
Wed, 19 May 2021 15:49:05 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
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 :|