Collaborative Working Sessions - Kernel module hashes

LWN article: https://lwn.net/Articles/1012946/

v1: https://lore.kernel.org/all/20241225-module-hashes-v1-0-d710ce7a3fd1@weissschuh.net/

v2: https://lwn.net/ml/all/20250120-module-hashes-v2-0-ba1184e27b7f@weissschuh.net/

v3: https://lore.kernel.org/all/20250429-module-hashes-v3-0-00e9258def9e@weissschuh.net/ → ima preparation patches discussed for separate merging, but this didn’t happen

  1. makes the kernel package build generally easier –> reduce complexity
  2. safety: the signing key could leak if an attacker gains read-only access to the build environment –> reduce attack surface

  3. less entropy needed: no need to generate ephemeral key and signatures, so the build might be faster on builders without a good source of entropy

    • If this is the last remaining bit of entropy in the kernel build process, that is a good argument to remove it for builders to be become completely deterministic.
  4. v4: Maybe we can optimize the load time checking a bit further: instead of linear search in the array of hashes, order the hashes by prefix during kernel build and then do a trie based search during load time - O(log n) instead of O(n) during load verification.
  5. Might make loading modules faster compared to signature verification because hashing of the module has to be done anyways during verification, and we no longer need the ECDSA/RSA signature verification.

5000 modules × 256/8 bytes/module = 150 kB of memory for the hash storage Total storage reqs are not changed, but are moved from the individual modules to the kernel. Unfortunately this means that memory is always loaded.