kernel module protection/Kernel self-protection

kernel module protection/Kernel self-protection

该功能是linux源生的security feature，已经适用了几个版本，不需要OEM在这块feature上做定制，因为已经很成熟了。该feature旨在保护内核的.ko模块拒绝非法性加载

功能的开关：

CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y

CONFIG_MODULE_SIG_SHA512=y

kernel的模块签名保护kernel免受运行时加载到内核中的所有模块的影响。其动机是通过禁止加载未签名的模块或使用无效密钥签名的模块来保护内核免受恶意软件的攻击。如果启用模块签名，当用户或系统尝试加载模块时，内核会根据嵌入在内核中的公钥验证该模块的签名，以验证该模块的签名。如果密钥匹配，内核将加载模块，如果它们不匹配则拒绝该模块。
1.密钥在构建过程中随OPENSSL随机生成，每个构建随机生成，因此它不是唯一的。
2.用于签署模块的私钥在构建过程中生成。
3.每个构建的关键是不同的，是用OPENSSL命令随机生成的。
opensslreq -new -nodes -utf8 - “sha512”-days 36500 -batch -x509 -config x509.genkey -outform DEER -out signing_key.x509 -keyout

验证签署模块的公钥在构建过程中嵌入到内核中。

在MTK平台上导入key进行签名的步骤可以参考如下流程：

在最坏的情况下，我们假设非特权本地攻击者可以对内核的内存进行任意读写访问。在许多情况下，被利用的错误将不会提供这种访问级别，但是对于抵御最坏情况的系统，我们也会覆盖更多有限的情况。一个更高的栏，还有一个值得铭记的地方，是保护内核免受本地攻击者的攻击，因为root用户可以访问大量增加的攻击面。 （特别是当他们有能力加载任意内核模块时。）

成功的自我保护系统的目标是它们是有效的，默认情况下，不需要开发者选择加入，不会影响性能，不妨碍内核调试并进行测试。所有这些目标都可以得到满足是不常见的，但值得明确提及它们，因为这些方面需要被探索，处理或接受。

而解密的步骤主要是指load_module时（此流程参考MTK），在module.c中，当一个module被加载时，会对.ko的尾部的签名进行校验，例如先行检查签名中的“～Module signature appended～”，该动作只能确定.ko是否有签名，但不确定签名的正确性，所以验证签名的正确性需要在load中单独执行。

该功能测试：

    When themodule is loaded, the kernel checks the signature of the module. If thesignature does not exist or the content of the signature is inconsistent, itwill force the module to load

sdm660_64:/system/lib/modules# insmod data_breakpoint.ko

insmod: failed to loaddata_breakpoint.ko: Required key not available

aftersign we can find the module include the "Module signature appended"info appended

sdm660_64:/system/lib/modules# insmod data_breakpoint_signed.ko

sdm660_64:/system/lib/modules# lsmod

ModuleSize Used by

data_breakpoint16384 0

该模块的内容很少在网络，供应商处有描写，所以趁着这次学习的机会，将学习到的东西写下来作为总结同时分享.

reference：

本文引用了：

https://www.kernel.org/doc/html/latest/security/self-protection.html

https://wiki.gentoo.org/wiki/Signed_kernel_module_support#Validating_module_signature_support