Hi there, I tried to upload fwts to the Snap Store and got the message:
“The kernel-module-control interface is reserved for snaps that require device ownership and the ability to load arbitrary kernel modules and is not usually needed for typical snaps.” … etc
The Firmware Test Suite (fwts) requires a kernel UEFI test module to be installed so it can test the UEFI run time services via the test modules ioctl() interface, so loading this module is key to the core functionality of fwts. Can this snap be allowed to use the kernel-module-control interface?
This is a kernel module that the FWTS project has got upstream’d into the Linux kernel. It acts as a interface between the userspace fwts test program and the UEFI firmware run time services via a kernel ioctl. The module just needs to be loaded/unloaded by fwts. For the deb packaged fwts, we use the kernel module too, but if it is not present it can be build using dkms. In the snap version, we just need to use the kernel module that comes with the kernel packaging.
@cking - snapd has the ‘kmod’ interface backend that is used for loading modules on behalf of snaps (in this manner, the snap itself doesn’t have to have the required privileges to load modules itself). How this works is that a snap plugs an interface that uses one of the backends and snapd will create a file in /etc/modules-load.d to load the module hard-coded in the snapd interface code on boot (and at the time of interface connection. Eg, connecting the firewall-control interface will have snapd add iptable_filter and a few other modules that don’t normally autoload to /etc/modules-load.d/snap.<name>.conf).
Considering the above and that you said that you expect the snap to simply use the module from the kernel snap, does it make sense to create an interface that your snap would plug? Note that the snap has no control over how the module is loaded or when it is loaded/unloaded.
Well, I guess it makes sense to use the snapd way of doing things, but it may mean we have to re-engineer fwts to cater for this different module handling approach. This is unfortunately, but I guess it needs to be done this way to fit into the snap paradigm.
Note that fwts loads the efi_test module as well as the msr module (to access x86 model specific registers). fwts currently assumes it performs the following:
start test init:
load a specific kernel module (if required)
run the test
run test de-init
unload a specific kernel module (if loaded).
So I guess I need to re-work the per test init/deinit stages for it to work as a snap :-/
So, going forward, you propose interface(s) to load the efi_test and msr modules before fwts is executed? I’m not familiar with these snap mechanism when it comes to modules so I doubt I will be able to author these interfaces.
I talked to @cking on IRC and fwts has legitimate use of kernel-module-control for two reasons:
fwts needs to unload/load the module between tests in order to ensure that earlier tests tests don’t impact later tests
fwts is not intended to be loaded all the time as it is a debugging module. As such, using the kmod backend for this snap would mean that on all systems with this snap installed, the module would be loaded, all the time. Since the module is designed for debugging and not widespread use, it could increase the instability or attack surface since the module is being used in ways not intended by its authors
The first reason is enough to grant use of the interface. I’ve vetted the publisher. This is now live.
i had a similar use case for usbtop (which i then gave up trying to get into the store), where it tries to load a debug module (usbmon) …
would it perhaps make sense to have a “kernel-debug-module” interface that is restricted to loading/unloading only debug modules and could thus be handled less restrictive than kernel-module-control ?
That would be nice, but there is no way to control which module to load atm. It is possible that a helper could be used and the kmod backend extended.
Eg back of the napkin idea, a new interface is created or kernel-module-control is extended to allow specifying a ‘modules’ attribute. The snap uses a special modprobe/kmod that instead of performing the action, talks to snapd (similar to what we do with xdg-open). snapd looks at the modules that the snap wants to load/unload and compares it to the modules listed in the connected interface. If it matches, perform the action on behalf of the snap, else deny the request. A snap declaration would likely be required to specify the modules.
People are free to implement this as a PR against snapd, but before doing so, please create a new forum topic to sketch out the design and get approval from stakeholders (eg, at least @pedronis/@niemeyer and myself).
