Adding Support for the Custom Kernel Module Integrity Checks

[adharsh277]

Add support for custom kernel module integrity verification at boot

This PR introduces a mechanism to verify the integrity of custom kernel modules at boot time. The change addresses a security concern where Flatcar currently does not check custom modules for tampering or unauthorized modifications, leaving potential room for malicious code injection.

The implementation uses a signed list of approved kernel module hashes. During boot, each custom module is checked against this list. If a mismatch is found or the module is not recognized, the system can block the module or issue a warning, depending on configuration. This adds a layer of integrity and trust to customized Flatcar deployments.

How to use

To test this feature:

1. Place your custom kernel modules in the standard modules directory.
2. Generate and sign a hash list using the provided script (scripts/module-integrity/generate-signed-hashlist.sh).
3. Add the signature and hash list to the system directory (e.g., /etc/modules/trusted/).
4. Reboot the system. During boot, the verification hook checks the modules.
5. Unverified modules will be blocked or flagged in boot logs.

Testing done

I manually tested this on a Flatcar development VM:

• Loaded signed modules: Passed verification, loaded successfully.
• Modified one module: Verification failed and module was blocked.
• Logs confirmed expected behavior.

Example:

dmesg | grep kernel-module-check
# Output: module xyz.ko failed signature verification, blocking load

[ader1990]

Hello, I am looking at the changed files, are those changes the intended ones? The idea appears to be good, if you can give also some pointers on how it is implemented in other OSses and maybe on how we can integrate this idea directly in the Flatcar/scripts repo.

[tormath1]

@adharsh277 thanks - you do not need to submit a formal proposal like this. You can simply use the content of your idea file as issue description here: https://github.com/flatcar/Flatcar/issues/1739 (and I think the Kuberneteessss folder is out of scope and it has been mistakenly pushed)