从你遇到的情况来看，核心问题是内核在查找pkcs1pad(rsa,sha256)加密算法时出现了间歇性阻塞甚至挂死——毕竟你已经修复了密钥环搜索和完整性密钥环缓存的bug，现在得把焦点放在加密子系统和模块加载的环节上。结合4.14内核对比3.14的变化，给你几个具体的排查方向：

• 检查加密算法的内核配置与模块依赖
  首先确认pkcs1pad(rsa,sha256)对应的内核模块是否完整：

  • 用modinfo pkcs1pad、modinfo rsa、modinfo sha256_generic检查这些模块是否存在于你的内核镜像或模块目录中；
  • 用lsmod确认模块是否已加载，尤其是启动阶段触发挂死的场景，可能是模块还没来得及加载就被调用了；
  • 对比3.14和4.14的内核配置，重点看CONFIG_CRYPTO_PKCS1PAD、CONFIG_CRYPTO_RSA、CONFIG_CRYPTO_SHA256这些选项，4.14里部分算法可能从内置改成了模块，导致启动阶段依赖模块加载服务未就绪。

• 分析request_module的阻塞风险
  问题触发点在request_module("crypto-%s", name)，这个函数会触发内核模块加载：

  • 尝试把pkcs1pad、rsa、sha256_generic直接编译进内核（设为y而不是m），跳过模块加载流程，如果问题消失，就说明是模块加载机制的问题；
  • 查看内核日志（dmesg | grep -E "crypto|module|rsa|sha256"），看是否有模块加载失败、依赖缺失或超时的报错；
  • 启动阶段挂死的话，要考虑此时udev或kmod服务是否还未初始化，导致模块加载请求无法处理。

• 排查加密算法查找的竞态与死锁
  4.14的加密子系统相比3.14有不少锁机制和查找逻辑的更新：

  • 开启CONFIG_MAGIC_SYSRQ后，在问题触发时用echo t > /proc/sysrq-trigger打印所有线程的栈回溯，检查是否有线程卡在mutex_lock或spin_lock上，排查死锁或锁竞争；
  • 对比3.14和4.14的crypto_larval_lookup实现，看是否新增了larval对象缓存或锁逻辑，这些地方可能存在竞态bug；
  • 确认你修复密钥环时是否修改了和加密子系统相关的锁，是否引入了新的竞争点。

• 验证IMA/EVM配置的兼容性
  虽然3.14上成功，但4.14的IMA/EVM有不少更新：

  • 检查CONFIG_IMA_VERIFY、CONFIG_EVM_VERIFY等配置是否正确开启，IMA策略（比如ima_policy内核参数）是否和3.14一致；
  • 确认签名时使用的算法和内核验证时期望的完全匹配，比如是否误用了硬件加速的SHA256模块（如sha256_arm）导致算法名称不匹配，但这个可能性较低，因为你已经定位到pkcs1pad(rsa,sha256)的查找问题。

• 独立测试加密算法的可用性
  排除IMA/EVM上下文的干扰，单独测试算法查找：

  • 写一个简单的内核模块，直接调用crypto_alloc_alg("pkcs1pad(rsa,sha256)", ...)，看是否会出现间歇性卡死；
  • 如果用户态能访问，也可以用cryptsetup benchmark或自定义工具测试对应的算法，但重点还是内核态的测试，因为IMA/EVM是在内核里执行验证的。

内容的提问来源于stack exchange，提问作者Gerhardh