由驱动源码编译的.o文件在不同版本的内核环境下无法通用

一、解决驱动源码编译的.o文件不通用问题

1、背景

我希望将驱动的部分源码事先编译成 .o 文件，然后将另一部分源码和事先编译好的 .o 文件拿到其它内核环境下重新编译成驱动模块文件（.ko文件）。

2、问题描述

在 Ubuntu20.04（内核版本 5.15.0-91-generic）环境下，由部分驱动源码编译成的 .o 文件拿到 Ubuntu18.04（内核版本 5.4.0-84-generic）环境下重新编译成驱动模块文件（.ko文件）出错。

3、报错截图

4、原因分析

经过排查发现由于内核版本不同，内核的一些配置选项有些差异，20.04 的 menuconfig 相较于18.04 增加了一些选项，导致在 20.04 编译成的 .o 文件包含了 18.04 中没有的一些符号链接，具体可以使用 objdump -t xx.o 命令查看符号链接表。可以通过 make menuconfig 命令以图形化的界面关闭相关选项，或者通过直接修改 .config 配置文件关闭相关选项。

5、如何修改（A、B二选一）

A、通过 make menuconfig

搜索 CONFIG_RETPOLINE 找到 Enable return-thunks 选项并关闭（ 路径：Mitigations for speculative execution vulnerabilities --> Enable return-thunks）；搜索 CONFIG_RETPOLINE 找到 Undefined behaviour sanity checker 选项并关闭；（路径：Kernel hacking --> Generic Kernel Debugging Instruments --> Undefined behaviour sanity checker），内核版本 5.15.0-91-generic，其它内核版本可能略有差异。

B、修改 .config

将 CONFIG_RETHUNK=y 修改为 #CONFIG_RETHUNK is not set；将 CONFIG_UBSAN=y 修改为 #CONFIG_UBSAN is not set。

6、补充

A、__x86_return_thunk

__x86_return_thunk 是一个与安全相关的机制，主要用于防止某些类型的攻击，如间接分支投机（Indirect Branch Speculation）。这些攻击被称为 “Spectre” 攻击变种之一。为了应对这些安全漏洞，Linux 内核以及其他软件对其进行了各种缓解措施。具体来说，__x86_return_thunk 是一种在函数返回时替代直接使用 ret 指令的技术。它通过使用一个安全的返回路径来防止潜在的攻击，这些攻击可能利用 CPU 的分支预测机制导致信息泄露。

B、__ubsan_handle_out_of_bounds

__ubsan_handle_out_of_bounds 是 Undefined Behavior Sanitizer（UBSan）的一部分，用于检测并处理数组越界错误。UBSan 是一个编译时工具，主要用于捕获和报告程序中的未定义行为，帮助开发者发现和修复潜在的错误。在编译代码时，启用 UBSan 会在代码中插入检查点，这些检查点在运行时可以捕获各种未定义行为。例如，当程序尝试访问数组或指针超出其边界时，__ubsan_handle_out_of_bounds 会被调用。具体来说，__ubsan_handle_out_of_bounds 的作用是检测和处理数组越界访问。当程序执行到一个可能导致数组越界的操作时，插入的检查代码会调用这个函数。函数会记录错误信息，并且通常会中止程序的执行，以防止进一步的错误或崩溃。要在编译时启用 UBSan，可以在编译器选项中添加 -fsanitize=undefined。这通常适用于 GCC 和 Clang 编译器。

二、Makefile、.config、make menuconfig、Kconfig 之间的关系

Makefile 里面的条件编译是由 .config 中选项决定，修改 make menuconfig 配置选项会修改 .config 文件选项, make menuconfig 中的是否存在这个配置选项则是由 Kconfig 决定的。

作者：ThinkerOne
出处：https://www.cnblogs.com/zwsmile/p/14150552.html
声明：本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文链接，否则保留追究法律责任的权利。