Message ID | 20210624103836.2382472-1-kraxel@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | modules: add meta-data database | expand |
Hello Gerd, Reviewed and tested successfully here. Thank you! Reviewed-by: Jose R. Ziviani <jziviani@suse.de> On Thu, Jun 24, 2021 at 12:38:02PM +0200, Gerd Hoffmann wrote: > This patch series adds support for module meta-data. Today this is > either hard-coded in qemu (see qemu_load_module_for_opts) or handled > with manually maintained lists in util/module (see module_deps[] and > qom_modules[]). This series replaced that scheme with annotation > macros, so the meta-data can go into the module source code and -- for > example -- the module_obj() annotations can go next to the TypeInfo > struct for the object class. > > Patches 1-3 put the infrastructure in place: Add the annotation macros, > add a script to collect the meta-data, add a script to compile the > meta-data into C source code which we can then add to qemu. > > Patch 4 - check module dependencies (Jose, new in v4). > > Patches 5-13 add annotations macros to the modules we have. > > Patches 14-16 put the modinfo database into use and remove the > module_deps[] and qom_modules[] lists. > > Patch 16 adds two tracepoints for easier trouble-shooting. > > Patches 18-20 add support for target-specific modules. > > Patches 21-24 add documentation for all of the above (new in v4, was > separate series). > > Patches 25-29 start building accelerators modular. So far it is > only qtest (all archs) and a small fraction of tcg (x86 only). > > Patches 30-34 add support for registering hmp commands so they can > be implemented as module (new in v4, was separate series). > > take care, > Gerd > > Gerd Hoffmann (33): > modules: add modinfo macros > modules: collect module meta-data > modules: generate modinfo.c > modules: add qxl module annotations > modules: add virtio-gpu module annotations > modules: add chardev module annotations > modules: add audio module annotations > modules: add usb-redir module annotations > modules: add ccid module annotations > modules: add ui module annotations > modules: add s390x module annotations > modules: add block module annotations > modules: use modinfo for dependencies > modules: use modinfo for qom load > modules: use modinfo for qemu opts load > modules: add tracepoints > modules: check arch and block load on mismatch > modules: check arch on qom lookup > modules: target-specific module build infrastructure > modules: add documentation for module sourcesets > modules: add module_obj() note to QOM docs > modules: module.h kerneldoc annotations > modules: hook up modules.h to docs build > accel: autoload modules > accel: add qtest module annotations > accel: build qtest modular > accel: add tcg module annotations > accel: build tcg modular > monitor: allow register hmp commands > usb: drop usb_host_dev_is_scsi_storage hook > monitor/usb: register 'info usbhost' dynamically > usb: build usb-host as module > monitor/tcg: move tcg hmp commands to accel/tcg, register them > dynamically > > Jose R. Ziviani (1): > modules: check if all dependencies can be satisfied > > scripts/modinfo-collect.py | 67 +++++++++++ > scripts/modinfo-generate.py | 97 ++++++++++++++++ > include/hw/usb.h | 7 +- > include/monitor/monitor.h | 3 + > include/qemu/module.h | 74 ++++++++++++ > accel/accel-common.c | 2 +- > accel/accel-softmmu.c | 2 +- > accel/qtest/qtest.c | 2 + > accel/tcg/hmp.c | 29 +++++ > accel/tcg/tcg-accel-ops.c | 1 + > accel/tcg/tcg-all.c | 1 + > audio/spiceaudio.c | 2 + > block/iscsi-opts.c | 1 + > chardev/baum.c | 1 + > chardev/spice.c | 4 + > hw/display/qxl.c | 4 + > hw/display/vhost-user-gpu-pci.c | 1 + > hw/display/vhost-user-gpu.c | 1 + > hw/display/vhost-user-vga.c | 1 + > hw/display/virtio-gpu-base.c | 1 + > hw/display/virtio-gpu-gl.c | 3 + > hw/display/virtio-gpu-pci-gl.c | 3 + > hw/display/virtio-gpu-pci.c | 2 + > hw/display/virtio-gpu.c | 1 + > hw/display/virtio-vga-gl.c | 3 + > hw/display/virtio-vga.c | 2 + > hw/ppc/spapr.c | 2 +- > hw/s390x/virtio-ccw-gpu.c | 3 + > hw/usb/ccid-card-emulated.c | 1 + > hw/usb/ccid-card-passthru.c | 1 + > hw/usb/dev-storage-bot.c | 1 + > hw/usb/dev-storage-classic.c | 1 + > hw/usb/dev-uas.c | 1 + > hw/usb/host-libusb.c | 38 ++---- > hw/usb/host-stub.c | 45 ------- > hw/usb/redirect.c | 1 + > monitor/hmp.c | 7 ++ > monitor/misc.c | 34 +++--- > softmmu/vl.c | 24 ++-- > stubs/module-opts.c | 4 - > ui/egl-headless.c | 4 + > ui/gtk.c | 4 + > ui/sdl2.c | 4 + > ui/spice-app.c | 3 + > ui/spice-core.c | 5 + > util/module.c | 200 ++++++++++++++++++-------------- > accel/qtest/meson.build | 8 +- > accel/tcg/meson.build | 6 +- > docs/devel/build-system.rst | 17 +++ > docs/devel/index.rst | 1 + > docs/devel/modules.rst | 5 + > docs/devel/qom.rst | 8 ++ > hmp-commands-info.hx | 3 - > hw/usb/meson.build | 10 +- > meson.build | 82 +++++++++++++ > util/trace-events | 4 + > 56 files changed, 624 insertions(+), 218 deletions(-) > create mode 100755 scripts/modinfo-collect.py > create mode 100755 scripts/modinfo-generate.py > create mode 100644 accel/tcg/hmp.c > delete mode 100644 hw/usb/host-stub.c > create mode 100644 docs/devel/modules.rst > > -- > 2.31.1 > > >
* Gerd Hoffmann (kraxel@redhat.com) wrote: > This patch series adds support for module meta-data. Today this is > either hard-coded in qemu (see qemu_load_module_for_opts) or handled > with manually maintained lists in util/module (see module_deps[] and > qom_modules[]). This series replaced that scheme with annotation > macros, so the meta-data can go into the module source code and -- for > example -- the module_obj() annotations can go next to the TypeInfo > struct for the object class. So this is slightly off-topic for the series; but kind of relevant, but... Is there a way to inhibit module loading after a given point? I ask, because there's a fairly well known security escalation that takes advantage of NSS loading of PAM modules; typically you have your nice sandboxed application, you write out your nasty .so into the sandbox and then somehow get your application to trigger the PAM module load. Now, what stops the same attack here? Dave > Patches 1-3 put the infrastructure in place: Add the annotation macros, > add a script to collect the meta-data, add a script to compile the > meta-data into C source code which we can then add to qemu. > > Patch 4 - check module dependencies (Jose, new in v4). > > Patches 5-13 add annotations macros to the modules we have. > > Patches 14-16 put the modinfo database into use and remove the > module_deps[] and qom_modules[] lists. > > Patch 16 adds two tracepoints for easier trouble-shooting. > > Patches 18-20 add support for target-specific modules. > > Patches 21-24 add documentation for all of the above (new in v4, was > separate series). > > Patches 25-29 start building accelerators modular. So far it is > only qtest (all archs) and a small fraction of tcg (x86 only). > > Patches 30-34 add support for registering hmp commands so they can > be implemented as module (new in v4, was separate series). > > take care, > Gerd > > Gerd Hoffmann (33): > modules: add modinfo macros > modules: collect module meta-data > modules: generate modinfo.c > modules: add qxl module annotations > modules: add virtio-gpu module annotations > modules: add chardev module annotations > modules: add audio module annotations > modules: add usb-redir module annotations > modules: add ccid module annotations > modules: add ui module annotations > modules: add s390x module annotations > modules: add block module annotations > modules: use modinfo for dependencies > modules: use modinfo for qom load > modules: use modinfo for qemu opts load > modules: add tracepoints > modules: check arch and block load on mismatch > modules: check arch on qom lookup > modules: target-specific module build infrastructure > modules: add documentation for module sourcesets > modules: add module_obj() note to QOM docs > modules: module.h kerneldoc annotations > modules: hook up modules.h to docs build > accel: autoload modules > accel: add qtest module annotations > accel: build qtest modular > accel: add tcg module annotations > accel: build tcg modular > monitor: allow register hmp commands > usb: drop usb_host_dev_is_scsi_storage hook > monitor/usb: register 'info usbhost' dynamically > usb: build usb-host as module > monitor/tcg: move tcg hmp commands to accel/tcg, register them > dynamically > > Jose R. Ziviani (1): > modules: check if all dependencies can be satisfied > > scripts/modinfo-collect.py | 67 +++++++++++ > scripts/modinfo-generate.py | 97 ++++++++++++++++ > include/hw/usb.h | 7 +- > include/monitor/monitor.h | 3 + > include/qemu/module.h | 74 ++++++++++++ > accel/accel-common.c | 2 +- > accel/accel-softmmu.c | 2 +- > accel/qtest/qtest.c | 2 + > accel/tcg/hmp.c | 29 +++++ > accel/tcg/tcg-accel-ops.c | 1 + > accel/tcg/tcg-all.c | 1 + > audio/spiceaudio.c | 2 + > block/iscsi-opts.c | 1 + > chardev/baum.c | 1 + > chardev/spice.c | 4 + > hw/display/qxl.c | 4 + > hw/display/vhost-user-gpu-pci.c | 1 + > hw/display/vhost-user-gpu.c | 1 + > hw/display/vhost-user-vga.c | 1 + > hw/display/virtio-gpu-base.c | 1 + > hw/display/virtio-gpu-gl.c | 3 + > hw/display/virtio-gpu-pci-gl.c | 3 + > hw/display/virtio-gpu-pci.c | 2 + > hw/display/virtio-gpu.c | 1 + > hw/display/virtio-vga-gl.c | 3 + > hw/display/virtio-vga.c | 2 + > hw/ppc/spapr.c | 2 +- > hw/s390x/virtio-ccw-gpu.c | 3 + > hw/usb/ccid-card-emulated.c | 1 + > hw/usb/ccid-card-passthru.c | 1 + > hw/usb/dev-storage-bot.c | 1 + > hw/usb/dev-storage-classic.c | 1 + > hw/usb/dev-uas.c | 1 + > hw/usb/host-libusb.c | 38 ++---- > hw/usb/host-stub.c | 45 ------- > hw/usb/redirect.c | 1 + > monitor/hmp.c | 7 ++ > monitor/misc.c | 34 +++--- > softmmu/vl.c | 24 ++-- > stubs/module-opts.c | 4 - > ui/egl-headless.c | 4 + > ui/gtk.c | 4 + > ui/sdl2.c | 4 + > ui/spice-app.c | 3 + > ui/spice-core.c | 5 + > util/module.c | 200 ++++++++++++++++++-------------- > accel/qtest/meson.build | 8 +- > accel/tcg/meson.build | 6 +- > docs/devel/build-system.rst | 17 +++ > docs/devel/index.rst | 1 + > docs/devel/modules.rst | 5 + > docs/devel/qom.rst | 8 ++ > hmp-commands-info.hx | 3 - > hw/usb/meson.build | 10 +- > meson.build | 82 +++++++++++++ > util/trace-events | 4 + > 56 files changed, 624 insertions(+), 218 deletions(-) > create mode 100755 scripts/modinfo-collect.py > create mode 100755 scripts/modinfo-generate.py > create mode 100644 accel/tcg/hmp.c > delete mode 100644 hw/usb/host-stub.c > create mode 100644 docs/devel/modules.rst > > -- > 2.31.1 > > >
On Thu, Jun 24, 2021 at 04:01:25PM +0100, Dr. David Alan Gilbert wrote: > * Gerd Hoffmann (kraxel@redhat.com) wrote: > > This patch series adds support for module meta-data. Today this is > > either hard-coded in qemu (see qemu_load_module_for_opts) or handled > > with manually maintained lists in util/module (see module_deps[] and > > qom_modules[]). This series replaced that scheme with annotation > > macros, so the meta-data can go into the module source code and -- for > > example -- the module_obj() annotations can go next to the TypeInfo > > struct for the object class. > > So this is slightly off-topic for the series; but kind of relevant, > but... > Is there a way to inhibit module loading after a given point? We could block loading after machine initialization. Has implications for hotplug though. > I ask, because there's a fairly well known security escalation that > takes advantage of NSS loading of PAM modules; typically you have > your nice sandboxed application, you write out your nasty .so into the > sandbox and then somehow get your application to trigger the PAM module > load. > Now, what stops the same attack here? Placing a new .so at some random directory wouldn't work, qemu only loads modules from the search path (but I guess the same is true for pam). With this patch series applied all modules are listed the in modinfo.c database (even if we don't have any metadata about them), so we could easily limit loading to modules known at compile time. Not sure how much that alone would improve security though, when the attacker is able to write to the qemu module directory it isn't much of a problem to just overwrite one of the existing modules. We could try work with hashes or signatures stored in modinfo ... take care, Gerd
* Gerd Hoffmann (kraxel@redhat.com) wrote: > On Thu, Jun 24, 2021 at 04:01:25PM +0100, Dr. David Alan Gilbert wrote: > > * Gerd Hoffmann (kraxel@redhat.com) wrote: > > > This patch series adds support for module meta-data. Today this is > > > either hard-coded in qemu (see qemu_load_module_for_opts) or handled > > > with manually maintained lists in util/module (see module_deps[] and > > > qom_modules[]). This series replaced that scheme with annotation > > > macros, so the meta-data can go into the module source code and -- for > > > example -- the module_obj() annotations can go next to the TypeInfo > > > struct for the object class. > > > > So this is slightly off-topic for the series; but kind of relevant, > > but... > > Is there a way to inhibit module loading after a given point? > > We could block loading after machine initialization. > Has implications for hotplug though. Yes; I was thinking perhaps a command to explicitly disable autoloading if people worried about it. > > I ask, because there's a fairly well known security escalation that > > takes advantage of NSS loading of PAM modules; typically you have > > your nice sandboxed application, you write out your nasty .so into the > > sandbox and then somehow get your application to trigger the PAM module > > load. > > Now, what stops the same attack here? > > Placing a new .so at some random directory wouldn't work, qemu only > loads modules from the search path (but I guess the same is true for > pam). Yes, I'm failing to find the CVE I vaguely remember about the details of how it was messed up. Dave > With this patch series applied all modules are listed the in modinfo.c > database (even if we don't have any metadata about them), so we could > easily limit loading to modules known at compile time. Not sure how > much that alone would improve security though, when the attacker is able > to write to the qemu module directory it isn't much of a problem to just > overwrite one of the existing modules. > > We could try work with hashes or signatures stored in modinfo ... > > take care, > Gerd >