Module for provide COW snapshot and change-block tracking functionality

At this stage, the question is how to configure the snap package and make it work on the system.
Our software relies on a specific kernel module which is called veeamsnap.

The module provides COW snapshot and change-block tracking functionality for block devices that are present in the system, thus ensureing filesystem consistency during backup.

There are two ways to install the module:

compile it on the target machine (either manually or using dkms)
use a pre-compiled binary (so far this one works only for RHEL-based distros, and on stable SLES releases)

We understand that the former might be not acceptable from some people from the security perspective, but the latter will require us to ship a pre-compiled module for every kernel version that is available for a particular distro since the module heavily relies on kABI. Without the module in place our software won’t be able to ensure backup consistency.

At the moment we use dpkg to install the module on distros other than RHEL/CentOS/SLES, and dkms is required in order to automatically rebuild the module after kernel updates.
If it is somehow possible to make a pre-compiled kernel module for Debian/Ubuntu/Mint which would work across different kernel versions (at least minor releases), we would like to learn how to do that.

  1. If the decision to use the module through the kernel-module-control, how to do it if need to check the kernel version of the system?(any example)
  2. If in the snap package to keep the sources of the module and when installing the snap package to copy them(source of modul) into the system and compile them there?

Thanks for the advice and help in solving this problem.

Can anyone advise how this can be solved correctly?

It isn’t so much that compiling it is unacceptable from a security perspective, DKMS does not exist as a concept with snapd.

The 2nd option is supported if you precompile it and have your snap ‘plugs: [ kernel-module-support ]’. This is what is problematic from a security perspective, because it allows loading a module into the kernel which gives device ownership to the snap for every system the snap is installed on. This is not typically granted to snaps in the public store. It also doesn’t really help you because, like you said, the module might not match all the kernels out there.

The ecosystem supports your use case via a brand store where you have devices and snaps associated with your brand and you have controls on how to manage the devices within your brand. This would typically include kernel snaps that have your module builtin so your module is available on your devices.

Beyond that, you could pursue upstreaming your module into the mainstream kernels so that it is available. This is a long term option. In the short term, for traditional classic distributions (eg, rpm/deb/etc based) you could have your snap detect if your module is loaded, and if not, provide instructions on how to do that (eg, instructions for downloading a deb that uses dkms, getting that deb into deb-based distributions like Ubuntu, Debian, etc).

Others in this forum may have other options to discuss.