本周继续连载 Risc-v Linux 系列文章，记得收藏分享+关注，合集：https://tinylab.org/riscv-linux
零门槛转战 RISC-V + 嵌入式 Linux，跟上泰晓科技的 B 站公开课，备一支 RISC-V 实验箱走起：https://tinylab.org/tiny-riscv-box
Linux 的 RISC-V 拓展支持与 alternative 运行时代码段修改
概述
RISC-V 拥有许多拓展指令集，CPU 可以选择性地支持这些拓展指令集。其中，RISC-V ISA Zbb 是一种基本位操作拓展指令集，可应用于字符串相关操作。近期，Linux 内核开始采用 Zbb 中的新指令来优化字符串操作，从而提升系统性能。
然而，内核必须同时考虑不支持 Zbb 的设备。使用不同的函数实现可能会引起多个问题，包括：
如果 CPU 不支持新指令该如何处理？ 如何将旧指令实现的函数替换成新指令实现的函数？ 启动的最初阶段内核不知道 CPU 支持哪些拓展。
为了解决这些问题，内核采用了"alternative"功能来实现函数替换。该功能可以在内核运行时将原有代码内容动态替换为新的代码内容，修改代码段以更改函数的执行路径。
"alternative"根据 CPU 的型号来决定是否替代代码。如果 CPU 不支持 Zbb，那么在内核启动时，就不会更改函数的执行路径，避免运行到 Zbb 专属指令的部分。
接下来，我们将研究 Linux Kernel v6.5-rc2 如何将原有的 strcmp 替换为 Zbb 中的新指令，并详细阐述"alternative"的实现原理。
准备工作
我们需要准备好测试环境，包括支持 Zbb 的工具链、支持 Zbb 的 CPU、并开启内核关于 Zbb 的选项。
工具链支持和内核选项
在内核代码中搜索 Zbb，可以找到如下配置选项：
// arch/riscv/Kconfig:507
config TOOLCHAIN_HAS_ZBB
bool
default y
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb)
depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
depends on AS_HAS_OPTION_ARCH
config RISCV_ISA_ZBB
bool "Zbb extension support for bit manipulation instructions"
depends on TOOLCHAIN_HAS_ZBB
depends on MMU
depends on RISCV_ALTERNATIVE
default y
help
Adds support to dynamically detect the presence of the ZBB
extension (basic bit manipulation) and enable its usage.
The Zbb extension provides instructions to accelerate a number
of bit-specific operations (count bit population, sign extending,
bitrotation, etc).
If you don't know what to do here, say Y.
我们需要开启这两个选项。RISCV_ISA_ZBB 依赖于 TOOLCHAIN_HAS_ZBB，TOOLCHAIN_HAS_ZBB 需要 LD_VERSION >= 23900。
我们可以使用 Binutils 2.40。如果发行版仓库中 Binutils 低于该版本，可以在 交叉编译工具链镜像 上下载该版本的 Binutils。
在正确的环境变量配置下，我们可以打开 menuconfig 来开启 RISCV_ISA_ZBB 选项。可以使用 / 来搜索选项，并且使用数字 1、2 来快速跳转到目标选项位置。
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
QEMU 支持
我们需要使用支持 Zbb 的 CPU 来运行内核。
QEMU 关于这方面的文档并不完整。通过在其 代码 中搜索，发现 v8.1.0-rc1 版本中的 veyron-v1 CPU 支持 Zbb。
使用 QEMU 运行 Linux Kernel：
qemu-system-riscv64
-nographic
-machine virt
-cpu veyron-v1
-kernel arch/riscv/boot/Image
-append "console=ttyS0"
如果我们想使用不支持 Zbb 的 CPU 来调试，可以使用 sifive-u54 CPU。
qemu-system-riscv64
-nographic
-machine virt
-cpu sifive-u54
-kernel arch/riscv/boot/Image
-append "console=ttyS0"
调试配置
内核开启调试选项
需要开启内核中的 CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT 选项来为内核增加调试信息。
VSCode 调试配置
我们可以使用 VSCode 来让调试更加便利。
只需要在项目根目录下创建两个文件 .vscode/launch.json 和 .vscode/tasks.json，即可使用 VSCode 来调试内核。
// .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Kernel Debug",
"type": "cppdbg",
"request": "launch",
"miDebuggerServerAddress": "localhost:1234",
"program": "${workspaceFolder:}/vmlinux",
"sourceFileMap": {
"kernel.map": "${workspaceFolder:}/System.map"
},
"MIMode": "gdb",
"externalConsole": false,
"miDebuggerPath": "gdb-multiarch",
"internalConsoleOptions": "openOnSessionStart",
"preLaunchTask": "qemu-debug",
"cwd": "${workspaceFolder:}",
"setupCommands": [
{
"text": "-enable-pretty-printing",
"description": "Enable GDB pretty printing",
"ignoreFailures": true
},
{
"text": "set architecture riscv:rv64",
"description": "Set target architecture",
"ignoreFailures": true
}
],
"miDebuggerArgs": "-q"
}
]
}
// .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "qemu-debug",
"command": "echo starting qemu... 1>&2 && qemu-system-riscv64 -nographic -machine virt -cpu veyron-v1 -kernel arch/riscv/boot/Image -append console=ttyS0 -s -S",
"isBackground": true,
"presentation": {
"echo": true,
"reveal": "always",
"focus": true,
"panel": "shared",
"showReuseMessage": false
},
"options": {
"cwd": "${workspaceFolder:}"
},
"problemMatcher": {
"pattern": {
"regexp": "."
},
"background": {
"activeOnStart": true,
"beginsPattern": ".",
"endsPattern": "."
}
}
}
]
}
通过更改 .vscode/tasks.json 中的 command 项，可以修改 QEMU 的参数。
创建好这两个文件后，即可使用 VSCode 调试功能。
alternative 原理
动态替换代码
首先我们来看一下 arch/riscv/lib/strcmp.S，可以 在线 查看代码。
strcmp.S 的结构为：
strcmp:
ALTERNATIVE("nop", "j strcmp_zbb", 0, RISCV_ISA_EXT_Zbb, CONFIG_RISCV_ISA_ZBB)
< 通用的 strcmp 汇编代码 >
ret
strcmp_zbb:
< 使用 Zbb 拓展指令的 strcmp 汇编代码 >
ret
ALTERNATIVE 是 汇编宏，在汇编转换为机器码的阶段展开。编译后，这部分代码段在运行时实际上会变为：
strcmp:
nop
< 通用的 strcmp 汇编代码 >
ret
strcmp_zbb:
< 使用 Zbb 拓展指令的 strcmp 汇编代码 >
ret
原来的 ALTERNATIVE 展开成 nop 指令。
我们可以推测，在内核启动时，如果 CPU 支持并且内核配置了 ZBB 选项，ALTERNATIVE 将把 nop 指令修改为跳转指令，跳转到 strcmp_zbb 处执行；相反，不支持 ZBB 的 CPU 或者没有配置 ZBB 选项，只会执行通用的 strcmp 汇编代码。
运行时的代码段修改
先在 arch/riscv/kernel/alternative.c 的 riscv_alternative_fix_offsets() 函数打断点。
这里的 alt_ptr 是 strcmp，有点像我们要找的地方。我们又在调用栈的上一层 riscv_cpufeature_patch_func() 打断点并重新运行，看执行 riscv_alternative_fix_offsets() 函数之前是什么样子。
调用栈的更上一层，即 riscv_alternative_fix_offsets() 的调用者 _apply_alternatives() 函数我们暂时不讨论。
我们暂停在执行 riscv_cpufeature_patch_func() 函数的 patch_text_nosync() 语句前：
oldptr 指向代码段 strcmp，altptr 指向代码段 strcmp+130，strcmp+130 的指令内容为 j strcmp+34，即跳转到 Zbb 拓展实现的 strcmp_zbb 处。
为什么突然出现 strcmp+130 这样的地址呢？
刚刚的 strcmp.S 代码中是这样的：
ALTERNATIVE("nop", "j strcmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB)
我们对 vmlinux 进行反汇编。strcmp+130 是整个的 strcmp.S 的结束地址，再往后是 strlen，
$ riscv64-linux-objdump -D -j .text vmlinux | grep -A "35" "<strcmp_zbb>:"
ffffffff800ab18a <strcmp_zbb>:
ffffffff800ab18a: 00b563b3 or t2,a0,a1
ffffffff800ab18e: 5efd li t4,-1
ffffffff800ab190: 0073f393 and t2,t2,7
ffffffff800ab194: 02039e63 bnez t2,ffffffff800ab1d0 <strcmp_zbb+0x46>
ffffffff800ab198: 00053283 ld t0,0(a0)
ffffffff800ab19c: 0005b303 ld t1,0(a1)
ffffffff800ab1a0: 2872de13 orc.b t3,t0
ffffffff800ab1a4: 03de1163 bne t3,t4,ffffffff800ab1c6 <strcmp_zbb+0x3c>
ffffffff800ab1a8: 0521 add a0,a0,8
ffffffff800ab1aa: 05a1 add a1,a1,8
ffffffff800ab1ac: fe6286e3 beq t0,t1,ffffffff800ab198 <strcmp_zbb+0xe>
ffffffff800ab1b0: 6b82d293 rev8 t0,t0
ffffffff800ab1b4: 6b835313 rev8 t1,t1
ffffffff800ab1b8: 0062b533 sltu a0,t0,t1
ffffffff800ab1bc: 40a00533 neg a0,a0
ffffffff800ab1c0: 00156513 or a0,a0,1
ffffffff800ab1c4: 8082 ret
ffffffff800ab1c6: 00629563 bne t0,t1,ffffffff800ab1d0 <strcmp_zbb+0x46>
ffffffff800ab1ca: 4501 li a0,0
ffffffff800ab1cc: 8082 ret
ffffffff800ab1ce: 0001 nop
ffffffff800ab1d0: 00054283 lbu t0,0(a0)
ffffffff800ab1d4: 0005c303 lbu t1,0(a1)
ffffffff800ab1d8: 0505 add a0,a0,1
ffffffff800ab1da: 0585 add a1,a1,1
ffffffff800ab1dc: 00629463 bne t0,t1,ffffffff800ab1e4 <strcmp_zbb+0x5a>
ffffffff800ab1e0: fe0298e3 bnez t0,ffffffff800ab1d0 <strcmp_zbb+0x46>
ffffffff800ab1e4: 40628533 sub a0,t0,t1
ffffffff800ab1e8: 8082 ret
ffffffff800ab1ea: fa1ff06f j ffffffff800ab18a <strcmp_zbb>
...
ffffffff800ab1f8 <__pi_strlen>:
ffffffff800ab1f8: 00000013 nop
ffffffff800ab1fc: 832a mv t1,a0
可以发现新指令 j strcmp_zbb 实际上是存放在 strcmp.S 的结束处的。说明 ALTERNATIVE 搞了一些魔法，定位到了该节的末尾，插入了新代码 j strcmp_zbb。我们将在文章的下个小节讨论这个魔法。
继续分析后续代码。在执行了 patch_text_nosync() 后，刚刚查看的 strcmp 内存处的 nop 指令已经变成了 j 0xffffffff800ab108，如下图：
这个跳转地址很奇怪，看起来没有任何作用。我们将在文章的下个小节讨论它。
执行了 riscv_alternative_fix_offsets() 后，原来的 nop 变成了 j strcmp+34。
查看 strcmp+34 处的指令，可以发现该处即为使用 Zbb 拓展指令实现的高性能 strcmp_zbb。
在此之后，内核代码段的内容已经被修改。原本调用 strcmp() 执行的第一条指令为 nop 指令，现在 nop 指令被修改为无条件跳转指令。调用 strcmp() 会立即跳转到 34 字节外的新指令 strcmp_zbb 上。
原有的：
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
0修改后：
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
1代码段 strcmp label 处的指令的变化过程：
| 语句 | 代码段 strcmp label 处的指令 |
|---|---|
patch_text_nosync() 执行前 | nop |
patch_text_nosync() 执行后 | j0xffffffff800ab108 <__memset+156> |
riscv_alternative_fix_offsets() 执行后 | j0xffffffff800ab18a <strcmp+34> <strcmp_zbb> |
经过两次代码段修改，nop 指令被修改为跳转到 strcmp_zbb 的指令
ELF 的 .alternative 节与魔法
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
2ALTERNATIVE 汇编宏展开时，会调用 ALT_NEW_CONTENT 汇编宏。
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
3其中，".4byte((" oldptr ") -.) n" 将 oldptr label 到当前位置的距离存储到了这个 4byte 大小空间中。有了偏移量，在应用 alternative 时（即刚刚打断点的 riscv_cpufeature_patch_func（） 函数的调用者 _apply_alternatives()），就能计算出新代码和旧代码的位置：
保存 offset 这个行为是由 该 patch 提供的，在这之前是直接保存的绝对地址，占用了更多的空间。
该汇编宏使用 .pushsection 在 ELF 文件中建立了 .alternative 节，将偏移量、vendor_id 和 patch_id 一起放在该节中。新代码并没有存储在这里，应该是为了缓存命中率的考虑，把新代码放在了所属代码节末尾。
存在于代码最前端的 ALTERNATIVE 展开后，能够把新代码放到代码段末尾，是通过 .subsection 和 .previous 实现的。
因此，后续 _apply_alternatives() 可以遍历该节每个 entry 来替换旧代码。
替换了两次旧代码？
在刚刚的分析中，我们 strcmp 处的代码被替换了两次，第一次替换的新代码跳转到 __memset+156 处，在 riscv_alternative_fix_offsets() 执行后，新代码才跳转到 strcmp_zbb 处。
首先我们来看看 patch_text_nosync() 的定义：
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
4这个函数在 addr 上写入长度为 len 的 insns。更改代码段需要刷新 icache 来确保缓存一致性。
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
5riscv_alternative_fix_offset() 函数根据偏移量计算出真正需要跳转的距离，按情况指派给 riscv_alternative_fix_auipc_jalr()、riscv_alternative_fix_jal()、riscv_alternative_fix_offsets() 函数，这些函数生成对应的指令后，再次使用 patch_text_nosync() 来修改目标地址代码。
经过 git blame 和搜索邮件列表，我们发现有一 patch 做了以下改动：
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
6邮件中写到：
make ARCH=riscv CROSS_COMPILE=riscv64-linux- menuconfig
7原来是因为单独的一行 patch_text_nosync() 会有 bug，offset 计算不正确，所以才使用一个单独的函数来修补错误。
总结
内核的启动过程中，会检测 CPU 的型号，遍历 .alternative 节中的 entry，符合条件的 patch 会被 apply。apply 会修改目标地址的旧代码为新代码，同时确保 icache 一致性。
针对 RISC-V 架构设备而言，其模块化的架构设计意味着不同的扩展可以拥有各自的优化指令。CPU 的指令集只能在运行时才能得知，在此之前只能使用兼容性最高的指令。“alternative” 在这种情况下是一种非常好的解决方案，既保证了兼容性，也提高了性能。
参考资料
RISC-V Bit-manipulation A, B, C and S Extensions | Five EmbedDev (five-embeddev.com) Latest corss-compilers Linux kernel source tree 通过编译器解决因链接过程 KEEP 操作引起的 Section GC 失败问题 QEMU source tree Macro (Using as) [PATCH v5 09/13] riscv: switch to relative alternative entries [PATCH v5 12/12] RISC-V: fix auipc-jalr addresses in patched alternatives
首发地址：https://tinylab.org/riscv-linux-extension-and-alternative
技术服务：https://tinylab.org/ruma.tech
左下角 阅读原文 可访问外链。都看到这里了，就随手在看+分享一下吧 ;-)
推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论，来说两句吧...